Research Academy
My account Customers About Blog Careers Legal Contact Resellers
The Burp Suite User Forum was discontinued on the 1st November 2024.

Burp Suite User Forum

For support requests, go to the Support Center. To discuss with other Burp users, head to our Discord page.

SUPPORT CENTER DISCORD

SSL certificate finding

ILGUIZ | Last updated: 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.

PortSwigger Agent | Last updated: Mar 21, 2019 12:07PM UTC

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

Burp User | Last updated: 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.

PortSwigger Agent | Last updated: Mar 27, 2019 03:59PM UTC

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."

Burp User | Last updated: 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

PortSwigger Agent | Last updated: Mar 29, 2019 10:27AM UTC

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.

Burp User | Last updated: Apr 08, 2019 01:49AM UTC

This should do: https;//cac.mesh.preprod.api.manulife.com

PortSwigger Agent | Last updated: Apr 08, 2019 08:08AM UTC

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

Burp User | Last updated: Apr 11, 2019 01:55PM UTC