Name is required.
Email address is required.
Invalid email address
Answer is required.
Exceeding max length of 5KB

SSL certificate finding

ILGUIZ LATYPOV Mar 20, 2019 12:29PM UTC

BURP 2.0.18Beta issued a finding about our site's SSL certificate. I believe it found a seeming inconsistency between the "alt" DNS names allowed by the certificate and the host name. But the site presents a different, proper certificate when sending the "Server Name Indication" (SNI) in opening the SSL connection. BURP should send SNI to get the proper SSL certificate and ciphers.


Paul Johnston Mar 21, 2019 12:09PM UTC Support Center agent

Burp will normally send the SNI. This configuration in User options > SSL > Disable Java SNI – so please check that settings is not enabled.


ILGUIZ LATYPOV Mar 27, 2019 03:58PM UTC
I just realized you might be right and my analysis of the cause was wrong.

So let me just dump one of the original findings that I believe was a false positive and suggest and new possible cause of the bug.

======================================
Severity: Medium
Confidence: Certain
Host: https://oauth-edge-service-ext-dev.apps.cac.preview.pcf.manulife.com
Path: /

Issue detail
The following problem was identified with the server's SSL certificate:

The server's certificate is not trusted.

Note: Burp relies on the Java trust store to determine whether certificates are trusted. The Java trust store does not include every root CA certificate that is included within browser trust stores. Burp might incorrectly report that a certificate is not trusted, if a valid root CA certificate is being used that is not included in the Java trust store.

The server presented the following certificates:

Server certificate
Issued to: pcf.manulife.com, *.apps.cac.preview.pcf.manulife.com, *.apps.pcf.manulife.com, *.cac.preview.pcf.manulife.com, *.login.sys.cac.preview.pcf.manulife.com, *.login.sys.pcf.manulife.com, *.pcf.manulife.com, *.sys.cac.preview.pcf.manulife.com, *.sys.pcf.manulife.com, *.uaa.sys.cac.preview.pcf.manulife.com, *.uaa.sys.pcf.manulife.com

Issued by: COMODO RSA Organization Validation Secure Server CA
Valid from: Tue Apr 18 20:00:00 EDT 2017
Valid to: Sat Apr 18 19:59:59 EDT 2020

Certificate chain #1
Issued to: COMODO RSA Certification Authority
Issued by: COMODO RSA Certification Authority
Valid from: Mon Jan 18 19:00:00 EST 2010
Valid to: Mon Jan 18 18:59:59 EST 2038

Certificate chain #2
Issued to: COMODO RSA Organization Validation Secure Server CA
Issued by: COMODO RSA Certification Authority
Valid from: Tue Feb 11 19:00:00 EST 2014
Valid to: Sun Feb 11 18:59:59 EST 2029

Certificate chain #3
Issued to: COMODO RSA Certification Authority
Issued by: COMODO RSA Certification Authority
Valid from: Mon Jan 18 19:00:00 EST 2010
Valid to: Mon Jan 18 18:59:59 EST 2038

======================================

I see that the "alt DNS" entries look all right and that one of them (*.apps.cac.preview.pcf.manulife.com) accepts the host name. My new theory goes that the fist certificate in chain appears misinterpreted by BURP. Connecting with openssl I see a server certificate first (pcf.manulife.com by COMODO Organizational), the root cert next (COMODO by COMODO), and the intermediary cert last (COMODO Organizational by COMODO). The last two entries in BURP's output seem all right (thanks for proper ordering, too). But the first entry (COMODO by COMODO) appears misrepresent the server's certificate (pcf.manulife.com by COMODO Organizational). Apologies for not having an externally visible test case.

Paul Johnston Mar 27, 2019 04:06PM UTC Support Center agent

When Burp says “The server’s certificate is not trusted.” it means the root CA isn’t in the Java store. It’s not related to the host name; that reports as “The server’s certificate is not valid for the server’s hostname.”


ILGUIZ LATYPOV Mar 28, 2019 06:19PM UTC
Thanks for reminding about the root certificate. I just checked it in the cacert Java store of the JRE used by BURP. It had the same fingerprint as the one extracted by openssl from the connection to the server.

$ openssl x509 -in oauth-edge-service-ext-dev_apps_cac_preview_pcf_manulife_com_443-cert-01-COMODO_RSA-COMODO_RSA.pem -fingerprint -sha1 -noout
SHA1 Fingerprint=AF:E5:D2:44:A8:D1:19:42:30:FF:47:9F:E2:F8:97:BB:CD:7A:8C:B4

$ "${jre}/bin/keytool" -keystore "${jre}/lib/security/cacerts" -storepass changeit -list -alias "comodorsaca [jdk]"
comodorsaca [jdk], 25-Aug-2016, trustedCertEntry,
Certificate fingerprint (SHA1): AF:E5:D2:44:A8:D1:19:42:30:FF:47:9F:E2:F8:97:BB:CD:7A:8C:B4

$ echo "${jre}"
/Library/Java/JavaVirtualMachines/jdk1.8.0_191.jdk/Contents/Home/jre

Paul Johnston Apr 01, 2019 02:00PM UTC Support Center agent

Thanks for following up. Is this site publicly accessible? If you could email the URL to support@portswigger.net we can investigate. We’ll only do the lightweight SSL probes and not any heavyweight scanning.


ILGUIZ LATYPOV Apr 08, 2019 01:49AM UTC
This should do:

https;//cac.mesh.preprod.api.manulife.com

ILGUIZ LATYPOV Apr 11, 2019 01:55PM UTC
I typed a semicolon instead of a colon in the https address above, sorry. The host name resolves in global DNS, and BURP incorrectly deciphers the cert chain as if it misses the server's own cert.

Paul Johnston Apr 11, 2019 01:59PM UTC Support Center agent

Thanks for clarifying. I wasn’t able to reproduce the issue. As you’ve confirmed it’s a false positive you can ignore it.


Post Your public answer

Your name
Your email address
Answer