In order to validate a client cert at all, with or without CRL(s), yes the server must request the client cert
and s_server does that only if you specify -verify or -Verify. The client must also agree to provide the cert, which it might not; if it does not and you use -verify the handshake proceeds without client auth; if you use -Verify the handshake fails. As the usage and man says, -crl_check_all checks the whole chain (except the root) vs -crl_check checks only the leaf cert. If you use CAfile only, which I think is simplest for testing, it should contain at least the root cert, and any intermediate certs needed that aren't supplied by the peer (client); and: CRL for the leaf-issuer i.e. the lowest and possibly only CA if -crl_check, or CRL(s) for all issuer(s) i.e. all CA cert(s) in the chain if -crl_check_all. I'm not sure it works (and can't easily test) to have more than one full CRL for the same issuer; if you don't seem to be finding the correct CRL(s) make sure you have no more than one per issuer. From skimming the code I'm pretty sure you can have full + delta, but I don't do deltas so I didn't test that. Remember s_server, like s_client, prints a message when cert validation fails for ANY reason: no issuer, signature bad, expired, wrong type, OR revoked; but continues with the connection unlike a real app which should abort the connection. Look closely at the lines before -----BEGIN SSL SESSION PARAMETERS----- to see the error if any. From: owner-openssl-us...@openssl.org [mailto:owner-openssl-us...@openssl.org] On Behalf Of Lakshmi Reguna Sent: Monday, March 31, 2014 18:33 To: openssl-users@openssl.org Subject: *** Spam *** Re: Enabling s_server to use a local CRL file 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 < <mailto:dthomp...@prinpay.com> dthomp...@prinpay.com> Reply-To: " <mailto:openssl-users@openssl.org> openssl-users@openssl.org" < <mailto:openssl-users@openssl.org> openssl-users@openssl.org> Date: Monday, March 31, 2014 at 2:54 PM To: " <mailto:openssl-users@openssl.org> openssl-users@openssl.org" < <mailto:openssl-users@openssl.org> 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: <mailto:owner-openssl-us...@openssl.org> 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: <mailto:openssl-users@openssl.org> 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. *** _____
