search

droe / sslsplit

Transparent SSL/TLS interception
https://www.roe.ch/SSLsplit
BSD 2-Clause "Simplified" License
1.73k stars 327 forks source link

net::ERR_CERT_INVALID with Chrome, Firefox for some sites, but not others #188

Open LeosSire opened 6 years ago

LeosSire commented 6 years ago

Hello.

I’m not sure if this is more documentation/setup related rather than code/functional and the correct place to ask but I won’t be the only one facing this.

Recently after updating chromium some websites are rejecting my Certs. Eg Wikipedia. Firefox does the same now too. Sites like google accept my cert and allow sslsplit as normal.

Reading the fault in the ‘developer tools -> security issues’ it’s that the cert issuer isn’t recognised. Obviously it’s not. It’s self cert. and I’m not that famous. Am I missing something on setup to get round this?

Options ‘-O -P’ allow the sites to be bypassed allowing seemless access but it avoids the point of SSLSplit

Has anyone else had this problem and if so how did you overcome it?

Thanks.

LeosSire commented 6 years ago

iPhone safari works and allows access. Silk Browser on Kindle (I believe Android based) works.

Seems to be PC causing the issues. Must be more rigorous key chain checking.

LeosSire commented 6 years ago

Good morning,

I have been looking further into this issue. While Safari works on an iDevice. Youtube app does not. This routes via the common google ip and (I'm guessing) resolves and returns the url as needs require. Odd as google works in safari. Youtube app IP from wireshark 216.58.198.225

Reading the output from SSLSplit youtube app is failing due to 'Unclean SSL shutdown'.

When I visit Wikipedia.org in Chromium the site fail on security issues. Looking at the Developer Tools -> Security -> Certificate Info in Chromium it appears the 'basic constrains' of the forwarded certificate aren't listed as a Certificate Authority. Could this be causing the issue?

Does this mean crypto pairs are going to need to be generated by an established CA with Private Keys capable of deriving a certificate already recognised?

Thoughts?

Thank you,

droe commented 6 years ago

Can you post the output of openssl x509 -in cert.pem -text on the CA certificate that you are using with SSLsplit and how you generated it? If applicable, which documentation did you follow to generate the certificate?

LeosSire commented 6 years ago

I made a fresh one for this post. Checked and the error continues. 

Certificate:
    Data:
        Version: 1 (0x0)
        Serial Number:
            d7:f1:af:8a:80:10:d3:d0
    Signature Algorithm: sha256WithRSAEncryption
        Issuer: C=UK, ST=Midlands, L=Warwickshire, O=SSLTest, CN=www.SSLTest.com
        Validity
            Not Before: Mar 28 11:41:00 2018 GMT
            Not After : Mar 25 11:41:00 2028 GMT
        Subject: C=UK, ST=Midlands, L=Warwickshire, O=SSLTest, CN=www.SSLTest.com
        Subject Public Key Info:
            Public Key Algorithm: rsaEncryption
                Public-Key: (2048 bit)
                Modulus:
                    00:b9:9b:76:6b:f9:07:d1:06:3a:ca:88:2d:d4:79:
                    ec:ce:0d:6a:9d:53:41:99:60:e2:d0:cb:b1:84:fe:
                    29:f4:d9:cc:54:9a:8a:ee:9e:37:1f:32:40:d0:de:
                    ea:77:a5:cf:e5:51:f7:16:84:48:16:69:63:2d:55:
                    c7:df:df:7c:5d:9d:fb:9f:c9:1f:41:bf:4e:fc:80:
                    3b:8e:c6:17:a9:9b:77:c7:12:95:bd:d3:6f:f7:66:
                    c3:af:65:49:1b:2b:09:0d:7b:cb:75:51:a0:19:b9:
                    77:76:80:6f:46:2f:44:72:ae:5a:49:b3:64:0e:60:
                    fd:65:21:c7:37:d5:d9:b4:55:70:8f:c7:78:e7:c1:
                    c7:95:21:36:6c:78:10:7c:64:d4:c7:31:ad:e0:44:
                    ff:c7:80:0f:91:be:66:14:45:60:9d:62:06:6a:f1:
                    ac:c7:0b:41:ce:8c:6b:17:17:d9:db:32:a6:9e:b7:
                    c4:ce:5d:51:19:8d:48:31:a9:03:9f:ee:cc:17:60:
                    9c:68:df:d0:ea:e7:05:80:93:bc:2e:53:7b:ac:32:
                    9c:57:c9:39:56:42:d9:5a:4c:b5:52:c6:29:6e:85:
                    3a:51:77:24:e2:7d:3a:ad:45:71:0b:54:46:ae:8b:
                    83:77:46:45:ff:31:82:1d:ef:51:1e:69:8e:b1:96:
                    fe:15
                Exponent: 65537 (0x10001)
    Signature Algorithm: sha256WithRSAEncryption
         13:42:95:5f:74:78:02:34:88:3a:28:8b:61:50:4f:36:ed:aa:
         30:eb:8c:c1:4c:28:ee:74:58:44:75:c6:22:f3:29:27:aa:5b:
         dd:2c:dc:7d:7a:ec:39:aa:18:3e:eb:a4:e0:c5:a7:e9:14:cc:
         2f:bb:76:df:c9:00:a1:8a:7d:82:0b:5b:a3:90:85:60:8a:d0:
         c9:b9:86:11:aa:f3:02:80:35:48:82:25:b7:8a:cb:25:ca:1c:
         84:78:03:7d:2d:19:32:a2:71:07:37:da:2d:e2:20:b2:7a:0e:
         55:19:1f:0d:8a:87:a8:d6:9b:ca:89:df:d7:2c:92:b7:e4:38:
         3e:07:81:02:0d:b1:2e:0d:48:c2:ce:35:24:7f:67:68:17:33:
         ad:e6:7f:b4:ee:f5:9a:20:61:46:11:1a:fe:7f:5f:f7:9d:ad:
         ee:5a:0a:89:9e:2d:ed:de:16:88:0e:72:46:6a:74:81:29:cc:
         b7:cf:16:c4:5a:30:9a:32:a1:1b:35:08:99:c0:ce:29:19:1c:
         63:30:e8:d0:1f:3b:7a:6c:b5:05:7b:67:de:c0:4a:da:3e:be:
         1e:59:5e:ad:a3:14:21:43:66:26:de:61:d8:2e:a0:4d:48:a5:
         2a:4f:76:25:1d:9d:31:89:ea:5e:db:d0:24:20:f6:55:9d:1c:
         eb:4a:df:b0
-----BEGIN CERTIFICATE-----
MIIDQjCCAioCCQDX8a+KgBDT0DANBgkqhkiG9w0BAQsFADBjMQswCQYDVQQGEwJV
SzERMA8GA1UECAwITWlkbGFuZHMxFTATBgNVBAcMDFdhcndpY2tzaGlyZTEQMA4G
A1UECgwHU1NMVGVzdDEYMBYGA1UEAwwPd3d3LlNTTFRlc3QuY29tMB4XDTE4MDMy
ODExNDEwMFoXDTI4MDMyNTExNDEwMFowYzELMAkGA1UEBhMCVUsxETAPBgNVBAgM
CE1pZGxhbmRzMRUwEwYDVQQHDAxXYXJ3aWNrc2hpcmUxEDAOBgNVBAoMB1NTTFRl
c3QxGDAWBgNVBAMMD3d3dy5TU0xUZXN0LmNvbTCCASIwDQYJKoZIhvcNAQEBBQAD
ggEPADCCAQoCggEBALmbdmv5B9EGOsqILdR57M4Nap1TQZlg4tDLsYT+KfTZzFSa
iu6eNx8yQNDe6nelz+VR9xaESBZpYy1Vx9/ffF2d+5/JH0G/TvyAO47GF6mbd8cS
lb3Tb/dmw69lSRsrCQ17y3VRoBm5d3aAb0YvRHKuWkmzZA5g/WUhxzfV2bRVcI/H
eOfBx5UhNmx4EHxk1McxreBE/8eAD5G+ZhRFYJ1iBmrxrMcLQc6MaxcX2dsypp63
xM5dURmNSDGpA5/uzBdgnGjf0OrnBYCTvC5Te6wynFfJOVZC2VpMtVLGKW6FOlF3
JOJ9Oq1FcQtURq6Lg3dGRf8xgh3vUR5pjrGW/hUCAwEAATANBgkqhkiG9w0BAQsF
AAOCAQEAE0KVX3R4AjSIOiiLYVBPNu2qMOuMwUwo7nRYRHXGIvMpJ6pb3SzcfXrs
OaoYPuuk4MWn6RTML7t238kAoYp9ggtbo5CFYIrQybmGEarzAoA1SIIlt4rLJcoc
hHgDfS0ZMqJxBzfaLeIgsnoOVRkfDYqHqNabyonf1yySt+Q4PgeBAg2xLg1Iws41
JH9naBczreZ/tO71miBhRhEa/n9f952t7loKiZ4t7d4WiA5yRmp0gSnMt88WxFow
mjKhGzUImcDOKRkcYzDo0B87emy1BXtn3sBK2j6+HlleraMUIUNmJt5h2C6gTUil
Kk92JR2dMYnqXtvQJCD2VZ0c60rfsA==
-----END CERTIFICATE-----

The above was generated with the following script:

#!/bin/sh                                                                                                                                             

if [[ $1 == --self ]]; then                                                                                                                           
  SELF_SIGN=1                                                                                                                                         
  shift                                                                                                                                               
fi                                                                                                                                                    

KEY_NAME=$1                                                                                                                                           
CSR_CONFIG=$2                                                                                                                                         

openssl req -config $CSR_CONFIG -new -newkey rsa:2048 -nodes -keyout /${KEY_NAME}.key -out /${KEY_NAME}.csr                                           

#echo "Created ${KEY_NAME}.key"                                                                                                                       
#echo "Created ${KEY_NAME}.csr"                                                                                                                       

if [[ -n $SELF_SIGN ]]; then                                                                                                                          
  openssl x509 -req -days 3650 -in /${KEY_NAME}.csr -signkey /${KEY_NAME}.key -out /${KEY_NAME}.crt                                                   
#echo "Created ${KEY_NAME}.crt (self-signed)"                                                                                                       
fi

The template: 

[ req ]
distinguished_name="SSLTest"
prompt="no"

[ SSLTest ]
C="UK"
ST="Midlands"
L="Warwickshire"
O="SSLTest"
CN="www.SSLTest.com"

Thank you,

LeosSire commented 6 years ago

Hello,

Last piece of info. Thought it would send the output and the version I'm using:

SNI peek: [en.wikipedia.org] [complete]
Attempt reuse dst SSL session
Connecting to [91.198.174.192]:443
===> Original server certificate:
Subject DN: /C=US/ST=California/L=San Francisco/O=Wikimedia Foundation, Inc./CN=*.wikipedia.org
Common Names: *.wikipedia.org/*.wikipedia.org/wikipedia.org/*.m.wikipedia.org/*.zero.wikipedia.org/wikimedia.org/*.wikimedia.org/*.m.wikimedia.org/*.planet.wikimedia.org/mediawiki.org/*.mediawiki.org/*.m.mediawiki.org/wikibooks.org/*.wikibooks.org/*.m.wikibooks.org/wikidata.org/*.wikidata.org/*.m.wikidata.org/wikinews.org/*.wikinews.org/*.m.wikinews.org/wikiquote.org/*.wikiquote.org/*.m.wikiquote.org/wikisource.org/*.wikisource.org/*.m.wikisource.org/wikiversity.org/*.wikiversity.org/*.m.wikiversity.org/wikivoyage.org/*.wikivoyage.org/*.m.wikivoyage.org/wiktionary.org/*.wiktionary.org/*.m.wiktionary.org/wikimediafoundation.org/*.wikimediafoundation.org/*.m.wikimediafoundation.org/wmfusercontent.org/*.wmfusercontent.org/w.wiki
Fingerprint: 0F:FB:95:52:F3:B1:3E:CF:AB:6E82:8C:60:88:A2:0F:D0:04:4E:4E
Certificate cache: HIT
===> Forged server certificate:
Subject DN: /C=US/ST=California/L=San Francisco/O=Wikimedia Foundation, Inc./CN=*.wikipedia.org
Common Names: *.wikipedia.org/*.wikipedia.org/wikipedia.org/*.m.wikipedia.org/*.zero.wikipedia.org/wikimedia.org/*.wikimedia.org/*.m.wikimedia.org/*.planet.wikimedia.org/mediawiki.org/*.mediawiki.org/*.m.mediawiki.org/wikibooks.org/*.wikibooks.org/*.m.wikibooks.org/wikidata.org/*.wikidata.org/*.m.wikidata.org/wikinews.org/*.wikinews.org/*.m.wikinews.org/wikiquote.org/*.wikiquote.org/*.m.wikiquote.org/wikisource.org/*.wikisource.org/*.m.wikisource.org/wikiversity.org/*.wikiversity.org/*.m.wikiversity.org/wikivoyage.org/*.wikivoyage.org/*.m.wikivoyage.org/wiktionary.org/*.wiktionary.org/*.m.wiktionary.org/wikimediafoundation.org/*.wikimediafoundation.org/*.m.wikimediafoundation.org/wmfusercontent.org/*.wmfusercontent.org/w.wiki
Fingerprint: BE:3B:52:A0:EC:3D:00:55:FF:0E98:53:BE:D2:AE:11:32:93:96:85
SSL connected to [91.198.174.192]:443 TLSv1.2 ECDHE-ECDSA-AES256-GCM-SHA384
CLIENT_RANDOM 375E8FF2A2EAFAE87E32C8C25F7EAB31753755E15D734421F1C906A78C1DD92B D9DC6B8244B6A63B415DB5FAAF4E38008FF4B15BD84F5600B4855BA4E36F2CDEF3D0D3B28C25E20947E9CC3C42D499BD
Certificate cache: KEEP (SNI match or target mode)
ssl 192.168.1.211 54486 91.198.174.192 443 sni:en.wikipedia.org names:*.wikipedia.org/*.wikipedia.org/wikipedia.org/*.m.wikipedia.org/*.zero.wikipedia.org/wikimedia.org/*.wikimedia.org/*.m.wikimedia.org/*.planet.wikimedia.org/mediawiki.org/*.mediawiki.org/*.m.mediawiki.org/wikibooks.org/*.wikibooks.org/*.m.wikibooks.org/wikidata.org/*.wikidata.org/*.m.wikidata.org/wikinews.org/*.wikinews.org/*.m.wikinews.org/wikiquote.org/*.wikiquote.org/*.m.wikiquote.org/wikisource.org/*.wikisource.org/*.m.wikisource.org/wikiversity.org/*.wikiversity.org/*.m.wikiversity.org/wikivoyage.org/*.wikivoyage.org/*.m.wikivoyage.org/wiktionary.org/*.wiktionary.org/*.m.wiktionary.org/wikimediafoundation.org/*.wikimediafoundation.org/*.m.wikimediafoundation.org/wmfusercontent.org/*.wmfusercontent.org/w.wiki sproto:TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256 dproto:TLSv1.2:ECDHE-ECDSA-AES256-GCM-SHA384 origcrt:0FFB9552F3B13ECFAB6E828C6088A20FD0044E4E usedcrt:BE3B52A0EC3D0055FF0E9853BED2AE1132939685
SSL connected from [192.168.1.211]:54486 TLSv1.2 ECDHE-RSA-AES128-GCM-SHA256
CLIENT_RANDOM 19368F9DBFC3C8763ED6218D896DEDFFED96BE5ADD0CD3DB1006E8CF0E44390C D1D7FE328304DBD80B55D4D85906AACC0F512087159E5CEB2D91F51C9A342132CF4837F8B64FBBA95EDFC9A5B64E7572
Unclean SSL shutdown.
SSL disconnected to [91.198.174.192]:443
SSL disconnected from [192.168.1.211]:54486
SSL_free() in state 00000003 = 0003 = SSLOK  (SSL negotiation finished successfully) [accept socket]
Failed to shutdown SSL connection cleanly: Max retries reached. Closing fd.
SSL_free() in state 00000003 = 0003 = SSLOK  (SSL negotiation finished successfully) [connect socket]

p.s. My version info:

SSLsplit 0.5.2 (built 2018-03-19)
Copyright (c) 2009-2018, Daniel Roethlisberger <daniel@roe.ch>
https://www.roe.ch/SSLsplit
Build info: V:FILE
Features: -DHAVE_NETFILTER
NAT engines: netfilter* tproxy
netfilter: IP_TRANSPARENT IP6T_SO_ORIGINAL_DST
Local process info support: no
compiled against OpenSSL 1.0.2l  25 May 2017 (100020cf)
rtlinked against OpenSSL 1.0.2l  25 May 2017 (100020cf)
OpenSSL has support for TLS extensions
TLS Server Name Indication (SNI) supported
OpenSSL is thread-safe with THREADID
Using SSL_MODE_RELEASE_BUFFERS
SSL/TLS protocol availability: tls10 tls11 tls12 
SSL/TLS algorithm availability: !SHA0 RSA DSA ECDSA DH ECDH EC
OpenSSL option availability: SSL_OP_NO_COMPRESSION SSL_OP_NO_TICKET SSL_OP_ALLOW_UNSAFE_LEGACY_RENEGOTIATION SSL_OP_DONT_INSERT_EMPTY_FRAGMENTS SSL_OP_NO_SESSION_RESUMPTION_ON_RENEGOTIATION SSL_OP_TLS_ROLLBACK_BUG
compiled against libevent 2.0.22-stable
rtlinked against libevent 2.0.22-stable
1 CPU cores detected
droe commented 6 years ago

Okay, you want to have basic constraints in your CA certificate. Check out the openssl commands in the make file and the config file that goes with them in https://github.com/droe/sslsplit/blob/develop/extra/pki/ specifically basicConstraints = CA:TRUE

Having said that, sslsplit should warn you that you are using a CA certificate without basic constraints. I'm flagging this issue as a feature request for better sanity checking and error reporting on the provided certificate.

LeosSire commented 6 years ago

Evening Daniel,

I have used the makefile and made the crypto pairs. Using the RSA. cyrpto pair I am still getting the same issue. In my testing over the last few weeks I have tried the CA:true flag but the same result. I tried your makefile too.

I thought you may appriciate the below. The cert's are generated as normal with Google

screenshot from 2018-03-28 20-41-08

But when you try wikipedia it faults.

screenshot from 2018-03-28 19-44-19

The criticallity of the certificate being a Certification Authority seems to depend on the website in question.

I have tried the other crypto pairs generated, some don't install as they're not the right type, naturally, but the RSA pair does work, on google and github but not wikipedia.

Apologies for persisting but it's very frustrating as I use this software often.

Thank you,

LeosSire commented 6 years ago

Any thoughts? Ive been working on a ‘work-around’ to force passthrough on SNI matching so I can continue to use without issues. (Whitelisting in effect). ‘-P’ has stopped working too on the sites I mentioned (YouTube, Wikipedia).

Have you been able to replicate the issue or is it working for yourself?

droe commented 6 years ago

I tried but I cannot reproduce this problem. I can intercept traffic to Wikipedia just fine with Chrome on macOS.

LeosSire commented 6 years ago

Would it be worth me issuing you a copy of the certs my OpenSSL produces? I used your GNUmakefile and used the rsa cert and key.

I have used the most up to date OpenSSL. What version are you using?

droe commented 6 years ago

I'm using OpenSSL 1.0.2o. Perhaps a pcap of both the network traffic before and after sslsplit could help narrowing down what's happening.

LeosSire commented 6 years ago

Tcpdump suffice?

droe commented 6 years ago

tcpdump -w, sure

droe commented 6 years ago

You can mail it to me instead of posting here if you prefer

droe commented 6 years ago

Can you retest with lastest develop after the commit referenced in #189 ?

LeosSire commented 6 years ago

Good afternoon Daniel.

I tried the latest develop last night.

All the raw code, only change was adding the 'CFLAG -lfts' to the GNUmakefile.

I am using a program called tinyproxy to upstream any connections to SSLSPLIT that are intended for google.com as I know this works with SSLSPLIT.

When the connection is received by SSLSPLIT it returns "Peeking did not yield a (truncated) ClientHello message, aborting connection"

By my reckoning the connection is being forwarded too late after the handshake has commenced, as the first proxy needs to determine the destination and isn't issuing the full details to SSLSPLIT.

I presume sslsplit works on a much lower level of the network where iptables/netfilter sits and the proxy I'm using is too high level.

This leaves me to two questions.

  1. Can SSLSPLIT try retrying a connection to reattain the connection details from those passed to it?

  2. Can we put a string comparison near the SNI PEEK code to confirm the SNI is google who whatever. Set a ctx variable to confirm this connection will be split. Otherwise passthrough. I have tried doing the opposite of this and passing-through anything with YouTube in the SNI but it fails on the passthrough due to unsafe memory. I set the bypass variable just after the code where the sni peek is printed to debug. And adding the bypass variable to the 3 if statements at "/ wrap client-side socket in a buffer event/" line 1874 of pxyconn.c

Before you ask I set he bypass variable to 0 on new ctx and disposed of it with a free() at the destroy ctx.

Thank you.

Joe

Sent from my iPhone

droe commented 6 years ago

"Peeking did not yield a (truncated) ClientHello message, aborting connection" means that sslsplit was unable to parse the SSL/TLS ClientHello message. If this is happening, capture the respective SSL/TLS connection in a PCAP, make sure that it is actually a ClientHello, and then open a separate issue on that.

Until I have a reproducible test case I cannot do much, I'm afraid.

Why are you adding libfts if you did not change any code?

droe commented 6 years ago

As an afterthought, please provide details on the platform and build environment. If this is some weird libc without fts(3), then I suspect your platform may be part of the problem.

LeosSire commented 6 years ago

Hello Daniel,

Apologies for the long delay.

I have been trying to figure out what has been going on.

My platform is OpenWRT a POSIX Linux OS for small embedded systems.

I have found something interesting.

Google.co.uk works find, Google.com does not.

Google.com reports the same error as youtube.

I have attached two pcap files, one for google.com the other for google.co.uk

From what I can see the browser is listing the connection as insecure due to the transmitions being received out of order? or being retransmitted?

Please let me know when you have chance to look into this?

Thank you,

Joe

droe commented 5 years ago

Joe, can you test drive branch issue/195 for me to see if the change fixes the issue you are having? It fixes the keyUsage field to be in line with the actual leaf key type instead of copying it from the upstream certificate.

LeosSire commented 5 years ago

Morning Daniel,

I will have a look this evening.

Cheers,

Joe

droe commented 5 years ago

If you start chromium-browser from a terminal, you will see the numerical NSS error code in error output that more specifically narrows down why Chromium raises NET::ERR_CERT_INVALID. If it's -8102 (SEC_ERROR_INADEQUATE_KEY_USAGE), that would be a strong indication that the root cause is the same as for isse #195. If it is something else, that number helps further investigation.

LeosSire commented 5 years ago

Good evening Daniel,

I compiled and tested and its still reporting the same issue on the YouTube App, output attached.

Google.com doesn't work either,

I'm not in a position to close chrome down to start via CLI.

Thank you for your efforts,

Joe

On Sun, 15 Jul 2018 at 15:59, Daniel Roethlisberger < notifications@github.com> wrote:

If you start chromium-browser from a terminal, you will see the numerical NSS error code in error output that more specifically narrows down why Chromium raises NET::ERR_CERT_INVALID. If it's -8102 ( SEC_ERROR_INADEQUATE_KEY_USAGE), that would be a strong indication that the root cause is the same as for isse #195 https://github.com/droe/sslsplit/issues/195. If it is something else, that number helps further investigation.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/droe/sslsplit/issues/188#issuecomment-405097595, or mute the thread https://github.com/notifications/unsubscribe-auth/ABRexd35Az5_GeGUUtsRzZ4SlSXEdiDeks5uG1jkgaJpZM4Suxr5 .

droe commented 5 years ago

Okay, please let me know the NSS error code when/if you have the opportunity to run Chrome or Chromium from a terminal.

aboulfad commented 5 years ago

Hi Daniel, I am trying to debug a bunch of Chrome cert errors as I am using sslsplit; running either Chrome or Chromium from osx terminal does not show the NSS error code. Even dev tools do not show any error codes.

Regards! PS: thank u very much for an awesome tool, so much to learn ...

droe commented 5 years ago

@aboulfad Please open a separate issue for your problem.

GHXST01 commented 5 years ago

Hey, could you try a certificate with an expiration date of less than 39 months? Google with Android 7.0 has been throwing certificate errors in it's applications when the root certificate has an validity of more than 39 months. I haven't checked in the desktop browser however, but know for sure this was one of the issues I ran into with Android.

droe commented 5 years ago

I would expect the 39 months limit to only be effective for issued certificates, not CA certificates. We are not generating any leaf certificates with a lifetime longer than a year, so we should not run into this issue. Nevertheless, I've reduced the validity period of the default CA certificate in extra/pki to 3 years.

GHXST01 commented 5 years ago

Hey @droe I managed to find my source, I should have looked for this when I made my comment.

Original article I read: https://blog.nviso.be/2018/01/31/using-a-custom-root-ca-with-burp-for-inspecting-android-n-traffic/

Links to source: https://bugs.chromium.org/p/chromium/issues/detail?id=475745

It does indeed seem to be the leaf certificates that are mentioned, not the CA, apologies.