reassign 640457 konqueror thanks On Sun, Oct 16, 2011 at 11:54, Maximilian Engelhardt <m...@daemonizer.de> wrote: > On Friday 14 October 2011 07:28:00 Kyle Moffett wrote: >> > 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". > > Hello Kyle, > > thanks for your detailed explanation. So this seems to be a Konqueror bug, > perhaps even an upstream KDE bug. > > On the other hand this might also be a ca-certificates bug, since it doesn't > ship the old Verisign root certificate anymore, but without that certificate > openssl will fail to verify any chain that uses it (and it seems to be wildly > used).
No, ca-certificates still ships the old Verisign root certificate. What changed is that the website you were accessing upgraded from their old certificate (issued with the old Verisign root) to a new one (issued by the new Verisign root), but they did not fix their certificate chain file to match. > I'm not really sure if it's a Konqueror or a ca-certificates bug, so feel free > to reassign it to whatever you think fits best, perhaps Konqueror, as you did > suggest in your last mail. I have reassigned this bug to konqueror. > I'm wondering how many other programs that use openssl experience the same > problem. This is an extremely common error among website operators, as most of the TLS implementations don't actually have very good diagnostics for identifying and fixing the issue. I have had this exact same issue myself with SMTP TLS, and the fix involved a configuration change on the server. In this case, it is very definitely a server misconfiguration. The only question is: How far should web browsers and TLS clients go in verifying server certificates when the server is providing a garbage certificate chain? It's the same fundamental issue with the "Be strict in what you admit and lenient in what you accept" policy that has plagued HTML; at some point you have a bunch of disparate implementations and *none* of them are compliant with the standards because most of the others are willing to tolerate most of the bugs. Cheers, Kyle Moffett -- Curious about my work on the Debian powerpcspe port? I'm keeping a blog here: http://pureperl.blogspot.com/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
