This section provides information on identifying directives
for certificate revocation list (CRL) and those supported in global
servers and virtual hosts.
Certificate revocation provides the ability to revoke a client
certificate given to IBM® HTTP Server by the browser when
the key becomes compromised or when access permission to the key gets
revoked. CRL represents a database which contains a list of certificates
revoked before their scheduled expiration date.
If you want to enable certificate revocation in IBM HTTP
Server, publish the CRL on a Lightweight Directory Access Protocol
(LDAP) server. Once the CRL is published to an LDAP server, you can
access the CRL using the IBM HTTP Server configuration file.
The CRL determines the access permission status of the requested client
certificate. Be aware, however, that it's not always
possible to determine the revocation status of a client certificate
if the backend server, the source of revocation data, is not available
or not communicating properly with IBM HTTP Server.
Identifying directives needed to set up a certificate revocation
list. The SSLClientAuth directive can include two options at once:
- SSLClientAuth 2 crl
- SSLClientAuth 1 crl
The CRL option turns CRL on and off inside an SSL virtual host.
If you specify CRL as an option, then you elect to turn CRL on. If
you do not specify CRL as an option, then CRL remains off. If the
first option for SSLClientAuth equals 0/none, then you cannot use
the second option, CRL. If you do not have client authentication on,
then CRL processing does not take place.
Identifying directives supported in global or server and virtual
host. Global server and virtual host support the following directives:
- SSLCRLHostname: The IP Address and host of the LDAP server, where
the CRL datahbase resides. Currently,
you must configure any static CRL repositories to allow for checking
of other URI forms in the CRLDistributionPoint fields.
Only an explicitly configured LDAP server
can be queried for CRL, and the SSL handshake fails if the backend
server is not reachable.
- SSLCRLPort: The port of the LDAP server where the CRL database
resides; the default equals 389.
- SSLCRLUserID: The user ID to send to the LDAP server where the
CRL database resides; defaults to anonymous if you do not specify
the bind.
- SSLStashfile: The fully qualified path to file where the password
for the user name on the LDAP server resides. This directive is not
required for an anonymous bind. Use when you specify a user ID.
Use
the sslstash command, located in the bin directory of IBM HTTP
Server, to create your CRL password stash file. The password you specify
using the sslstash command should equal the one you use to
log in to your LDAP server.
Usage:
sslstash [-c] <directory_to_password_file_and_file_name> <function_name> <password>
where:
- -c: Creates a new stash file. If not specified, an existing
file updates.
- File: Represents the fully qualified name of the file to
create, or update.
- Function: Indicates the function for which to use the password.
Valid values include crl, or crypto.
- Password: Represents the password to stash.
- SSLUnknownRevocationStatus: This
is provided for cases in which recoverable errors occur in IBM HTTP
Server when it is communicating with the backend server, and the IBM
HTTP Server cannot determine the revocation status of a certificate.
The default behavior is to continue processing the handshake unless
the backend server can successfully indicate that the certificate
is revoked.
CRL checking follows the URIDistributionPoint X509 extension in
the client certificate as well as trying the DN constructed from the
issuer of the client certificate. If the certificate contains a CRL
Distribution Point (CDP), then that information is given precedence.
The order in which the information is used is as follows:
- CDP LDAP X.500 name
- CDP LDAP URI
- Issuer name combined with the value from the SSLCRLHostname directive
Avoid trouble: If your certificates
use the LDAP or HTTP URI forms of the CertificateDistributionPoint
or AIA extensions, be sure that the IBM HTTP Server system can establish
outgoing connections of this type; you might need to adjust the settings
for your firewall.
gotcha