> From: [email protected] On Behalf Of Mihalenko, Walter via RT > Sent: Wednesday, 30 January, 2013 16:30
> I am curious as to the difference between loading a > validating a server certificate such as found on > https://innovation01.acs-ops.com using the "openssl s_client" > command and using a web browser. They result in different > certificate chains, diverging at the "VeriSign Class 3 Public > Primary Certification Authority - G5" level. My web browser > seems to find this cert to be self signed, where as openssl > finds it to be an intermediate certificate signed by > Verisign. This is true for the both versions of openssl I > have tested (0.9.8 and 1.0.1c). > I assume, since you don't mention it, you aren't using -CAfile or -CAdir, or envvars SSL_CERT_*, to select a truststore. You also don't say what the verify result was. A real webbrowser like IE,FF,Chrome that finds a server cert verification error will put up an error dialog and refuse to continue without explicit manual action if at all, but s_client simply displays the verify callback steps near the top and the final verify return code at the bottom of the "SSL-Session", and carries on. I assume the callback "returns" are 1 (true) and the final verify return is 0 i.e. the server cert chain DID verify using the default truststore for openssl on your system(s?). Official OpenSSL has no default truststore; or exactly, a build of OpenSSL has a default location for the truststore but no contents (CA certs) placed in it. Presumably either: - you are using a package of OpenSSL built by someone who added some set of CA certs s/he considered wise - you have some other package(s) installed on your system that installed CA certs in OpenSSL's truststore (e.g. on Linux I believe curl does this BICBW) - someone just placed some root certs, and possibly chain certs, chosen somehow, in the truststore on your system (I assume you didn't do this, as you don't mention it) If you have two versions of openssl on the same system, built the same way, they are likely using the same default truststore. That will work for a CAfile format truststore (defaulting to OPENSSLDIR/cert.pem) but not necessarily a CApath format one (OPENSSLDIR/certs/) which uses links/names based on the hash of the subject, since the hash algorithm changed 0.9.8 to >=1.0.0. Although if you're careful you probably can put both oldhash and newhash links in one directory and I think it would work. > What mechanism is causing the divergence? The chain that > Windows recognizes would seem to suggest that I can supply > those certificates as trusted and validation should succeed, > but if a different chain is generated via openssl this is > invalid. It is causing problems in how organizations can > find what certificates they need to add as trusted. > There are legimately two chains. When Verisign upgraded to the class3-G5 root in 2010 (because RSA 2048bit was then required or at least believed required) they provided a transition chain back to the 1996 "G1" root to allow support of clients that didn't then have the G5 root, and may still not. ("G1" in quotes because it isn't stated in the cert, it's retroactive. I ran into this recently with some Java apps running on a 3-year-old JRE version which for reasons not relevant here couldn't be upgraded.) See https://knowledge.verisign.com/support/ssl-certificates-support/ index?page=content&id=AD220&actp=LIST&viewlocale=en_US and especially the picture in https://knowledge.verisign.com/support/ssl-certificates-support/ index?page=content&actp=CROSSLINK&id=AR1462 (links broken for posting, paste back together). If browser/Windows has both old=G1 and new=G5 roots, it could simply choose to use and/or display the shorter, or newer, or otherwise more convenient path (unless the child has AKI with issuer&serial, which this one doesn't and IME Verisign doesn't). (If the browser is IE or Chrome I believe they are actually using platform MSCAPI logic here, but I'm not positive.) OpenSSL does not; it uses the chain supplied by the peer (server) and adds to the end from the local truststore as needed (and replaces only the (selfsigned) root with a local trusted copy). You might try temporarily removing the G5 root from your Windows (or browser?) truststore and see if it then finds and accepts the transition chain to G1. ______________________________________________________________________ OpenSSL Project http://www.openssl.org Development Mailing List [email protected] Automated List Manager [email protected]
