[Pkg-openssl-devel] Bug#640457: [openssl] some Verisign certificates fail to verify

[Kyle Moffett]

> 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