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

[Vít Ondruch]

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