Re: Checking client certificates against CRLs

[Mike Jackson <mj@netauth.com>]

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