ca-certificates 2014.2.1 will remove several still valid CA certificates with weak keys

[Kai Engert]

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