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 mj@netauth.com wrote:
On 09 Apr 2014, at 21.03, Howard Chu hyc@symas.com 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