On Sat, 2014-09-06 at 01:58 +0200, Kai Engert wrote: > The failure is with the s3.amazonaws.com host. > Looking at the certificates the server sends: > $ openssl s_client -showcerts -connect s3.amazonaws.com:443 2>&1 \ > |egrep " s:| i:" > 0 s:/C=US/ST=Washington/L=Seattle/O=Amazon.com Inc./CN=s3.amazonaws.com > i:/C=US/O=VeriSign, Inc./OU=VeriSign Trust Network/OU=Terms of use at > https://www.verisign.com/rpa (c)10/CN=VeriSign Class 3 Secure Server CA > - G3 > 1 s:/C=US/O=VeriSign, Inc./OU=VeriSign Trust Network/OU=Terms of use at > https://www.verisign.com/rpa (c)10/CN=VeriSign Class 3 Secure Server CA > - G3 > i:/C=US/O=VeriSign, Inc./OU=VeriSign Trust Network/OU=(c) 2006 > VeriSign, Inc. - For authorized use only/CN=VeriSign Class 3 Public > Primary Certification Authority - G5 > > 2 s:/C=US/O=VeriSign, Inc./OU=VeriSign Trust Network/OU=(c) 2006 > VeriSign, Inc. - For authorized use only/CN=VeriSign Class 3 Public > Primary Certification Authority - G5 > i:/C=US/O=VeriSign, Inc./OU=Class 3 Public Primary Certification > Authority > > This means, the server sends three certificates during the handshake. > One server cert, and two intermediates. > > The intermediate at level 2 was issued by root CA: > C=US > O=VeriSign, Inc. > OU=Class 3 Public Primary Certification Authority > This root CA is very old, it had been issued in 1996: > [...] > When connecting to this server using an NSS client, such as Firefox, it > works. I believe this is because an alternative trust chain can be > found. Unfortunately only NSS works. Both openssl and gnutls fail to connect to popular sites because of that change. It should not be assumed that the users of ca-certificates are only programs using nss. > A root CA with this subject is included in our trust list. > So, NSS can find this root CA cert, and succeeded the verification, and > ignores the unnecessary, additional intermediate CA cert sent by the > server. > I guess that openssl strictly wants to make use of all intermediates > sent by the server, and doesn't search for alternative chains. And the > only certificate satisfying this chain has been marked as untrusted for > SSL/TLS in our update. I guess this is verification based on the rfc5280 path validation. Unlike that NSS ignores the provided trust chain and tries to construct a new one internally. That's interesting and happens to work around the issue here but it is not and must not be required for all software to reconstruct trust chains. The TLS is very specific on that issue, the chain is provided by the server. > If we want things to just work, without requiring server administration, > then openssl should be enhanced to try additional chains, (or the Ruby > software could be changed to use NSS). I do not agree. Such changes are dangerous to be performed on a stable release, and may introduce more issues than solve. Ca-certificates should not assume that NSS is its only user. That is either (1) it should include the trusted certificates that are still in wild use, or (2) it should include the intermediates of the trusted certificates that are in use. regards, Nikos -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
