Monoculture

Ben Laurie ben at algroup.co.uk
Fri Oct 10 07:19:05 EDT 2003


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 majordomo at metzdowd.com



More information about the cryptography mailing list