This question may be better asked in the NSS mailing list. Feel free to let me know if that is the case.
I'm building a service based around OpenLDAP and SASL EXTERNAL authentication using client certificates. One of requirements is that we have the ability to revoke client certificates. I've found that the only way to revoke a client certificate using an NSS-linked OpenLDAP (RHEL's default 2.4.23) is to:
- Revoke the certificate - Import the CRL into the db referenced by olcTLSCACertificatePath - restart slapd
Is there a way to update the CRL without restarting slapd? And is there any way to make slapd request the URL referenced in the client cert's nsCaRevocationUrl attribute? If the answer to this is "use OpenSSL", that's a fine answer.
Regards, David
On Wed, 9 Apr 2014 09:38:29 -0400 David Arroyo droyo@aqwari.net wrote
This question may be better asked in the NSS mailing list. Feel free to let me know if that is the case.
I'm building a service based around OpenLDAP and SASL EXTERNAL authentication using client certificates. One of requirements is that we have the ability to revoke client certificates. I've found that the only way to revoke a client certificate using an NSS-linked OpenLDAP (RHEL's default 2.4.23) is to:
- Revoke the certificate - Import the CRL into the db referenced by olcTLSCACertificatePath - restart slapdIs there a way to update the CRL without restarting slapd? And is there any way to make slapd request the URL referenced in the client cert's nsCaRevocationUrl attribute? If the answer to this is "use OpenSSL", that's a fine answer.
I'm also interested in CRL checking without having to reload a server configuration. I'm using a custom OpenLDAP build linked against OpenSSL though.
Ciao, Michael.
On 09 Apr 2014, at 17.02, Michael Ströder michael@stroeder.com wrote:
On Wed, 9 Apr 2014 09:38:29 -0400 David Arroyo droyo@aqwari.net wrote
This question may be better asked in the NSS mailing list. Feel free to let me know if that is the case.
I'm building a service based around OpenLDAP and SASL EXTERNAL authentication using client certificates. One of requirements is that we have the ability to revoke client certificates. I've found that the only way to revoke a client certificate using an NSS-linked OpenLDAP (RHEL's default 2.4.23) is to:
- Revoke the certificate
- Import the CRL into the db referenced by olcTLSCACertificatePath
- restart slapd
Is there a way to update the CRL without restarting slapd? And is there any way to make slapd request the URL referenced in the client cert's nsCaRevocationUrl attribute? If the answer to this is "use OpenSSL", that's a fine answer.
I'm also interested in CRL checking without having to reload a server configuration. I'm using a custom OpenLDAP build linked against OpenSSL though.
Ciao, Michael.
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.
Setting up an OCSP responder is the “modern” way to go. Think about it: if your CRL grows large, your client (in this case slapd) needs to fetch and parse it. OCSP checks are lightweight and happen in real-time. Of course, you should always HUP your OCSP responder when publishing a new CRL.
NSS has a crazy arcane (even more arcane than OpenSSL) set of command line options for managing their certificate databases, and at the end of they day they are BDB - easily corrupted.
-mike
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.
Setting up an OCSP responder is the “modern” way to go. Think about it: if your CRL grows large, your client (in this case slapd) needs to fetch and parse it. OCSP checks are lightweight and happen in real-time. Of course, you should always HUP your OCSP responder when publishing a new CRL.
NSS has a crazy arcane (even more arcane than OpenSSL) set of command line options for managing their certificate databases, and at the end of they day they are BDB - easily corrupted.
Sigh. NSS is over-engineered where it doesn't matter, and under-designed everywhere else - i.e., actual usability.
-mike
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
Mike Jackson wrote:
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.
Such a general statement regarding CRL vs. OCSP is nonsense.
If you have really high traffic checking client certs against a local black-list (CRL) is much better.
Also OCSP is a privacy nightmare.
Ciao, Michael.
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
openldap-technical@openldap.org
-
David Arroyo -
Howard Chu -
Michael Ströder -
Mike Jackson