Thor Lancelot Simon wrote: > On Sun, Oct 05, 2003 at 03:04:00PM +0100, Ben Laurie wrote: > >>Thor Lancelot Simon wrote: >> >> >>>On Sat, Oct 04, 2003 at 02:09:10PM +0100, Ben Laurie wrote: >>> >>> >>>>Thor Lancelot Simon wrote: >>>> >>>> >>>>>these operations. For example, there is no simple way to do the most >>>>>common certificate validation operation: take a certificate and an optional >>>>>chain, and check that the certificate is signed by an accepted root CA, or >>>>>that each certificate in the chain has the signing property and that the >>>>>chain reaches that CA -- which would be okay if OpenSSL did the validation >>>>>for you automatically, but it doesn't, really. >>>> >>>>Err, yes it does, but its not very well documented. >>> >>> >>>No. You can't do it in one step, and you have to use functions that are >>>marked in OpenSSL's header files as not being part of the official API. >>>mod_ssl has a convenience function that's confusingly named just like the >>>OpenSSL library functions that deals with this -- of course, it should be >>>part of OpenSSL itself, but at least as of 0.9.6 it was not. >> >>Would you care to be more explicit? > > > I have to apologize -- I was not entirely correct in my initial statement, > but without access to the source tree I did most of my OpenSSL work in > (it belongs to a former employer) it took me a while to retrace my steps > and realize I was not quite right. > > On the client side, though the documentation's poor, you're correct: there > _is_ a way to validate a certificate and chain you've received from the peer > in one step. (I note that there is now reference in the header files to > some AUTOCHAIN stuff that I don't recall from earlier versions of OpenSSL, > but that ssl_verify_cert_chain is *still* not part of the public API; it's > in ssl_locl.h).
But that's because its used internally (by both clients and servers). > On the server side (or, indeed, on the client side, if the client side > needs to follow a chain to reach a trusted CA, and thus needs to load chain > certificates) there's no API for loading a cert and its entire chain in one > shot, and indeed to do so AFAICT you must use functions that are not part of > the public API. Hmmm. You can put multiple certs in a single file, IIRC, and you can certainly have multiple certs in a directory, with hashed links pointing to them. I know for sure chained certs work without screwing around coz I just tested them whilst adding CRLs to Apache-SSL. > See SSL_CTX_use_certificate_chain() in the mod_ssl sources (which appears > much simpler in mod_ssl 2.8 than what I remember working with -- perhaps the > OpenSSL API *has* improved!) and SSL_use_certificate_file, > SSL_CTX_use_certificate_file, and SSL_CTX_use_certificate_chain_file in the > OpenSSL sources. And then note that *all* of the example code gets this > stuff wrong -- if it even bothers to do server certificate validation at > all. Regrettably, mod_ssl is not the best guide to the use of OpenSSL - it often goes about things in a long-winded and inappropriate way (compare its CRL handling with mine, for example). > I can't lose my impression that some of the chain-handling functions moved > from ssl_locl.h to ssl.h between 0.9.6 and 0.9.7 but I don't have a 0.9.6 > tree handy nor the time to sift through it. Sigh. I wish I had some of > my code from the last time I tackled this issue with OpenSSL at hand, but > unfortunately I don't own it, so I do not. This could well be true. > The complexity and instability of the API for this stuff, and the fact that > we're both rooting around *in the OpenSSL source code* to figure out which > bits of it are public and which are internal, and in which version of > OpenSSL, when the operations at hand (loading and validating chains of > certificates, from the cert for the peer's identity up to the cert from > which trust derives) is a pretty good example, itself, of why I don't care > for OpenSSL. Oh, I totally agree! > I spent a long time working on the X.509 support in Pluto, > too, and though I don't really care for it either it does have the decided > advantage that it appears to be designed in the right direction: from "what > are the end-user's needs?" instead of "what is the structure of the > underlying protocol or software abstraction?" I'm not familiar with Pluto. Cheers, Ben. -- http://www.apache-ssl.org/ben.html http://www.thebunker.net/ "There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit." - Robert Woodruff --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]