5.3 TLS Certificate Revocation List Handling

Learn how to configure a revocation list.

A Certificate Revocation List (CRLs) is a Privacy Enhance Mail (PEM) formatted file that contains information identifying the issuer of the revocation list followed by zero or more entries identifying certificate that have been revoked. A secured server is part of establishing a secure channel with a peer and will initiate a handshake with the peer. During this handshake security information and capabilities are negotiated and exchanged, which includes the one or both certificates of the participants. Depending on security configurations, one, both, or neither of the participants may present or require the presentation of the peer's certificate.

After receiving and verifying the validity of a peer's X.509 certificate, the receiving participant consults the currently configured CRL. The presence of an entry identifying the just-validated peer certificate causes the receiving participant to consider the remote participant's certificate as having been revoked. A revoked certificate is considered invalid for the purposes of authenticating the identity of the remote participant. A revoked certificate fails the integrity-check portion of the secure channel handshake and terminates the channel. Depending on the implementation that remote peer detects that an error occurred during certificate validation, but may not be informed of the specific cause.

The actual CRL consists of prolog and identifies the issuer of the CRL followed by zero or more entries. Each entry identifies a specific certificate by serial number along with security information relating to the date of revocation, the signature algorithm, and finger-print information.

Typically, the CRL in compact form only includes the contents between the -----BEGIN X509 CRL----- and -----END X509 CRL----- delimiters. All other data outside these delimiters is ignored. You can embed a textual representation of the CRL in the CRL file without affecting the function of the CRL.

The use of CRLs is configured for each MA server individually The CRL configuration is composed of two properties:

/config/security/common/crlEnabled

Enables or disables CRL processing.

If, however, /config/security/common/crlEnabled is enabled (true), then the /config/security/common/crlStore property must refer to a valid and well formed CRL.

/config/security/common/crlStore

When CRL processing is disabled (false), the remote participant's certificate is not checked against a CRL. When this is the case, you don’t need to set the /config/security/common/crlStore property.

A valid and well formed CRL file is either a PEM encoded CRL file that conforms to the RFC2380 - Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile or an empty file.

The following is a sample excerpt declaring and defining CRL processing for a secured server.

{
    "config" : {
        "security: {
            "common" : {
                "crlEnabled" : true,
                "crlStore"   : "file:/scratch/Tests/unittests/etc/ssl/RootCA/CAs/Deploy1/CRLs/empty_CRL.pem"
            }
        }
    }
}

The CRL file may be updated or replace by other, presumably more current, versions while the server is running. Replacing the CRL file causes the next request CRL lookup to use the newly updated file.

Regardless of how the /config/security/common/crlEnabled property is set, CRL processing is disabled if the general security configuration of the server is disabled. For example, the value of the /config/security property is false).

One other configure setting that indirectly effects CRL processing is the /config/securityDetails/network/common/authMode property. This property controls whether the server requires the client to authenticate using a certificate or whether the server accepts optionally presented certificate or whether the server will ignore any presented client certificates.  If a certificate is not required, not presented, or ignored by the server, then CRL processing is not used.