[openssl-dev] [openssl.org #2634] Cross-signed certs rejected by OpenSSL because root cert not base of chain

[nagle@sitetruth.com via RT]

This is an old bug from 2011, generated originally by someone who put a
self-signed cert in their cert chain.  Until now, it's been ignored.
It's become a big problem now that Verisign cross-signed one of their
major root certs (VeriSign Class 3 Public Primary Certification
Authority - G5). Their root cert is thus no longer the base of a
chain, and is rejected by OpenSSL. This bug now comes up if you use
Mozilla's root cert store with Python. It's affecting some major
web sites and systems which use OpenSSL are struggling to deal
with this defect.

I reported the bug for Python:
http://bugs.python.org/issue23476
and the Python developers blame this OpenSSL bug. There's code
there to reproduce the bug.

Ubuntu has a workaround:
https://bugs.launchpad.net/ubuntu/+source/openssl/+bug/1014640
which involves modifying the cert file.  (The order of the
certificates in the cert file may be significant.  Not sure
about this.)

The developers of the "request" add-on for Python's HTTP client
have a different workaround, also involving using a different
certificate bundle.
https://github.com/kennethreitz/requests/issues/2455

See also this proposed patch from 2012:
http://rt.openssl.org/Ticket/Display.html?id=2732
"2634: Fail to verify server with a trusted CA root in the middle of the
chain".

The problem can be reproduced with the OpenSSL command line client,
but only on some platforms. See the comments in the Python bug report:

"I have determined that s_client is buggy. It will always load the
system certs *if and only if* you also pass it a valid custom CA cert
(which is the reverse of what's expected)."

"Antione closed this, as a not python error, as
if you do not pass a valid certificate to openssl s_client
it will not read the system certificates, which is clearly
utterly surprising and nuts."

So three different development teams now agree it's an OpenSSL bug.

 John Nagle