Configuring Client Certificate Revocation
Certificates installed on client devices can be used to authenticate users or devices, giving them access to a
particular realm. A certificate is usually valid until it expires, but it is possible for it to be compromised before it
expires. For example, a CA may decide that a certificate was improperly issued, or its private key may have been
You can consult a certificate revocation list (CRL) to check a certificate’s validity (its location—the CRL
distribution point, or CDP—is typically included in the X.509 certificate). If a certificate is no longer valid, the
user is denied access. CRLs are published for each authority and can contain status of only the certificates issued
by that certificate authority. This requires a separate, hierarchical CRL server for each CA that you want to trust.
The client needs to know the public key for each CA in the chain to verify each certificate and CA at each level in
Online Certificate Status Protocol (OCSP) and an OCSP responder server can be used instead of a CRL server to
check the status of a certificate. OCSP responders take the certificate from a client, evaluate it and give back a
response to the server as revoked, unrevoked, or unknown. OCSP can save bandwidth in a large organization, as
the CRL server list can get very large. OCSPs can be configured to operate for any number of CAs and certificates.
A single OCSP server can be configured for the entire PKI infrastructure, irrespective of CA relations.
If both CRL and OCSP are enabled for a CA certificate, only OCSP will be used.
Fallback from CRL to OCSP or OCSP to CRL is not supported.
Was This Article Helpful?
Help us to improve our support portal