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 database 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