Dne 6.9.2014 01:58, Kai Engert napsal(a): > On Tue, 2014-08-26 at 12:36 +0200, Vít Ondruch wrote: >> $ gem fetch power_assert >> ERROR: Could not find a valid gem 'power_assert' (>= 0), here is why: >> Unable to download data from https://rubygems.org/ - >> SSL_connect returned=1 errno=0 state=SSLv3 read server certificate B: >> certificate verify failed >> (https://s3.amazonaws.com/production.s3.rubygems.org/latest_specs.4.8.gz) > The gem tool appears to use openssl. That is correct. > > $ openssl s_client -showcerts -connect rubygems.org:443 2>&1 \ > |grep "Verify return code" > Verify return code: 0 (ok) > > $ openssl s_client -showcerts -connect s3.amazonaws.com:443 2>&1 \ > |grep "Verify return code" > Verify return code: 20 (unable to get local issuer certificate) > > 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: > > With the recent upstream update 2.1 this certificate was disabled for > the SSL/TLS use, see: > https://bugzilla.mozilla.org/show_bug.cgi?id=986005 > > (Symantac/Verisign was aware, cc'ed on the bug, and didn't object.) > > 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. > > The intermediate certificate sent by the server at level 1 was issued > by: > 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 > > 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. Thanks for the detailed analysis. I could learn something new from it :) > > I believe that we must contact Amazon and Symantec about this issue. > Amazon should remove the second intermediate, ending the path with the > G5 intermediate. This will allow openssl to find the trusted root CA. > > Also, Symantec should reach out to all of their customers and tell them > you update their configuration. > > I will contact them. Great! Thanks. Should I open ticket against ca-certificates to keep track about this issue? > > 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 was told by Tomáš Mráz that recent OpenSSL can do something like this, but it is not enabled by default, so it is hardly useful for this case. Vít -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
