Certificate Revocation List (CRL) vs Online Certificate Status Protocol (OCSP): What You Need to Know

When a digital certificate can no longer be trusted, how does your infrastructure find out? The answer depends on whether you rely on Certificate Revocation Lists (CRLs), the Online Certificate Status Protocol (OCSP), or both. Each mechanism has distinct strengths and trade-offs, and the right choice depends on your environment, compliance requirements, and tolerance for risk.

This post breaks down how CRLs and OCSP work, where each one falls short, and how to decide which approach fits your PKI strategy.

Why certificate revocation matters

Certificates are the backbone of PKI. They enable trust, allowing users to authenticate identity across networks applications and devices, and encrypt communications in such environments. Every certificate has a finite validity period, which has been shrinking steadily: from 13 months (as of September 2020) to 200 days (March 2026), with further reductions targeting 100 days by March 2027 and 47 days by March 2028.

But validity periods only set the outer boundary. During that window, a CA or certificate owner may need to declare a certificate untrusted well before it expires. That is where revocation comes in.

Certificate revocation is an important, and often overlooked, function of certificate lifecycle management. Without a reliable way to revoke and communicate revoked status, compromised or misissued certificates remain trusted, leaving systems exposed.

To learn more about the fundamentals, visit our guides to the certificate revocation list and online certificate status protocol. Once you understand the difference between CRL and OCSP, learn how to view and check a CRL in practice.

What is a Certificate Revocation List (CRL)?

A CRL is a digitally signed file containing a list of serial numbers corresponding to certificates that have been revoked and have not yet expired. Defined in the X.509 standard and RFC 5280, 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.

Certificate revocation is the process of declaring a digital certificate untrusted before its scheduled expiration date.

How CRLs are structured and published

Each entry in a CRL includes the certificate’s serial number, the revocation date, an optional time limit, and a reason code. A certificate can carry one of two statuses:

• Revoked: permanently untrusted
• Hold: temporarily suspended, with the possibility of reinstatement

CAs publish CRLs on a schedule (hourly, daily, weekly, etc.) depending on their policy. Between publications, any newly revoked certificate will not appear on the list until the next update.

How browsers and applications check CRLs

When a browser initiates a TLS connection, it validates the server’s certificate and checks the associated CRL to confirm the certificate has not been revoked. Checking the CRLs is an essential step in a PKI-based transaction because they verify the identity of the site owner and discover whether the associated certificate is trustworthy.

The certificate itself contains one or more CDP URLs that point to where the CRL can be downloaded.

What is a CRL distribution point (CDP)?

A CDP is the location on a web server where a CA publishes CRLs. CDPs were traditionally deployed on LDAP servers, but his practice is increasingly uncommon in favor of simplicity. The browser or application downloads the CRL from the CDP, caches it until it expires, and parses it to determine revocation status.

This creates two requirements for reliable revocation checking:

• The CRL must be current (not expired).
• The CDP must be reachable at all times. If the CDP becomes unavailable, revocation status checks fail entirely.

For a step-by-step guide to finding and checking CDPs, see How to View and Check a Certificate Revocation List.

Common reasons for certificate revocation

Certificates are revoked for a range of operational and security reasons, including:

• Improper issuance: the certificate was issued incorrectly or without proper validation
• Fraudulent certificate: the certificate was obtained through deception
• Private key compromise: the certificate’s private key has been exposed or stolen
• CA compromise: the issuing CA itself has been compromised
• Domain ownership change: the entity that owns the domain has changed
• Validation misrepresentation or agreement violation: the certificate holder violated the terms of issuance or misrepresented information during validation

Without functional CRLs or an equivalent revocation mechanism, organizations face serious security risks: data breaches, identity theft, financial loss, and potential malware installation through compromised certificates.

Limitations of using CRLs alone

While CRLs are a foundational part of PKI, they come with notable limitations:

• File size: CRL files can become quite large, making them inefficient for use in devices with limited memory, like smartphones or IoT devices.
• Parsing overhead: the browser must download and parse the full list to check the status of a single certificate, which introduces latency and poor performance.
• Staleness window: because CRLs are published on a schedule, caching creates a time window where a revoked certificate might be accepted as valid.
• CDP availability: if the distribution point becomes unavailable, clients cannot check revocation status at all.

These limitations are exactly why the industry developed an alternative: the Online Certificate Status Protocol.

What is the Online Certificate Status Protocol (OCSP)?

OCSP offers a fundamentally different approach to revocation checking. Instead of downloading the latest CRL and parsing it to check whether a requested certificate is on the list, the browser requests the status for a particular certificate from the issuing CA’s revocation server.

Online Certificate Status Protocol (OCSP) is a method for checking the revocation status of a single certificate in real time, without downloading the entire CRL.

How OCSP works

When a client needs to verify a certificate, it sends an OCSP request to the CA’s OCSP responder. The responder returns one of three statuses:

• Good: the certificate is valid and has not been revoked
• Revoked: the certificate has been revoked
• Unknown: the responder does not have information about the certificate

OCSP responses are smaller than CRL files and are suitable for devices with limited memory. The protocol is described in RFC 6960.

Limitations of OCSP

OCSP solves the file size and freshness problems of CRLs, but introduces its own challenges:

• Privacy: each OCSP request reveals which site the user is visiting to the CA’s responder, creating a potential privacy concern.
• Industry shift away from OCSP for Web PKI: Let’s Encrypt, one of the world’s largest CA for Web PKI, announced in December 2024 that it would end OCSP support (effective May 2025), citing privacy concerns, infrastructure complexity, and cost. Other CAs have similarly moved to deprecate OCSP from their Web PKI offerings, signaling a broader shift back toward CRL-based checking for publicly trusted certificates.

What is OCSP stapling?

OCSP stapling addresses the privacy and performance drawbacks of standard OCSP. With OCSP stapling, the web server caches the OCSP response from the CA. When a TLS handshake is initiated by the client, the web server “staples” the OCSP response to the certificate it sends to the browser, eliminating the need for the browser to contact the CA directly.

Defined in RFC 6066, OCSP stapling delivers three key advantages:

• Improved performance: the browser receives the revocation status as part of the TLS handshake, removing the need for an additional round trip to the OCSP responder.
• Improved security: fewer false positives from unreachable OCSP responders and reduced attack vectors, since the browser no longer needs to make its own external request.
• Enhanced user privacy: CAs receive OCSP requests only from web servers, not from individual users, so browsing behavior is no longer exposed.

CRL vs OCSP: a side-by-side comparison

When to use CRL, OCSP, or both

The right approach depends on your environment, policy requirements, and risk tolerance. Here is practical guidance for common scenarios:

• Server environments: use CRL combined with OCSP stapling. The server handles revocation checking and staples the response, giving clients the best of both worlds.
• IoT and constrained devices: OCSP is often the better fit, since small per-certificate responses are far more manageable than large CRL downloads on devices with limited memory and bandwidth.
• High-security and compliance-driven environments: deploy both CRL and OCSP for redundancy. If one mechanism becomes unavailable, the other provides a fallback, ensuring continuous revocation coverage.

Which one to choose depends on the use case. For scenarios where the privacy of the request is importan, CRL is a better option. When it is necessary to have the latest status of the PKI and which certificates have been revoked, OCSP is better suited. And both can be used whenever it is necessary to have maximum reliability.

Using both CRLs and OCSP provides operational redundancy for certificate revocation checking. If one revocation mechanism becomes unavailable or experiences an outage, the other can continue to provide revocation status information, improving reliability and resilience of the PKI. Ultimately, the decision to deploy one or both mechanisms depends on the organization’s security and operational policies.

Why CRL and OCSP monitoring is critical

Regardless of which method you choose, monitoring your revocation infrastructure is essential. Consider this: if a CA is down, you will be unable to issue new certificates, but if your CRL is expired or unreachable, all of your certificates become immediately unusable.

That distinction makes revocation monitoring one of the most operationally critical functions in any PKI deployment.

Effective monitoring should cover:

• CRL monitoring: endpoint responsiveness, expiration warnings, and expired CRL alerts
• OCSP monitoring: endpoint responsiveness and response validity

Real-time and continuous revocation monitoring provided by certificate lifecycle automation tools like Keyfactor Command can ensure that this does not happen. By proactively tracking CRL and OCSP health, teams can prevent the kind of silent failures that lead to widespread outages.

To see how CRL checking works in practice, read How to View and Check a Certificate Revocation List.

Got certificate revocation questions? We’ve got answers.

What is the difference between a CRL and OCSP?
A CRL is a complete list of revoked certificates published periodically by a CA, while OCSP checks the status of a single certificate in real time. CRLs require downloading and parsing the entire file, whereas OCSP returns a lightweight, per-certificate response.

Can I use both CRL and OCSP at the same time?
Yes, and many organizations do. Running both provides redundancy: if one mechanism becomes unavailable, the other serves as a fallback. This is especially common in high-security and compliance-driven environments.

Why would a digital certificate be revoked?
Common reasons include private key compromise, CA compromise, improper issuance, fraudulent certificates, domain ownership changes, and validation misrepresentation or agreement violations.

Is OCSP more secure than CRL?
OCSP provides more timely revocation data, but it introduces a privacy concern because each request reveals which certificate the user is checking. Neither method is inherently “more secure”; each has strengths that suit different use cases and environments.

How often are CRLs updated?
CRL update frequency varies by CA policy. Common intervals include hourly, daily, and weekly. More frequent updates reduce the staleness window but increase infrastructure load.