Hi, we get the following verification problem in our product, because
some servers like signin.ebay.de, comdirect.de or meine.deutsche-bank.de
add additional certicates to the chain, which are needed for some
clients but not for others. Unfortunatly these are not minor companies
and all of the certificates are EV.
Tests done with various openssl versions from 0.9.7j up to 1.0.0a on
OpenBSD and 1.0.0e and 1.0.1beta2 on Ubuntu 11.10.
Details:
The server sends 3 certificates (cert3, cert2 and cert1) while the client
has certB and/or certR as a trusted root certificate.
certR signs cert1, while certB signs cert2 by using the same public key
as cert1.
The certificate hierarchy as a picture:
-
| Cert3 |
| | |
| Cert2 --
| | ||
| Cert1 ||
|___|___||
||
||
CertR -\ CertB -\
|| ||
cert3.pem
- ..CN=meine.deutsche-bank.de
- SHA1 Fingerprint=6C:F2:11:14:DC:4F:77:95:1A:67:63:E1:64:2B:AE:2F:DF:33:EB:BC
cert2.pem
- ..CN=VeriSign Class 3 Extended Validation SSL SGC CA
- SHA1 Fingerprint=B1:80:39:89:98:31:F1:52:61:46:67:CF:23:FF:CE:A2:B0:E7:3D:AB
cert1.pem
- ..CN=VeriSign Class 3 Public Primary Certification Authority - G5
- SHA1 Fingerprint=29:B7:3D:9F:75:01:B8:C0:AD:FD:5E:43:37:A3:90:D1:AD:20:5F:48
certB.pem
- ..CN=VeriSign Class 3 Public Primary Certification Authority - G5
- SHA1 Fingerprint=4E:B6:D5:78:49:9B:1C:CF:5F:58:1E:AD:56:BE:3D:9B:67:44:A5:E5
- this has the same public key as cert1, but is self signed
certR.pem
- C=US, O=VeriSign, Inc., OU=Class 3 Public Primary Certification Authority
- SHA1 Fingerprint=74:2C:31:92:E6:07:E4:24:EB:45:49:54:2B:E1:BB:C5:3E:61:74:E2
- this is very old but still valid, but MD2/RSA signed and thus probably not
added in some products
(it's not in /etc/ssl/certs on Ubuntu 11.10)
The following tests will be done
- openssl verify -verbose -CAfile chain21.pem cert3.pem
cat cert2.pem cert1.pem chain21.pem
will FAIL because neither certB nor certR are present and so no root is found
- openssl verify -verbose -CAfile chain21R.pem cert3.pem
cat cert2.pem cert1.pem certR.pem chain21R.pem
will SUCCEED because a complete hierarchy to the root can be found:
cert3 - cert2 - cert1 - certR
- openssl verify -verbose -CAfile chain2B.pem cert3.pem
cat cert2.pem certB.pem chain2B.pem
will SUCCEED because a complete hierarchy to the root can be found:
cert3 - cert2 - certB
so far everything is like expected, but it gets interesting if we have
both cert1 and certB. Note that cert1 has the same public key as certB
so that both certificates sign cert2.
- openssl verify -verbose -CAfile chain21B.pem cert3.pem
cat cert2.pem cert1.pem certB.pem chain21B.pem
The expected thing is, that it will succeed because it can verify
cert3 - cert2 - cert B and just ignore cert1.
But it FAILs because it tries cert3 - cert2 - cert1 - .. and then it
is missing certR
- openssl verify -verbose -CAfile chain2B1.pem cert3.pem
cat cert2.pem certB.pem cert1.pem chain2B1.pem
same certificates as last test, but this time certB is before cert1.
I would expect, that the order does not matter, but this SUCCEEDs
because of cert3 - cert2 - certB and it ignores cert1
And this is where the bug is: one should expect, that it ignores an
the unneeded cert1 in both cases, but the behavior depends on the order
of the certicates in the chain.
The bug causes konqueror (using openssl) to fail on certificate check,
while Chrome and firefox (using NSS) succeed. At least FF seems to
have certR too, but uses certB, probably because the trust chain is
shorter. Opera on Linux and MSIE8 on Windows XP succeed too, also using
certB and not certR for verification.
A similar problem was already reported, but w/o response:
http://rt.openssl.org/Ticket/Display.html?id=2634
and maybe http://rt.openssl.org/Ticket/Display.html?id=1851
is also related.
If you need more information or tests please let me know.
Regards,
Steffen Ullrich
--
GeNUA Gesellschaft für Netzwerk - und Unix-Administration mbH
Domagkstr. 7, D-85551 Kirchheim. http://www.genua.de
Tel: (089) 99 19 50-0, Fax: (089) 99 10 50 - 999
Geschäftsführer: Dr. Magnus Harlander, Dr. Michaela Harlander,
Bernhard Schneck. Amtsgericht München HRB 98238
Certificate:
Data:
Version: 3 (0x2)
Serial Number:
57:bf:fb:03:fb:2c:46:d4:e1:9e:ce:e0:d7:43:7f:13
Signature Algorithm: sha1WithRSAEncryption
Issuer: C=US, O=VeriSign, Inc., OU=Class 3 Public Primary Certification
Authority
Validity
Not Before: Nov 8 00:00:00 2006 GMT
Not After : Nov 7 23:59:59 2021 GMT
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
