> From: owner-openssl-us...@openssl.org On Behalf Of Jakob Bohm > Sent: Monday, 25 February, 2013 03:18
> On 2/25/2013 4:26 AM, Dave Thompson wrote: <snip about verify-chain> > > The one limitation, implicit above, is "a" chain, singular. > > If there is more than one chain above a given cert or subtree -- > > e.g. Clam-Shack-CA has its own root but also is cross-certified > > by Certs-R-Us -- X509_verify_cert can only do one of them per call. > > > > My experience was with GlobalSign certs, they have an old 1024 bit > root and a new 2048 bit root. The 2048 bit root is also cross signed > by the old 1024 bit root to facilitate trust by old browsers that only > include the old root. I was double checking a combined chain file > before installing it on production web servers that need to work in > both scenarios. > Yes, that is exactly the case I referred to. For that you can verify the ...newroot chain as a whole, or the ...cross,oldroot chain as a whole, but not both at once. (Or you can verify leaf using imed,newroot and then imed using cross,oldroot, thus only checking leaf-to-imed once.) As a result openssl client apps (and server for client-auth, but that's rarer) do not handle this situation very well; fortunately "real" clients like web browsers usually do. (I encountered this when Verisign a few years ago similarly went to "G5" 2048bit with a compatibility path back to "G1".) > The documentation for the openssl command line tools (I have > insufficiently checked the source) are quite vague if including an > intermediary cert in -CAfile and/or -CApath makes it trusted. Most > other SSL/X.509 implementations feature clearly separated stores for > trusted CAs, blacklisted CAs and locally available copies of > intermediary certs, which also makes it easier for end users to deal > with incidents such as the recent scandals with mismanaged > intermediary CAs. Yes, this area is not explained well, and a bit unusual. >From experience stepping through this to debug issues: OpenSSL can use (intermediate or root) certs in truststore (-CAfile and/or -CApath on commandline, _load_verify_ in library) to "complete" a chain: for lone cert as with commandline verify; for lone cert or partial chain received in protocol, which "shouldn't" need intermediate because server (or client for client-auth) should send at least everything below the/a root; and (less obvious) for cert or partial chain sent in protocol, if not fully provided by _use_certificate_chain_ (which s_client for one doesn't do). But: only one chain. At each step, x509_verify_cert looks for "the" parent cert to add next. If there is more than one possible parent -- with Subject matching child Issuer and other attributes matching child AKI if used and KeyUsage if used reasonable -- x509_verify_cert uses the first one found (which I'm pretty sure is in input order for CAfile and I'm certain is in hash.0,1,etc order for CApath); if that chain later fails, the code doesn't backtrack and look for alternates. And: openssl -- so far -- only uses a root in truststore as an anchor. It can use intermediates in truststore to build the chain, but that chain must end at a root in truststore to verify okay. According to posts in the last few months, this may change: there are reportedly new options for trust anchors in HEAD, which presumably will be in 1.0.2. (Standard caveat: I'm not a developer and don't speak for them.) At present you can make a root untrusted by removing it locally. For any child (intermediate or leaf) x509_verify_cert can check CRL if stored locally (only); to dynamically get CRL, or use OCSP, or use any other kind of blacklist AFAIK you need custom code. I haven't heard of changes coming in this area, but I wouldn't be astonished, since as you note other implementations do more here. ______________________________________________________________________ OpenSSL Project http://www.openssl.org User Support Mailing List openssl-users@openssl.org Automated List Manager majord...@openssl.org
