[prev in list] [next in list] [prev in thread] [next in thread] 

List:       freeradius-users
Subject:    Re: OCSP Response Signed by other CA
From:       Alan DeKok <aland () deployingradius ! com>
Date:       2019-10-31 18:38:16
Message-ID: 8986D215-75AD-4D94-8F74-AE41CAE28E90 () deployingradius ! com
[Download RAW message or body]



> On Oct 31, 2019, at 2:09 PM, Mike DiBella <mike@dibella.net> wrote:
> 
> In testing my OCSP responder configuration I've found that the following openssl \
> command: 
> openssl ocsp -issuer client_cer_root.cer -cert client.cer -VAfile ocsp_signer.cer \
> -url http://ocsp.responder.net/ocsp 
> returns:
> 
> Response verify OK
> client.cer: good
> This Update: Oct 31 11:43:47 2019 GMT
> Next Update: Nov  2 00:03:47 2019 GMT
> 
> I see that there is a client keyword in the verify section of the eap configuration \
> file.   I'm wondering if I can I substitute this command for the default openssl \
> verify command prototyped in the file?

  Yes, that should mostly work.  You should use %{TLS-Client-Cert-Filename} instead \
of a hard-coded filename though.  The server will write the client certificate to a \
temporary file, and then clean it up after OSCP tests are done.

> In my testing, it looks like openssl returns exit 0 for both verified and responder \
> errors, so I'm wondering how freeradius parses the result of the command.

  FreeRADIUS looks for the command to succeed / fail.  If the OSCP responder is down, \
OpenSSL may do various magic.  :(

  The solution is to ensure that critical pieces of infrastructure stay up.

  Alan DeKok.


-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html


[prev in list] [next in list] [prev in thread] [next in thread]