Updating app-misc/ca-certificates from 3.17.2 to 3.17.4 breaks openssl access to some websites, because some old certificates have been removed from NSS 3.17.3. For example, https://mandrill.com and https://mandrillapp.com can't be accessed by openssl-based softwares, including curl and epiphany for me: $ openssl s_client -connect mandrillapp.com:443 CONNECTED(00000003) depth=2 C = US, O = "thawte, Inc.", OU = Certification Services Division, OU = "(c) 2006 thawte, Inc. - For authorized use only", CN = thawte Primary Root CA verify error:num=20:unable to get local issuer certificate --- Certificate chain 0 s:/C=US/ST=Georgia/L=Atlanta/O=The Rocket Science Group, LLC/OU=Product Dev/CN=mandrillapp.com i:/C=US/O=thawte, Inc./CN=thawte SSL CA - G2 1 s:/C=US/O=thawte, Inc./CN=thawte SSL CA - G2 i:/C=US/O=thawte, Inc./OU=Certification Services Division/OU=(c) 2006 thawte, Inc. - For authorized use only/CN=thawte Primary Root CA 2 s:/C=US/O=thawte, Inc./OU=Certification Services Division/OU=(c) 2006 thawte, Inc. - For authorized use only/CN=thawte Primary Root CA i:/C=ZA/ST=Western Cape/L=Cape Town/O=Thawte Consulting cc/OU=Certification Services Division/CN=Thawte Premium Server CA/emailAddress=premium-server@thawte.com $ curl https://mandrill.com curl: (60) SSL certificate problem: unable to get local issuer certificate More details here: http://curl.haxx.se/docs/sslcerts.html As explained in a mozilla bug report (https://bugzilla.mozilla.org/show_bug.cgi?id=986014) and in the release notes (https://developer.mozilla.org/en-US/docs/Mozilla/Projects/NSS/NSS_3.17.3_release_notes), some old root certificates have been removed in 3.17.3. According to the comments of this bug, these certificates are no longer needed by the top 200000 websites. In firefox 36, a version where these old certificates have been removed, everything is OK, I can reach https://mandrill.com/. It's quite normal for me, because the certificate at depth 1 is included in the root certificates of NSS, and there's no need to go further to trust this chain. Everything is also OK with gnutls: "gnutls-cli mandrill.com" gives me no error. On the contrary, openssl returns "unable to get local issuer certificate", because it can't find the certificate at depth 2. This certificate is the "Thawte Premium Server CA", one of the certificates that have been removed. Re-adding the "Thawte Premium Server CA" certificate or installing the previous app-misc/ca-certificates-20140927.3.17.2 version fixes the problem. Keeping old certificates at the end of a certificate chain seems to be a common practice to keep compatibility with old systems, and it shouldn't be a problem for SSL libraries as long as other certificates earlier in the chain are trusted. Is there anything wrong with my OpenSSL installation? Reproducible: Always Steps to Reproduce: 1. Launch "openssl s_client -connect mandrillapp.com:443" Actual Results: depth=2 C = US, O = "thawte, Inc.", OU = Certification Services Division, OU = "(c) 2006 thawte, Inc. - For authorized use only", CN = thawte Primary Root CA verify error:num=20:unable to get local issuer certificate Expected Results: Get a connection open with no "verify error".
the websites in question should be providing the full cert chain from their server. i understand that most likely would be hard to get a website to fix their configuration, but that's how it is. we're not carrying certs above & beyond what mozilla's nss is. see bug 485474 for details.
(In reply to SpanKY from comment #1) > the websites in question should be providing the full cert chain from their > server. Actually, as far as I can tell, they do. The problem is caused by an extra certificate at the end of the chain that is not trusted anymore, but as an intermediate certificate is trusted, it should be no problem. > i understand that most likely would be hard to get a website to fix > their configuration, but that's how it is. we're not carrying certs above & > beyond what mozilla's nss is. > > see bug 485474 for details. Sorry for being so *********, but that's not exactly the same bug. With the same certificates and the same chain, NSS and GnuTLS work, but OpenSSL don't. I really understand that carrying only Mozilla's certs is an easy and quite good choice. But Mozilla chose the certificates according to which websites work with NSS, and I just wanted to tell that working with NSS is not the same as working with OpenSSL (and that's probably unfortunate). Important websites such as mandrill.com (ranked 8,665 on Alexa) and indiegogo.com (1,042) are now broken with OpenSSL, even if they provide a "good" cert chain (at least for NSS and GnuTLS).
@ Guillaume: OpenSSL is very strict: If you provide a trust chain, OpenSSL will use this chain. OpenSSL doesn't try to create an alternative chain in that case but GnuTLS does. mandrillapp.com sends the following chain: 0: mandrillapp.com ================== SHA1 Fingerprint=DA:15:24:4F:F9:26:9B:F1:3B:A5:44:8B:EA:13:35:2E:87:96:41:F2 Hash=2c791b55 Issuer=thawte SSL CA - G2 Authority Key=C2:4F:48:57:FC:D1:4F:9A:C0:5D:38:7D:0E:05:DB:D9:2E:B5:52:60 1: thawte SSL CA - G2 ===================== SHA1 Fingerprint=2E:A7:1C:36:7D:17:8C:84:3F:D2:1D:B4:FD:B6:30:BA:54:A2:0D:C5 Hash=9ad474ec Issuer=thawte Primary Root CA Key Identifier=C2:4F:48:57:FC:D1:4F:9A:C0:5D:38:7D:0E:05:DB:D9:2E:B5:52:60 Authority Key=7B:5B:45:CF:AF:CE:CB:7A:FD:31:92:1A:6A:B6:F3:46:EB:57:48:50 2: thawte Primary Root CA ========================= SHA1 Fingerprint=1F:A4:90:D1:D4:95:79:42:CD:23:54:5F:6E:82:3D:00:00:79:6E:A2 Hash=2e4eed3c Issuer=Thawte Premium Server Key Identifier=7B:5B:45:CF:AF:CE:CB:7A:FD:31:92:1A:6A:B6:F3:46:EB:57:48:50 The issuer from the last cert (#2, thawte Primary Root CA), SHA1 fingerprint 62:7F:8D:78:27:65:63:99:D2:7D:7F:90:44:C9:FE:B3:F3:3E:FA:9A (Hash 98ec67f0) was removed in NSS 3.17.3 [1]. As said, OpenSSL is strict. That's why it is failing now because #2 cannot be verified anymore. If mandrillapp.com wouldn't send #2 at all, verify would pass because #1 is in the trusted root store. That's something mandrill should fix. BUT (and that's the reason why I am posting): OpenSSL will change its behavior with openssl-1.1.0 to follow GnuTLS and others: See https://bugzilla.mozilla.org/show_bug.cgi?id=986005#c4 and http://rt.openssl.org/Ticket/Display.html?id=3637&user=guest&pass=guest [1] https://developer.mozilla.org/en-US/docs/Mozilla/Projects/NSS/NSS_3.17.3_release_notes
Really useful explanation, thank you!
*** Bug 548436 has been marked as a duplicate of this bug. ***
