> So chain-0 can be verified by chain-1 and chain-1 can be verified by the > system installed CAs. > > The problem is that > VeriSign_Class_3_Public_Primary_Certification_Authority_-_G5.crt > got updated in ca-certificates 20110421. > And the last certificated sent by the server (chain-2) is the old version of > this same certificate. > > $ openssl x509 -noout -subject -issuer -in > /etc/ssl/certs/VeriSign_Class_3_Public_Primary_Certification_Authority_- > _G5.pem > subject= /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 > issuer= /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 > > So it seems like openssl first uses the certificate that's send from the > server, but then fails to verify it (as it can't find an appropriate root > certificate). Instead it should ignore the sent certificate and use the one > that is installed on the local system and thus trusted as root certificate. > > This behaviour is especially a problem for me since konqueror uses openssl to > verify the certificates and there are quite some sites that deliver the old > certificate in the chain. > > Also note that gnutls-cli --x509cafile /etc/ssl/certs/ca-certificates.crt -p > 443 signin.ebay.de" does verify the certificate just fine.
This PHP bug-report seems basically identical: https://bugs.php.net/bug.php?id=49419 Based on my understanding of TLS and from that PHP bug-report... I'm actually pretty sure that this is not a bug. According to the TLS standard (RFC2246): certificate_list This is a sequence (chain) of X.509v3 certificates. The sender's certificate must come first in the list. Each following certificate must directly certify the one preceding it. Because certificate validation requires that root keys be distributed independently, the self-signed certificate which specifies the root certificate authority may optionally be omitted from the chain, under the assumption that the remote end must already possess it in order to validate it in any case. The certificates passed in the protocol must be a strict sequence. Any server sending out-of-order or bogus certificates in the chain is not complying with the TLS protocol requirements, and cannot reasonably expect to validate correctly. It's entirely possible that some implementations are much more lenient than others, but the standard itself seems very obvious as to the requirement. As far as I can tell, OpenSSL implements a very safe default for SSL certificate chain construction and requires the application to implement a more advanced model if desired. This is basically a server configuration problem, and at best this should be a feature request against konqueror to better handle broken server configurations. Please note that GnuTLS has historically been missing a number of the stricter checks that OpenSSL provides by default, and that those tend to get added to GnuTLS when their absence is identified. For example, OpenSSL has always checked certificate validity times by default, but prior to CVE-2009-1417, the GnuTLS library relied upon the application to perform those checks (and most did not). Let me know if you want me to reassign this bug to konqueror or close it as "wontfix". Cheers, Kyle Moffett -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
