0

Nessus is reporting that an "SSL Certificate Cannot Be Trusted".

This is due to the intermediate certificate not being in the certificate bundle presented during the TLS/SSL handshake.

I've looked at a couple of similar threads:

This isn't an issue as most browsers will download intermediate certificates.

If I try with openssl to verify the certificate:

openssl s_client -connect example.com:443 -showcerts </dev/null

The output only shows the first cert and then an unable to get local issuer certificate error.

Or if I try https://testssl.sh/ I get the same error:

Chain of trust               NOT ok (chain incomplete)

Is there any method that I can use that acts in the way a browser would and downloads any intermediate certs?

Even if there's a way to identify where to download intermediate certs from I am happy to code something up that would do this, but it's just knowing what to look for in the server certificate response.

Update

Running

openssl x509 -in g0 -text

gives the AIA information for the intermediate cert download URLs

Authority Information Access: 
                OCSP - URI:http://ocsp.int-x3.letsencrypt.org
                CA Issuers - URI:http://cert.int-x3.letsencrypt.org/

Then we can run:

wget http://cert.int-x3.letsencrypt.org/ -O intermed.der

Then

openssl x509 -inform DER -in intermed.der -out intermed.pem -outform PEM

Then

openssl x509 -in intermed.pem -text

Which gives

 Authority Information Access: 
                OCSP - URI:http://isrg.trustid.ocsp.identrust.com
                CA Issuers - URI:http://apps.identrust.com/roots/dstrootcax3.p7c

But this is in a different format and trying to convert it gives an error:

openssl pkcs7 -print_certs -in dstrootcax3.p7c -out dstrootcax3
unable to load PKCS7 object
139884641126208:error:0906D06C:PEM routines:PEM_read_bio:no start line:crypto/pem/pem_lib.c:691:Expecting: PKCS7

Regarding Steffen Ullrich's comment, this makes sense and would explain why it sometimes works better than the certificate not being able to be downloaded. However, I'd still like to figure this one with the end goal of using openssl to verify the whole chain including downloadable intermediate certs.

SilverlightFox
  • 33,408
  • 6
  • 67
  • 178
  • 1
    *"This isn't an issue as most browsers will download intermediate certificates."* - From my experience Chrome Desktop seems to download missing certificates, Firefox seems to fill it only from intermediates cached from previous connections to other sites and mobile browsers usually expect the full chain or fail. – Steffen Ullrich Nov 07 '17 at 15:18
  • Good point. Shame Nessus doesn't report this as such (unless I'm missing something?). Not much of an issue for a couple of sites, but for large pentests it makes it hard to provide concise information in the report. – SilverlightFox Nov 07 '17 at 15:43
  • The TLS spec states that all CA certificates in the chain (Root is optional) should be presented in the handshake. Instead of downloading them and masking the issue as you're proposing, you should simply abuse the server admins until they correctly configure their servers. AIA simply hides bad practices by server admins. – garethTheRed Nov 07 '17 at 19:54
  • That `.p7c` can be read with `openssl pkcs7` by adding `-inform der` . But better to get DSTRootCAX3 from a local, good truststore (Windows Mozilla and recent Java definitely have it; Apple I expect but can't confirm) because validating against a root from a good truststore provides at least some security while trusting a root you found following a received chain provides no security at all. – dave_thompson_085 Nov 08 '17 at 00:31

0 Answers0