Skip to main content
Comply Defense
Category: Identity & Access Management

Certificate Revocation List

Also known as:
Simply put

A Certificate Revocation List (CRL) is a list of digital certificates that a certificate authority has invalidated before their scheduled expiration date. It lets systems and users check whether a given certificate can still be trusted, for example when a certificate was issued in error or is no longer valid.

Formal definition

A CRL is a list of revoked public key certificates that is created and digitally signed by the issuing certification authority (CA). The digital signature allows relying parties to verify the list's authenticity and integrity before using it to determine whether a certificate has been revoked prior to its scheduled expiration. CRLs are one mechanism a CA may use to communicate revocation status; this entry does not address specific CRL formats, distribution methods, update frequency, or alternatives such as online status-checking protocols, which should be confirmed against current authoritative PKI standards and the relevant CA's certificate policy.

Why it matters

In defense and public sector environments, PKI is foundational to identity, authentication, and encrypted communications, and the ability to revoke trust in a compromised or erroneously issued certificate is as important as the ability to issue one. A CRL provides a mechanism for a certificate authority to communicate that a certificate should no longer be trusted before its scheduled expiration, for example when the certificate was issued in error or is otherwise no longer valid. Without a reliable revocation-checking process, a relying party may continue to trust a certificate that the issuing CA has already invalidated, undermining the assurance that certificate-based authentication is intended to provide.

Because the CRL is digitally signed by the issuing CA, relying parties can verify the list's authenticity and integrity before acting on it. This matters for compliance because verifying revocation status is a distinct control from simply validating a certificate's signature and expiration date; treating an unexpired certificate as automatically trustworthy overlooks the possibility that it has been revoked. Systems that rely on certificates for access decisions generally need a defined process for obtaining and evaluating revocation information, and gaps in that process can weaken the overall trust model even when the underlying cryptography is sound.

It is worth emphasizing that a CRL is one of several possible mechanisms a CA may use to convey revocation status, and this entry does not address specific formats, distribution methods, update frequency, or alternative status-checking protocols. Organizations should confirm the applicable requirements against current authoritative PKI standards and the relevant CA's certificate policy, since operational details and acceptable revocation-checking approaches can vary by system and by agency implementation.

Who it's relevant to

Information System Security Managers and PKI Administrators
Personnel responsible for systems that rely on certificate-based authentication generally need to ensure that revocation status is checked, not just that certificates are validly signed and unexpired. Understanding that a CRL is CA-signed and represents certificates invalidated before their scheduled expiration helps in designing and documenting revocation-checking processes. Specific distribution, update frequency, and format requirements should be confirmed against the relevant CA's certificate policy and applicable PKI standards.
Compliance Officers and Auditors
Those assessing PKI-dependent controls should recognize revocation checking as a distinct element of certificate trust and avoid treating an unexpired certificate as automatically trustworthy. When evaluating whether a system properly handles revoked certificates, auditors should confirm the actual mechanism in use and the governing certificate policy rather than assuming a particular approach, since a CRL is one of several possible revocation mechanisms.
System and Network Architects
Individuals designing authentication and encryption architectures that depend on certificates need to account for how relying parties obtain and verify revocation information. Because this entry does not address specific formats, distribution methods, update intervals, or alternatives such as online status-checking protocols, architects should verify the appropriate approach against current authoritative PKI standards and the applicable CA's certificate policy for their environment.

Inside CRL

Revoked Certificate Serial Numbers
A list of the serial numbers identifying certificates that the issuing Certification Authority (CA) has revoked before their scheduled expiration date.
Revocation Date
For each listed certificate, the date and time at which the CA considered the certificate revoked, which practitioners should not conflate with the date the CRL was published.
Revocation Reason (Optional)
An optional CRL entry extension that may indicate why a certificate was revoked, such as key compromise, cessation of operation, or superseded status. Presence and use of reason codes can vary by CA implementation.
Issuer Information
Identification of the CA that issued and signed the CRL, establishing the trust chain against which the list's authenticity is validated.
thisUpdate and nextUpdate Fields
Timestamps indicating when the CRL was issued and when the next CRL is expected. These generally define the validity window a relying party uses to determine whether its cached CRL is current.
CA Digital Signature
A cryptographic signature applied by the issuing CA over the CRL contents, allowing relying parties to verify the list's integrity and origin before trusting its revocation data.

Common questions

Answers to the questions practitioners most commonly ask about CRL.

Does a certificate that appears on a Certificate Revocation List simply mean it has expired?
No. Revocation and expiration are distinct concepts. A certificate expires when it reaches the end of its defined validity period, and an expired certificate is not placed on a CRL for that reason alone. A CRL lists certificates that have been revoked before their scheduled expiration, typically because of key compromise, a change in the subject's affiliation, superseding of the certificate, or a similar cause. Verifiers generally check both the validity period and revocation status as separate steps, so treating the CRL as an expiration list can lead to accepting a compromised but unexpired certificate.
If a certificate is not listed on the CRL, does that guarantee it is trustworthy?
Not by itself. Absence from a CRL indicates only that the issuing authority has not published a revocation for that certificate as of the CRL's issuance. It does not establish that the certificate is currently valid, that the CRL being consulted is fresh, or that the overall chain of trust is sound. A relying party generally must also confirm the certificate is within its validity period, that the signing chain validates to a trusted anchor, and that the CRL itself is current and properly signed. Revocation information can also lag, so a recently compromised certificate may not yet appear. Readers should verify status handling against their applicable policy and current authoritative guidance.
How does CRL-based revocation checking differ from using the Online Certificate Status Protocol (OCSP)?
Both mechanisms convey revocation status, but they differ in delivery model. A CRL is a periodically published, signed list that a relying party downloads and may cache, meaning status reflects the state as of the last CRL issuance. OCSP generally provides a per-certificate status response from a responder at query time. Many implementations use one, the other, or both, and some rely on OCSP stapling to reduce query overhead. The appropriate choice and configuration depend on the governing certificate policy and system requirements, which the reader should confirm against current authoritative sources.
How often should a relying party retrieve an updated CRL?
CRLs typically include fields indicating when they were issued and when the next update is expected, and relying parties generally refresh their cached copy at or before that next-update time. Refresh frequency is driven by the issuing authority's certificate policy and the operational risk tolerance of the relying system; more sensitive environments may require more frequent retrieval or supplemental real-time checks. Because specific intervals are set by policy rather than fixed universally, verify the required cadence against the applicable certificate policy and system security requirements.
How should a system behave when a current CRL cannot be retrieved?
This is a policy decision between fail-closed and fail-open handling. A fail-closed approach rejects certificates when revocation status cannot be confirmed, favoring security at the cost of availability; a fail-open approach accepts them, favoring availability at the cost of assurance. The appropriate behavior depends on the sensitivity of the system, the governing certificate policy, and any applicable authorization requirements. Readers should not assume a default and should confirm the required behavior against their system's documented policy and current authoritative guidance.
What integrity checks should be applied to a CRL before it is trusted?
Before relying on a CRL, a verifier generally validates that the CRL is signed by an authority permitted to issue it within the relevant trust chain, that the signature verifies, and that the CRL is current relative to its issuance and next-update fields. Chaining the CRL signer to a trusted anchor and confirming the CRL scope covers the certificate in question are also typically part of proper processing. The precise validation steps follow the applicable path-validation rules and certificate policy, which the reader should confirm against current authoritative specifications.

Common misconceptions

A certificate that does not appear on a CRL is definitively valid and trustworthy.
Absence from a CRL only indicates the certificate has not been listed as revoked as of the CRL's issuance. A relying party must still verify the certificate's validity period, trust chain, and the freshness of the CRL itself. A stale CRL may not yet reflect a recent revocation, so absence is not by itself proof of current validity.
Checking a CRL provides real-time revocation status.
CRLs are generally published on a periodic schedule rather than continuously, so there can be a lag between when a certificate is revoked and when that status is reflected in a downloadable CRL. Where more timely status is required, protocols such as OCSP are often used as an alternative or complement; readers should confirm which mechanisms their environment and policy require.
Successfully retrieving and processing a CRL means the endpoint or system is secure and compliant.
Validating revocation status is one control within certificate lifecycle and identity management; it does not equate to overall security or compliance. Effective revocation checking must be part of a broader configuration that also addresses signature verification, trust anchor management, and continuous monitoring consistent with applicable authorization requirements.

Best practices

Verify the CRL's digital signature against the trusted issuing CA before relying on any revocation data, and reject CRLs that fail integrity or trust-chain validation.
Enforce checks of the thisUpdate and nextUpdate fields so that relying parties detect and reject stale CRLs rather than trusting an expired cached copy.
Confirm which revocation-checking mechanism (CRL, OCSP, or both) your governing policy and system authorization require, since timeliness needs and agency tailoring may differ across environments.
Treat absence from a CRL as only one input to a validity decision, combining it with validity-period, trust-chain, and freshness checks rather than as standalone proof of trust.
Establish and document a schedule for retrieving updated CRLs consistent with the CA's publication cadence, and monitor for retrieval or distribution-point failures that could leave revocation status unchecked.
Verify all revocation-related configuration and cadence expectations against current official CA and program documentation, as implementation details and reason-code usage can vary by issuer.