Thanks for the response Dave. Would you also know how -Verify option interacts with the -crl_check_all. This what I gather from the Openssl s_server help documentation. Is the entire certificate chain checked against CRLs issued by each intermediate CA in the chain. Would you have a use case example of how the CAfile is expected to look like.
-verify depth, -Verify depth The verify depth to use. This specifies the maximum length of the client certificate chain and makes the server request a certificate from the client. With the -verify option a certificate is requested but the client does not have to send one, with the -Verify option the client must supply a certificate or an error occurs. -crl_check, -crl_check_all Check the peer certificate has not been revoked by its CA. The CRL(s) are appended to the certificate file. With the -crl_check_all option all CRLs of all CAs in the chain are checked. -CApath directory The directory to use for client certificate verification. This directory must be in ``hash format'', see verify for more information. These are also used when building the server certificate chain. -CAfile file A file containing trusted certificates to use during client authentication and to use when attempting to build the server certificate chain. The list is also used in the list of acceptable client CAs passed to the client when a certificate is requested. Thanks, Lakshmi. From: Dave Thompson <dthomp...@prinpay.com<mailto:dthomp...@prinpay.com>> Reply-To: "openssl-users@openssl.org<mailto:openssl-users@openssl.org>" <openssl-users@openssl.org<mailto:openssl-users@openssl.org>> Date: Monday, March 31, 2014 at 2:54 PM To: "openssl-users@openssl.org<mailto:openssl-users@openssl.org>" <openssl-users@openssl.org<mailto:openssl-users@openssl.org>> Subject: RE: Enabling s_server to use a local CRL file Through 1.0.1, put the CRL in PEM format in CAfile (specified or defaulted) or in CApath (ditto) named or linked as $hash.r$num (c_rehash can do for you). I’ve never seen a CA distribute PEM so you almost certainly need to convert. And specify –crl_check or –crl_check_all (see the man page or -?). 1.0.2 apparently has new capabilities in this area but I haven’t looked yet. From:owner-openssl-us...@openssl.org<mailto:owner-openssl-us...@openssl.org> [mailto:owner-openssl-us...@openssl.org] On Behalf Of Lakshmi Reguna Sent: Friday, March 28, 2014 14:16 To: openssl-users@openssl.org<mailto:openssl-users@openssl.org> Subject: *** Spam *** Enabling s_server to use a local CRL file Hi, I would like to know how I can specify s_server to use a local CRL file. Do I need to specify a LDAP CRL distribution field in the certificate which is being checked against the CRL ? Thanks, Lakshmi. ________________________________ *** Please note that this message and any attachments may contain confidential and proprietary material and information and are intended only for the use of the intended recipient(s). If you are not the intended recipient, you are hereby notified that any review, use, disclosure, dissemination, distribution or copying of this message and any attachments is strictly prohibited. If you have received this email in error, please immediately notify the sender and destroy this e-mail and any attachments and all copies, whether electronic or printed. Please also note that any views, opinions, conclusions or commitments expressed in this message are those of the individual sender and do not necessarily reflect the views of Fortinet, Inc., its affiliates, and emails are not binding on Fortinet and only a writing manually signed by Fortinet's General Counsel can be a binding commitment of Fortinet to Fortinet's customers or partners. Thank you. *** ________________________________ *** Please note that this message and any attachments may contain confidential and proprietary material and information and are intended only for the use of the intended recipient(s). If you are not the intended recipient, you are hereby notified that any review, use, disclosure, dissemination, distribution or copying of this message and any attachments is strictly prohibited. If you have received this email in error, please immediately notify the sender and destroy this e-mail and any attachments and all copies, whether electronic or printed. Please also note that any views, opinions, conclusions or commitments expressed in this message are those of the individual sender and do not necessarily reflect the views of Fortinet, Inc., its affiliates, and emails are not binding on Fortinet and only a writing manually signed by Fortinet's General Counsel can be a binding commitment of Fortinet to Fortinet's customers or partners. Thank you. ***
