3.11.16. TLS_CRLFile Previous topic Parent topic Child topic Next topic

This optional parameter specifies one or more CRL files that are used to check peer certificates for revocation when all the following conditions apply:
  • TLS is enabled.
  • TLS is configures to check peer certificates with TLS_RequireClientCert.
  • CRL checking is enabled with TLS_CRLCheck.
The CRL files are also used when TLS_CRLCheckAll is enabled.
If the CRL file is not found or the CRL says the certificate has been revoked, TLS authentication fails with an error:
SSL3_GET_CLIENT_CERTIFICATE:no certificate returned
One or more CRLs can be named with multiple TLS_CRLFile parameters. Alternatively, CRLs can follow the file-naming convention: the hash of the issuer Subject Name and a suffix that depends on the serial number, such as ab1331b2.r0, ab1331b2.r1.
Find out the hash of the issuer name in the CRL with the following command:
openssl crl -in crl.pem -hash -noout
CRLs with this name convention are searched in TLS_CAPath, else in the OpenSSL certificates directory (typically /usr/local/openssl/certs/).
CRLs are expected to be in PEM format. A CRL file can be generated with OpenSSL like this:
openssl ca -gencrl -revoke cert-clt.pem
openssl ca -gencrl -out crl.pem
Using these flags requires Net_SSLeay-1.30 or later.
Each CRL file named with a TLS_CRLFile is automatically reloaded and reread at the start of an each new RadSec session if the modification date of the named CRL file has changed since the last time it was loaded. If the CRL for a particular issuer changes, it is sufficient to replace the existing CRL file with the newer version and RadSec reloads the new CRL when required.
Operating system wildcards are supported, so you can name multiple CRLs with a single wildcard like:
TLS_CRLFile %D/crls/*.r0