[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: Checking client certificates against CRLs

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.


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