OCSP vs CRL: The Best Bet To Revoke Certificates In A PKI

Online Certificate Status Protocol (OCSP) and certificate revocation lists (CRLs) are different methods of verifying certificate status. While they have similarities, the modern choice between OCSP vs. CRL is clear: across all important categories, CRL outperforms OCSP.

In this article, we’ll explain how OCSP and CRLs work, compare their strengths and weaknesses, and examine why browsers, certificate authorities (CAs) and enterprise public key infrastructure (PKI) deployments are increasingly picking CRLs over OCSP for modern certificate revocation.

You can also watch our video to learn more about OCSP and CRL certificate revocation in PKI deployments:

Why Certificate Lifecycle Management Is Critical

Expired certificates can cause outages that block legitimate users from accessing resources, while granting access with revoked certificates creates serious security risks. That’s why staying ahead of certificate lifecycle management is important for a healthy and secure business.

But network administrators shouldn’t have to spend all their time performing certificate revocation status checks and monitoring revocation dates.

Instead, admins need certificate lifecycle automation systems that handle daily operations reliably and securely, keeping accounts and devices safe from unauthorized access.

With automated tools, manual OCSP and CRL checks aren’t the only way to confirm certificate validity.

SecureW2 helped a leading data and AI platform company secure more than 17,000 devices with automated certificate enrollment and revocation, replacing pre-shared keys with certificate-based Wi-Fi and VPN authentication. Read the full case study.

What Is OCSP (Online Certificate Status Protocol)?

OCSP stands for Online Certificate Status Protocol. This protocol, described in RFC 6960, can be used to request the revocation status of a specific digital certificate.

OCSP uses a Transport Layer Security (TLS) client to check revocation status in real time. The client requests the status of one certificate and receives a signed response verifying that certificate’s validity with one of the following responses:

• Good: The certificate is currently valid
• Revoked: The certificate is revoked (response includes a reason code and timestamp)
• Unknown: The OCSP responder can’t determine the status of the certificate

Why Is OCSP Important?

OCSP is helpful because it delivers the real-time status of a specific certificate upon request.

OCSP was created to be more efficient than CRL (which we’ll explain shortly). And in some ways, it was. Unlike CRLs, OCSP lets admins check a certificate's status without reviewing a list of all certificates.

Large numbers of individual requests are resource-intensive and ultimately slow down OCSP responders. If the responder is overloaded or goes down, requests receive error messages. Meanwhile, users with revoked certificates may gain access.

This, along with privacy concerns and rising costs, has contributed to the gradual shift away from OCSP. In August 2023, the industry’s standard body for CAs and browsers (the CA/Browser Forum) made OCSP optional for CAs — but a valid CRL is mandatory.

How to Check Certificate Revocation Status With OCSP Requests

In OCSP, every authentication request requires the Remote Authentication Dial-In User Service (RADIUS) server to look up the certificate status in the PKI over HTTP.

The OCSP response requires several PKI operations, including digitally signing it with a private key. This response is then sent back to the RADIUS server and requires another cryptographic operation, which is expensive in terms of server load, to verify the response.

Here are the steps to check certificate revocation status with OCSP:

1. Client extracts CA-operated OCSP URL from a specific certificate’s embedded Authority Information Access (AIA) extension
2. Client creates an OCSP request with certificate serial number and issuer’s public-key and name hashes
3. Client sends request via HTTP GET (short requests) or HTTP POST (long requests)
4. OCSP server receives the request and references database to determine certificate status (CA updates database after each certificate revocation)
5. OCSP responder returns a digitally signed response with the certificate status (good, revoked, or unknown), validity period and responder’s signature
6. Client validates response signature against CA’s public key, proceeding with TLS handshake only if status is “good” and response is still within the validity period

The diagram below illustrates a simplified version of how this works, using a client connecting to a website as an example:

One solution to reduce lookup costs is a technique called “OCSP stapling,” which combines two necessary requests to further improve speed.

However, stapling is not supported for Wi-Fi client certificates. Some OCSP implementations are also vulnerable to replay or man-in-the-middle attacks.

What Is a CRL?

CRL stands for certificate revocation list. It’s exactly what it sounds like — a list of all the revoked certificates populated by the issuing CA.

But a CRL is more than just a list; it’s a much-needed security tool. Once a certificate is revoked and its serial number appears on that list, any system that references the CRL will refuse to authenticate that certificate. This includes network equipment such as RADIUS servers, as well as standard web browsers.

CRLs store the name of the issuing certificate authority, publication date of the latest CRL, date of the next updated CRL and the CA’s digital signature.

For every certificate revoked, CRL entries include the following details:

• Serial number of the revoked certificate
• Revocation date (not the original expiration date, but the date on which the CA invalidated the certificate)
• (Optional) Reason code explaining why the certificate was revoked

When a client requests a site’s certificate information, it accesses a specified CRL distribution point (CDP): the server-specific location of that CRL. If CDPs are unreachable, it’s almost impossible to check the current CRL.

Why Are CRLs Important?

CRLs matter because responsible certificate revocation keeps network resources, websites, and sensitive data safe, which is not possible without reliable certificate status checks.

As the modern industry standard, CRLs help protect publicly trusted CAs, organizations, application and website owners, and users from serious dangers.

Without reliable certificate revocation, compromised or fraudulently issued certificates may continue to be trusted, opening open the door to man-in-the-middle (MITM) attacks, exposing credentials and sensitive data such as financial records, credit card information and Social Security Numbers. Attackers may also use fraudulent certificates to distribute malware or trick users into downloading malicious software.

Cyberattacks like these can cause widespread data breaches, identity theft and impersonation, financial loss, data loss and diminished trust in an organization.

How to Check Certificate Revocation Status With CRL Distribution Points

When using a CRL to check certificate status, the client (such as a browser) requests authentication from a RADIUS server. The server communicates with the CRL and, based on the certificate status, can either authorize or refuse access.

Here’s a specific example of how to reference a CRL to check certificate revocation status for access to a WPA2-Enterprise network with Extensible Authentication Protocol-Transport Layer Security (EAP-TLS) authentication:

1. Client device presents digital certificate to wireless access point (AP).
2. AP forwards the certificate to RADIUS server.
3. RADIUS server verifies the certificate has not expired.
4. RADIUS server checks identity directory (such as Entra ID) to confirm the user is authorized.
5. RADIUS server downloads the CRL or references a cached copy, checking whether the certificate’s serial number appears on it.
6. If the certificate’s serial number appears on the CRL, the RADIUS server denies access.
7. If the certificate passes all checks, the RADIUS server grants network access.

The diagram below illustrates this process, but the exact steps vary depending on the request and what’s being accessed.

Checking Certificate Revocation With SecureW2 CRL

This process is much simpler with SecureW2 because our CRLs are pre-parsed for faster checks. The file is copied from our PKI at fixed intervals and requires a very simple public key decryption (verify signature) and a binary lookup of a serial ID in a file.

Essentially, we skip the slow parts of a CRL check by doing the heavy lifting of the authentication event in advance.

Even if the file grew to a few hundred megabytes, it would still be quicker to use the CRL because we use another improved CRL technique called “Delta + Base CRL”.

One unique thing about a certificate revocation list is it actually has two different types of lists. It has a base CRL and a delta CRL. The base CRL has every serial number of the certificates that should be revoked. A delta CRL has every serial number that's been added recently.
Micah Spady, Director of Product Marketing at SecureW2

In this setup, the RADIUS server stores a copy of the CRL locally for quick reference (the base CRL) and updates it regularly, often during off-peak times. The update request returns the delta CRL, a much smaller list that only contains changes to the base CRL since the last update, significantly reducing the load.

The image below shows you the SecureW2 CRL technique.

OCSP vs. CRL: Key Differences

The table below summarizes how OCSP and CRL differ across the most important dimensions for network architects and PKI administrators.

	OCSP	CRL
Definition	Real-time protocol for querying certificate revocation status from a CA-operated responder	Periodically published list of revoked certificate serial numbers signed by the issuing CA
How it works	Client sends certificate status request to an OCSP responder; responder returns a signed good/revoked/unknown status	Client downloads the CRL file and checks the target certificate’s serial number against the list locally
Speed & bandwidth	Fast query but slower under load; requires a live round-trip per authentication event	Slow at first with large initial download, then faster at scale; CRL is cached locally and checked with a binary lookup
Frequency of checks	On demand for every request	Periodically
Privacy	Low. Each OCSP request reveals to the CA which certificate (and site) the user is accessing	High. No real-time reporting to the CA; the client checks the list locally
Network failure behavior (offline capability)	Poor. Authentication may fail or experience a soft fail if the OCSP responder is unreachable	Strong. Cached CRL continues to function during network interruptions, up to its validity period
OCSP stapling support	Supported for TLS web certificates; not supported for Wi-Fi client certificates	Not applicable
Drawbacks	Slow and expensive at scale, not private (CAs see user activity), revoked certificates may gain access if OCSP responder is down	Revoked certificates retain access until next list publication, clients must download and cache entire list to check certificate status, constant updates require frequent downloads
Best for	Short-lived TLS certificates where real-time status is critical	Wi-Fi, VPN, and RADIUS deployments where speed, privacy, and offline resilience matter

Why Browsers and CAs Are Moving Away From OCSP

Although it’s often considered an upgrade, many popular browsers don’t even use OCSP: Google Chrome uses a CRL; Firefox uses a CRL (admittedly, with a soft check for OCSP if the CRL fails).

Some OCSP configurations are just using a CRL under the hood for most operations because it tends to be faster.

Ultimately, the limiting factor in checking revoked certificates is typically network latency, not CPU cycles, so CRLs are shown to perform better across distributed networks.

OCSP had the potential to replace CRL, but in its current state, OCSP is an inferior solution for Wi-Fi security applications.

CAs are taking notice, too. Let’s Encrypt shut down its OCSP services in August 2025, and they’re not alone.

These are the three main reasons CAs and browsers are phasing out OCSP

Lack of Privacy With OCSP Responder

The privacy problem with OCSP is straightforward: every time a browser checks a certificate, it sends the certificate’s serial number to the CA’s OCSP responder. That responder now knows which site the user is visiting, at what time, and from what IP address.

At scale, OCSP creates a detailed browsing record held by a third-party CA. Google’s decision to move Chrome to CRLSets was driven in part by this concern, alongside performance considerations.

Poor Reliability During Outages

Reliability is the second factor. An OCSP responder is a live service, and live services go down.

When an OCSP responder is unreachable, browsers must choose between blocking the user (hard fail) or allowing the connection anyway (soft fail). Soft-fail behavior, which most browsers default to, means OCSP revocation checks provide limited real security value during outages.

Slow Performance at Scale

Performance at scale is the third factor. A CRL is downloaded once and cached locally. Every subsequent revocation check against that CRL is a local binary lookup, not a network round-trip.

Across a distributed enterprise network with hundreds of daily authentication events, the cumulative latency difference is significant.

Why CRLs Are Better Suited to Wi-Fi and RADIUS Authentication

In the context of 802.1X authentication, the choice between OCSP vs. CRL is not just a performance question but a practical one.

OCSP stapling, which would otherwise reduce the per-authentication round-trip cost, is not supported for Wi-Fi client certificates. That removes the main performance mitigation that makes OCSP viable for web TLS.

RADIUS servers handling certificate-based authentication need to check revocation status for every device that connects. With OCSP, that means a live HTTP lookup against the PKI for each event.

With CRL and the Delta+Base CRL technique, the heavy cryptographic work is done in advance. The Base CRL is stored locally on the RADIUS server, and only the smaller Delta CRL is fetched during off-peak update cycles. The result is a revocation check that is both faster and more resilient to network interruptions than OCSP.

For organizations managing certificates across thousands of devices, this approach can make certificate-based authentication more efficient and resilient at scale.

Automate Certificate Revocation With JoinNow Dynamic PKI and Cloud RADIUS

Efficient revocation checks are only one part of maintaining a secure network. IT teams also need to manage certificate issuance, renewal, and revocation as users and devices change.

SecureW2 JoinNow Dynamic PKI and JoinNow Cloud RADIUS bring certificate lifecycle management and network authentication together in a cloud-based platform. Organizations can simplify PKI and RADIUS administration while enforcing certificate-based access across enterprise Wi-Fi and VPN deployments, without maintaining the same on-premises infrastructure.

Schedule a demo to see how SecureW2 simplifies certificate management and revocation for enterprise networks.

---

Frequently Asked Questions

Why are certificates revoked?

A certificate authority may revoke a website certificate or other digital certificate before it expires if it was issued fraudulently, the certificate’s private key or issuing CA was compromised, or the certificate was issued based on false or misleading information. A CA may also revoke a certificate if the website or application owner violates the CA’s terms or relinquishes ownership.

What is OCSP and how does it work?

OCSP (Online Certificate Status Protocol) is a real-time protocol defined in RFC 6960 for checking whether a digital certificate has been revoked.

A client sends a request containing the certificate’s serial number to an OCSP responder operated by the issuing CA. The responder returns a signed response indicating the certificate’s status: good, revoked, or unknown.

Unlike CRLs, which are downloaded and cached locally, OCSP requires a live network connection for each check.

What is a certificate revocation list (CRL)?

A certificate revocation list is a file published by a certificate authority that lists the serial numbers of all certificates the CA has revoked before their natural expiration.

Clients download the CRL and check it locally whenever they need to verify a certificate’s revocation status. CRLs are signed by the issuing CA so their authenticity can be verified without a live connection to the CA.

What is the difference between OCSP and CRL?

OCSP checks the revocation status of a single certificate in real time by querying a live CA-operated responder, while a CRL is a periodically updated list of all revoked certificates, which clients download and check locally.

OCSP introduces per-authentication network latency and privacy trade-offs; CRL trades absolute real-time accuracy for speed, resilience, and privacy.

For most enterprise Wi-Fi and RADIUS deployments, CRL with Delta+Base updates performs better than OCSP.

What is OCSP stapling?

OCSP stapling is a TLS extension that allows a web server to obtain and cache a signed OCSP response from the CA, then attach (“staple”) it to the TLS handshake for the client. This eliminates the client’s need to contact the OCSP responder directly, improving both performance and privacy.

However, OCSP stapling applies only to web server TLS certificates. It is not supported for Wi-Fi client certificates used in 802.1X authentication.

Why are browsers shifting away from OCSP?

Browsers are moving away from OCSP primarily because of privacy concerns, reliability issues, and performance at scale. OCSP lookups disclose user browsing activity to third-party CAs. OCSP responder outages lead to soft-fail behavior that provides little real security value. And local CRL checks are faster than live OCSP round-trips at enterprise scale. Google Chrome, for example, uses its own CRL distribution mechanism (CRLSets) rather than relying on OCSP.

But browsers aren't the only ones shifting from OCSP — certificate authorities are, too. Let's Encrypt shut down its OCSP services in August 2025.

What are the disadvantages of OCSP?

The main disadvantages of OCSP include per-request latency from live network lookups; privacy exposure because the CA learns which certificates clients are checking; availability risk when OCSP responders go offline; and lack of support for stapling in Wi-Fi client certificate contexts.

In soft-fail mode, OCSP outages mean revocation checks are silently bypassed, which undermines the security value the protocol is intended to provide.

Are CRLs still used today?

Yes, CRLs are still used by browsers, applications, and certificate authorities today. In fact, in 2023, CA/Browser Forum's Ballot SC063 made CRLs mandatory for CAs.

CRLs provide a traceable record of certificate validity that isn't susceptible to OCSP's issues with privacy (CAs could monitor browser activity), reliability (when OCSP responders are down, users with revoked certificates may gain access), and latency (one certificate per request creates more requests overall), along with rising costs at scale.

Due to these OCSP deficiencies, CRL remains the modern standard for reliable certificate status checks.