Home / server / Questions / 917333
Accepted
Kevin Buchs
Asked: 2018-06-20 08:53:10 +0800 CST

Seeking ground truth on TLS certificates and MacOS - browser, curl, openssl compared

  • 772

On a Mac, High Sierra 10.13.5, I'm seeing a difference in TLS certification validation. Chrome and Safari are happy with TLS validation when visiting https://www.visitflorida.com. Also, curl has no complaints and I am NOT using '-k'. However, openssl complains that it cannot find the intermediate certificate when trying this openssl s_client -connect www.visitflorida.com:443 < /dev/null | openssl x509 -subject -noout. I have used both the base openssl and brew-installed one.

I have tried to add in -CAfile intermediate.pem (where I downloaded the intermediate certificate from TrustWave). Even though the intermediate certificate does not appear anywhere in my KeyChain, I have exported my KeyChain System Roots into a single file and tried that via -CAfile also. Nothing is working. The only filesystem location I see certificates is /etc/ssl/cert.pem and when I specify that via -CAfile, it still fails.

Someone has suggested that my browsers and curl have a looser requirement for TLS validation than openssl. Is that really the case? I have a hard time believing it. Can anyone help me explain this behavior?

BTW, I know this can be resolved by including the intermediate certificate with the endpoint certificate on the TLS endpoint for www.visitflorida.com. Now if we could just find that missing key file!

Browser happiness: screenshot of browser validation

Curl log: curl output

ssl-certificate

1 Answers

  1. Best Answer

    Browsers, such as Internet Explorer/Edge, Chrome and Safari will look at the AIA extensions's caIssuer field for an URL from where it can download a superior CA's certificate if one is not provided by the server during the TLS handshake.

    Your website's certificate has a caIssuer field set to http://ssl.trustwave.com/issuers/OVCA2_L1.crt therefore all the above browsers will download it from that URL and use it to build the chain.

    Command line tools such as OpenSSL's s_client won't use the caIssuer to download this additional certificate, hence the situation you witnessed. If you were to try Mozilla Firefox, you'd notice the same there too as Mozilla refuse to use this extension.

    The caIssuer field ends up cloaking the real issue, which is bad server admin. RFC 5246 Section 7.4.2 dictates that the server must send a certificate_list consisting of its own certificate followed by any intermediate CA certificates.

    • 3