Thank you for all of the advice, everyone. I have taken the common advice of using a slapd built against OpenSSL, and everything just worked. Even the programs that I had linked against libldap started working better. I wish I had done it sooner -- all of our other pki infrastructure uses OpenSSL, so it works together much better.
Certificates issued by my CA have both an OCSP responder URI and a CRL URI. The use case for my CA is not the traditional one; it is primarily used to issue short-lived (2-6 weeks) client certificates used to bind to an LDAP server using SASL/EXTERNAL authentication. Revoking certificates is extremely unusual, and even revoking every certificate in use would still produce a small CRL. So it's feasible to have a shorter TTL for the CRL, to get responsiveness comparable to OCSP. Cheers, David On Apr 10, 2014, at 2:31 AM, Mike Jackson <[email protected]> wrote: > > On 09 Apr 2014, at 21.03, Howard Chu <[email protected]> wrote: > >> Mike Jackson wrote: >>> I think the answer is to link against OpenSSL because it supports CRL >>> retrieval via HTTP and LDAP, and ultimately more convenient - OCSP. Certs >>> which contain both CRL and OCSP information, a modern client should try OCSP >>> first and then fall back to trying the CRL. >> >> OCSP is fine, but considering we're talking about OpenLDAP here, the most >> convenient thing for slapd is for OpenSSL to retrieve its CRL using LDAP. >> Which means you can just store the CRL as an entry in slapd and OpenSSL will >> do the right thing. > > > I thought about the problem a little bit more and realize that NSS isn’t > necessarily the problem here and that OpenSSL won’t necessarily solve the > problem, either. > > OP has a problem not because slapd or a crypto library is misbehaving, but > because his CRL validity isn’t expired and yet he’s published a new CRL in > the meantime. After all, if you tell me to come back and get a new CRL in 14 > days then I am not coming back every two days between now and then to pester > you about it. So, of course you need to restart slapd to reload the new CRL. > > If OpenLDAP supports delta CRL checking, anyway then one possibility is 1) to > get the “freshest CRL” extension into *both* your client and server certs, > and 2) create and publish delta CRLs from your issuing CA. > > OPs problem, IMO, can either be solved via slapd performing delta CRL > checking, or OCSP. OCSP is, IMO, far preferable because it can perform delta > CRL checking behind the scenes, removes the need to implement delta CRL > checking in the clients, simplifies your certificate profiles, and is overall > better for the network for a few reasons. > > > -mike
