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