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. $ 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. 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. 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). Kai -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
