I've been asked to enable OCSP checking in our client (connecting to any LDAP server) . The client uses OpenLdap api's for managing the connection to the server. From my recent birth-by-fire education on certs and security, OCSP checking appears more or less to be a manual process rather than having OpenSSL do all the work auto-magically as part of the handshake (ignoring ocsp stapling which I'm avoiding). I don't see any options in openssl s_client (for testing) to enable OCSP -- only a separate utility to manually check based on captured client certs.
Storing the CRL in the LDAP DB isn't an option. For whatever reason, OCSP is required.
Is there any way to enable OCSP checking via the current LDAP API? Assuming the answer is no, then would a reasonable approach be to manually query the server URL from time to time, and verify the certificate in the background? Traffic from our client should be relatively minimal, so even at a rate of one verification an hour should have a minimal risk window of the cert being expired. Using this method I can more or less follow the same logic as the openssl utilities (s_client and ocsp).
TIA.
Jason Talley wrote:
I've been asked to enable OCSP checking in our client (connecting to any LDAP server) . The client uses OpenLdap api's for managing the connection to the server. From my recent birth-by-fire education on certs and security, OCSP checking appears more or less to be a manual process rather than having OpenSSL do all the work auto-magically as part of the handshake (ignoring ocsp stapling which I'm avoiding). I don't see any options in openssl s_client (for testing) to enable OCSP -- only a separate utility to manually check based on captured client certs.
Storing the CRL in the LDAP DB isn't an option. For whatever reason, OCSP is required.
Is there any way to enable OCSP checking via the current LDAP API?
There is nothing in the LDAP API for this.
Assuming the answer is no, then would a reasonable approach be to manually query the server URL from time to time, and verify the certificate in the background?
Sure.
Traffic from our client should be relatively minimal, so even at a rate of one verification an hour should have a minimal risk window of the cert being expired. Using this method I can more or less follow the same logic as the openssl utilities (s_client and ocsp).
TIA.
This page has a decent breakdown of verifying: https://blog.ivanristic.com/2014/02/checking-ocsp-revocation-using-openssl.h...
Step one would likely start with with 'get cert from your ldap node/vip' - and in my environment at least, returns the configured chain, which help you move on to the next step.
- chris
PS: If this is old news to you, feel free to ignore this. :)
-----Original Message----- From: openldap-technical [mailto:openldap-technical-bounces@openldap.org] On Behalf Of Howard Chu Sent: Thursday, January 28, 2016 3:09 PM To: Jason Talley jbtalley98@gmail.com; openldap-technical@openldap.org Subject: Re: OCSP for LDAP Client
Jason Talley wrote:
I've been asked to enable OCSP checking in our client (connecting to any LDAP server) . The client uses OpenLdap api's for managing the connection to the server. From my recent birth-by-fire education on certs and security, OCSP checking appears more or less to be a manual process rather than having OpenSSL do all the work auto-magically as part of the handshake (ignoring ocsp stapling which I'm avoiding). I don't see any options in openssl s_client (for testing) to enable OCSP -- only a separate utility to manually check based on captured client certs.
Storing the CRL in the LDAP DB isn't an option. For whatever reason, OCSP is required.
Is there any way to enable OCSP checking via the current LDAP API?
There is nothing in the LDAP API for this.
Assuming the answer is no, then would a reasonable approach be to manually query the server URL from time to time, and verify the certificate in the background?
Sure.
Traffic from our client should be relatively minimal, so even at a rate of one verification an hour should have a minimal risk window of the cert being expired. Using this method I can more or less follow the same logic as the openssl utilities (s_client and ocsp).
TIA.
-- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/
“This message is intended only for the use of the addressee(s) and may contain information that is PRIVILEGED and CONFIDENTIAL. If you are not the intended recipient(s), you are hereby notified that any dissemination of this communication is strictly prohibited. If you have received this communication in error, please erase all copies of the message and its attachments and notify the sender immediately.”
openldap-technical@openldap.org
-
Chris Jacobs -
Howard Chu -
Jason Talley