CRL processing
Libsslfd supports CRL processing as described below.
CRL files (SSLeay-0.6.x)
In the SSLeay world at least, a CRL file, contains information about
the Issuer and a list of revoked serial numbers. The check_crl
routine, looks for a file named for that hash of the issuer plus an
extention of .crl, such a file can be produced as shown below:
# cd /usr/local/ssl/certs
# ../bin/ca -gencrl > crl.pem
# ln -s crl.pem `../bin/ca -noout -hash < crl.pem`.crl
#
If a CRL is found, we check that the issuer's actually match otherwise
we look for hash plus extentions of .0.crl .1.crl etc.
check_crl
This function is called by the certificate callback routines, and
returns a value that indicates the check results:
- 0
- No CRL file found for issuer.
Note, unless compiled with -DCRL_PEDANTIC the
callback routines will quietly ignore this.
- -2
- Found a CRL which revokes subject cert.
- -1
- Found an expired CRL which does not revoke
subject cert. Note that in this case we cannot be sure the
certificate has been revoked or not. This is always logged.
- 1
- Found a valid CRL which does not revoke subject cert.
If the certificate has been revoked, and VERIFY_FAIL_IF_NO_PEER_CERT
is set, the SSL session will fail to establish. Regardless of the
ssl_verify_flag setting, ssld_auth() will never accept an expired or
revoked certificate as authentication. If the ssl_verify_flag does
not have the VERIFY_FAIL_IF_NO_PEER_CERT bit set, then the client will
receive a meaningful error message.
CRL files (SSLeay-0.8.x)
In SSLeay-0.8 the structures that the previous description relied on
are no longer available outside of libcrypto. In order to implement
CRL checks in SSLeay-0.8.1, you must apply the patch found in
ssl/lib/sslfd/crl-081.patch which will install the above login into
libcrypto such that check_crl() can now simply call
X509_STORE_get_by_subject(ctx,X509_LU_CRL,issuer,&obj)
to find and load a CRL file. The rest of the logic remains the same.
$Id: crl.html,v 1.3 1997/09/16 16:02:35 sjg Exp $
Copyright ©
1997 QUICK.COM.AU