What Is a Certificate Revocation List (CRL)?

Why certificate revocation matters

Digital certificates are used to create trust in online transactions. After trust has been established and the identity of the other party has been confirmed, only then it is possible to create an authenticated and encrypted channel of communication. Together, these properties form the foundation of the Public Key Infrastructure (PKI) that underpins virtually every secure digital interaction.

Every certificate is issued with a finite validity period, ranging from hours to several years depending on the issuing CA’s policy. However, it is worth mentioning that the maximum validity period for a publicly trusted digital certificate will be only 47 days starting on March 2029. A certificate is immediately undermined the moment it is known that its private key has been compromised, independently of how much time is left in its validity period. The validity period becomes irrelevant once the trust basis no longer holds.

A private key may be compromised through a breach or misconfiguration. An employee with a client certificate may leave the organization. A certificate authority (CA) itself may need to withdraw trust from certificates it has issued. Without a reliable mechanism to invalidate certificates before their natural expiration date, organizations are left exposed to attacks that exploit credentials the PKI no longer considers trustworthy.

Certificate revocation is that mechanism, and the certificate revocation list (CRL) is its oldest and most widely deployed implementation.

What is certificate revocation?

Certificate revocation is the act of invalidating a digital certificate before its scheduled expiration date. It is a foundational operation within PKI, ensuring that certificates no longer deemed trustworthy cannot be used to authenticate identities or encrypt communications.

During a certificate’s validity period, the certificate owner or the certificate authority (CA) that issued the certificate may determine that it should no longer be trusted. When that happens, the un-trusted certificate needs to be revoked and relying parties (browsers, servers, applications, etc.) need to be informed. The primary mechanism for communicating this revocation status is the certificate revocation list.

In a well-managed PKI, the ability to revoke trust is fundamental. It is the control that ensures the integrity of the trust chain when real-world conditions change faster than certificate validity periods allow.

What is a certificate revocation list?

A certificate revocation list can be defined at several levels of specificity:

At its simplest, a CRL is a list of revoked certificate serial numbers published by a certificate authority.

The CA Security Council defines it as “a digitally-signed file containing a list of certificates that have been revoked and have not yet expired.”

RFC 5280, the Internet Standard that governs X.509 PKI, provides the formal definition: a CRL is “a time-stamped and signed data structure that a certificate authority (CA) or CRL issuer periodically issues to communicate the revocation status of affected digital certificates.”

The CRL format is defined in the X.509 standard and specified in detail by RFC 5280. Each entry in a CRL includes the serial number of the revoked certificate and the date of revocation. Entries may optionally include a time limit for the revocation and a reason code explaining why the certificate was revoked.

CAs publish CRLs on a regular schedule (hourly, daily, or weekly, depending on policy and risk tolerance). A revoked certificate can have one of two statuses on a CRL:

• Revoked: The revocation is permanent and irreversible. The certificate will never be trusted again.
• Hold: The revocation is temporary. The certificate’s trust is suspended, but it may be reinstated if circumstances change.

How certificate revocation lists work

The role of the certificate authority

CRLs are issued and maintained by the certificate authority that originally issued the certificates. The CA digitally signs each CRL it publishes, and this signature is critical: it proves the authenticity of the file and prevents tampering.

Any relying party that downloads a CRL can verify the CA’s signature to confirm the list has not been altered in transit. In most deployments, the CRL is signed by the same entity that issued the certificates. However, in some cases, a CA will designate another authorized signer to issue CRLs on its behalf, a configuration supported by the X.509 standard but used infrequently in practice.

CRL structure and contents

According to RFC 5280, a CRL contains the following key fields:

• Issuer name: The distinguished name of the CA that issued the CRL
• This update: The date and time the CRL was published
• Next update: The date and time by which the next CRL will be published (effectively, the CRL’s expiration)
• Revoked certificates list: A sequence of entries, each containing:
  • The serial number of the revoked certificate
  • The revocation date
  • Optional extensions, including revocation reason codes
• CA’s digital signature: Authenticates the entire CRL

Per RFC 5280, expired certificates are normally removed from the CRL once their original validity period has passed, since they would no longer be accepted regardless of revocation status. However, this behavior is configurable by the CA.

CRL entries and revocation reason codes

The X.509 standard defines several reason codes that a CA can attach to a CRL entry. These codes provide context about why a certificate was revoked, which can be important for forensic analysis and for determining whether content signed before the revocation date should still be trusted.

The standard reason codes include:

• Key Compromise: The certificate’s private key has been compromised. Content previously signed with this key should not be trusted.
• CA Compromise: The issuing CA’s own private key has been compromised, casting doubt on all certificates it issued.
• Affiliation Changed: The certificate holder’s organizational affiliation has changed (for example, a subsidiary was sold).
• Superseded: The certificate has been replaced by a newer certificate.
• Cessation of Operation: The entity has ceased operations, or the domain or server associated with the certificate is no longer owned by the certificate holder.
• Privilege Withdrawn: The certificate holder’s authorization has changed (for example, an employee has left the organization). Pre-revocation signatures may still be considered valid, since the holder was authorized at the time of signing.
• Certificate Hold: The certificate is temporarily suspended. It can be reinstated with a “removeFromCRL” entry on a subsequent delta CRL.

Certificates may also be revoked for being improperly issued, obtained through fraud, or issued in violation of the CA’s certificate practice statement.

How browsers and applications check CRLs

When a user connects to a website or service secured with a digital certificate, the relying party (browser, application, or operating system) performs a series of validation steps. CRL checking is a core part of this process:

1. CRL Distribution Points: At the moment of creation, certificates contain a CRL Distribution Points (CDP) extension that lists one or more URLs where the issuing CA’s CRL can be retrieved whenever they need to be validated.
2. TLS handshake: When initiating a TLS session, the browser initiates the connection and receives the server’s certificate.
3. CRL retrieval and check: The browser fetches the CRL from the URL specified in the certificate’s CDP extension and checks whether the certificate’s serial number appears on the list.
4. Decision: If the certificate is not on the CRL, the connection proceeds. If it is listed, the browser alerts the user that the certificate has been revoked and the connection should not be trusted.

This validation is an essential step in every PKI-based transaction. However, it introduces a practical concern: if the browser does not have a recent copy of the CRL cached locally, it must fetch the full CRL during the initial connection, adding latency. Browsers do cache CRLs to mitigate this, but caching creates a time window during which a recently revoked certificate will still be accepted.

Types of certificate revocation lists

Full (combined) CRLs

A full CRL, sometimes called a combined CRL, contains every revoked certificate from the issuing CA that has not yet expired. Each time the CA publishes an updated CRL, it builds the complete list from scratch.

Full CRLs are straightforward to implement and widely supported across all PKI clients. The format is easy to audit. Every relying party that downloads the CRL gets a complete picture of revocation status. However, for CAs that have revoked large numbers of certificates, full CRLs can become extremely large, consuming significant bandwidth and increasing download times. This makes them best suited for smaller PKI deployments where the total number of revoked certificates remains manageable.

Partitioned CRLs

Partitioned CRLs divide revocation information across multiple separate CRL files. This option allows to spread the serial numbers of the revoked certificates across a predetermined number of partitions. Certificates are assigned to a randomly-generated CRL partition number upon issuance.​ This way, relying parties can identify the correct partition via the CDP extension, and the corresponding partition is requested.​ ​

The advantage is scalability. Instead of downloading a single massive CRL, a relying party downloads only the partition relevant to the certificate it is validating. This approach reduces bandwidth consumption, speeds up CRL generation on the CA side, and allows independent caching of each partition. However, it requires that both, the relying party and the Partitioned CRLs are the standard approach for large enterprise PKIs managing tens of thousands of certificates or more.

Delta CRLs

A delta CRL contains only the changes (additions and removals) since the last full (base) CRL was published. Instead of re-downloading the entire list, a relying party that already has the base CRL only needs to fetch the delta to bring its revocation data up to date.

Delta CRLs significantly reduce bandwidth requirements, especially in environments with large base CRLs and relatively few revocations between publication cycles. However, they are heavily reliant on the base CRL, and verification may fail even if the delta CRL is available.

CRL lifecycle: updates, expiration, and frequency

Update frequency and the “next update” field

Every CRL includes a “next update” timestamp that tells relying parties when to expect the next version. CAs publish new CRLs on a schedule defined by their certificate practice statement:

• Root CA CRLs: Published every few months to years. Root CA private keys are stored offline, so CRL generation requires physical access to the signing key.
• Issuing (subordinate) CA CRLs: Published every few hours to days. These CAs are online and can automate CRL generation more readily.

Frequency heavily depends on the CA’s policy. An offline root CA (a certificate authority that is kept offline for security reasons) may generate a new CRL every year, or even less often. On the contrary, an issuing CA in a high security environment may generate a new CRL every hour, or even more often.

Administrators can also trigger manual CRL publication immediately after a high-priority revocation event, ensuring that the revocation is propagated without waiting for the next scheduled update.

What happens when a CRL expires

If a CRL reaches its “next update” time and no replacement has been published, or if the CRL endpoint becomes unreachable, the consequences are severe: all certificates issued by that CA become immediately unusable. Relying parties that cannot obtain a valid, current CRL have no way to confirm whether a certificate has been revoked, and many will reject the certificate outright.

This behavior (fail-closed) is the secure default. Some implementations offer a fail-open option that accepts certificates even when a current CRL cannot be retrieved, but this trades security for availability and is not recommended for production environments.

CRL expiration is one of the most common causes of unexpected PKI outages, making CRL monitoring a critical operational requirement.

How to check a certificate revocation list

Certificates include a CRL Distribution Points (CDP) extension that contains the URLs where the corresponding CRL can be downloaded. There are several common methods for checking a CRL:

• Windows: The certutil command-line tool can download, parse, and display CRL contents.
• macOS and Linux: OpenSSL provides commands to fetch and decode CRLs from CDP URLs.
• Browsers: Modern browsers perform CRL (or OCSP) validation automatically during TLS handshakes, alerting users if a certificate has been revoked.

A dedicated guide to checking CRLs with specific tools and commands is available in the Keyfactor Education Center.

Why CRLs are important

Without functioning certificate revocation, PKI loses its ability to respond to changing trust conditions. The risks of operating without effective CRL management are significant:

• Trust validation: CRLs are the mechanism that confirms a certificate is still trusted by its issuing CA. Without them, relying parties have no way to distinguish a valid certificate from one that has been compromised.
• Backdated revocation: CRL entries include the revocation date, allowing organizations to determine when trust was withdrawn. This is essential for forensic investigations, where knowing the exact moment a certificate became un-trusted affects the validity of everything signed with it.
• Data breaches: A compromised certificate that remains trusted enables man-in-the-middle (MITM) attacks. Attackers can intercept encrypted traffic containing Social Security numbers, bank account credentials, credit card data, and protected health information.
• Identity theft and impersonation: Un-revoked compromised certificates can be used for credential theft and business email compromise (BEC) campaigns, allowing attackers to impersonate trusted entities.
• Financial loss: Stolen banking credentials, payment card data, and corporate authentication tokens can all be harvested through connections that rely on certificates that should have been revoked.
• Malware distribution: Compromised code-signing or TLS certificates can be used to install keyloggers, deploy ransomware, or recruit devices into DDoS botnets, all while appearing legitimate to the victim’s systems.

Get a demo

CRL distribution and hosting

CRL distribution points (CDPs)

A CRL Distribution Point is the location (typically an URL on a LDAP directory server or web server) where a CA publishes its CRLs. The CDP URL is embedded in every certificate the CA issues, via the CDP extension, so that relying parties know where to fetch the CRL.

CDPs must be reachable at all times. If a relying party cannot contact the CDP to retrieve a current CRL, certificate validation will fail. For this reason, LDAP-based CDPs are not recommended for public-facing PKI. Web server (HTTP/HTTPS) CDPs are the standard for most deployments.

Hosting strategies

Organizations have several options for hosting CRL endpoints, each with different availability and scalability characteristics:

• Web servers: The simplest approach. A standard HTTP server hosts the CRL files, and certificates reference its URL as the CDP. Suitable for small to mid-size PKIs.
• Content delivery networks (CDNs): Distribute CRL files across geographically distributed edge nodes, providing high availability and low latency for global deployments.
• Web farms: Multiple web servers behind a load balancer provide redundancy and fault tolerance.
• LDAP directories: Historically used in enterprise Active Directory environments. Largely deprecated for new deployments in favor of HTTP-based distribution.

Caching considerations

Relying parties cache CRLs locally until the “next update” timestamp expires. While caching reduces load on CDP endpoints and improves connection latency, it introduces a window during which a recently revoked certificate may still be accepted by a client using a cached (and now outdated) CRL. This trade-off between freshness and performance is inherent to CRL-based revocation and should be factored into CRL publication frequency decisions.

Large CRL downloads also increase latency during the initial connection when no cached copy exists, which can affect user experience and application performance.

CRL monitoring and management

Why CRL monitoring is critical

Mismanagement can have serious consequences. if your CRL is expired or unreachable, all of your certificates become immediately unusable. A single missed CRL publication or an unreachable CDP can trigger a widespread outage affecting every service that depends on certificates from that CA.

What to monitor

Effective CRL monitoring should cover:

• Endpoint responsiveness: Confirm that all CDP URLs are reachable and returning valid CRL data.
• Upcoming expiration dates: Alert when a CRL’s “next update” timestamp is approaching and no replacement has been published.
• Expired CRLs: Immediately flag any CRL that has passed its “next update” time without being replaced.

CRL generation and automation

CRL generation can be manual (triggered on demand by an administrator) or automated through several mechanisms:

• CRL Update Service Workers: Background processes that generate and publish CRLs on a configured schedule.
• Event-triggered generation: Automatic CRL publication immediately after a certificate is revoked.
• Unix cron jobs: Scheduled tasks that trigger CRL generation at fixed intervals.

As a best practice, newly created CAs should publish an empty CRL immediately upon creation. This ensures that relying parties can validate the CA’s certificates from day one, even before any revocations have occurred.

Common CRL challenges and limitations

While CRLs remain a fundamental revocation mechanism in PKI, they carry well-known operational challenges:

• Scalability: CRL files grow with every revocation. For large CAs, CRLs with millions of entries are possible, and downloading and parsing these files becomes resource-intensive. This is particularly problematic for constrained devices such as smartphones and IoT endpoints with limited memory and processing power.
• Latency: The entire CRL must be downloaded and parsed to check a single certificate’s status. Unlike OCSP, which returns a focused response for one certificate, CRLs provide no way to query individual entries.
• Connection overhead: If no recent CRL copy is cached, the relying party must fetch the CRL during the initial TLS handshake, adding measurable latency to the connection setup.
• Caching windows: The gap between CRL publications creates a window during which a revoked certificate may still be accepted by relying parties using a cached copy. Shorter publication intervals reduce this window but increase CA and network load.

CRL best practices

Managing CRLs effectively requires deliberate planning and operational discipline. The following practices address the most common failure modes:

1. Set update frequencies based on risk. Issuing CA CRLs should be published every 24 to 72 hours. Root CA CRLs, where signing keys are kept offline, can be published every 3 to 12 months. Match the frequency to the sensitivity of the certificates being issued.
2. Monitor CRL endpoints proactively. Do not wait for an outage to discover that a CDP is unreachable or a CRL has expired. Implement automated monitoring that checks endpoint availability and alerts on approaching expirations.
3. Automate CRL generation. Manual CRL publication is error-prone and does not scale. Use scheduled jobs, service workers, or event-triggered automation to ensure CRLs are published reliably and on time.
4. Plan for high availability. CRL endpoints are critical infrastructure. Use CDNs, web farms, or load-balanced web servers to ensure that CDP URLs remain reachable even during server failures or traffic spikes.
5. Use partitioned CRLs at scale. If your PKI issues large volumes of certificates, use partitioned CRLs to keep individual CRL files at a manageable size.
6. Align CRL policy with security requirements. The trade-off between CRL freshness and operational overhead should be an explicit policy decision, informed by the organization’s risk tolerance and the sensitivity of the systems protected by the PKI.
7. Account for caching behavior. Understand that relying parties will cache CRLs until the “next update” timestamp. Factor this caching window into incident response plans and revocation urgency decisions.

How Keyfactor can help

Managing CRLs and certificate revocation at scale requires both a capable PKI infrastructure and centralized visibility into revocation status across the environment.

EJBCA by Keyfactor is a full-featured, enterprise-grade CA platform that provides complete control over CRL generation and distribution. EJBCA supports manual and automated CRL publication, partitioned CRLs, and delta CRL generation, configurable CRL Distribution Point (CDP) settings, and flexible publication frequencies. As the CA platform responsible for issuing and revoking certificates, EJBCA gives PKI teams direct control over the revocation lifecycle from issuance through CRL publication.

Keyfactor Command provides the centralized visibility and automation layer that sits across every CA in the environment. Command monitors CRL and OCSP endpoints, sends configurable email alerts when CRLs approach expiration, and provides real-time revocation status monitoring across the entire certificate inventory. For organizations managing certificates from multiple CAs, Command consolidates revocation data from every CA into a unified monitoring dashboard, eliminating the risk of an expired or unreachable CRL going unnoticed.

Together, EJBCA and Keyfactor Command deliver end-to-end certificate lifecycle management: discovery, monitoring, issuance, renewal, and revocation, all through a unified platform.