Certificate Revocation: OCSP vs CRL — Which One Should Your Enterprise Use?

A device certificate is valid for two years. On day 3, the laptop is stolen.

For the next 727 days, that certificate — cryptographically signed, structurally valid, passing every signature check — could theoretically be used to authenticate to your corporate Wi-Fi, your VPN, your internal applications. The expiry date printed on the certificate says it is fine. The CA’s signature says it is fine. Only you know it is not.

This is the revocation problem. A certificate’s validity period and its trustworthiness are not the same thing, and the gap between them is a real attack surface. Certificate revocation is the mechanism that bridges this gap — the kill switch that tells relying parties “this certificate is no longer trustworthy, regardless of what the expiry date says.”

Two mechanisms have coexisted for three decades to solve this problem: CRL (Certificate Revocation Lists) and OCSP (Online Certificate Status Protocol). Both are standardized. Both are widely deployed. Both have serious trade-offs that matter enormously in enterprise environments. And the industry is now actively moving beyond both of them.

This guide explains how each mechanism works, where each fails, what the 2023 CA/Browser Forum decision means for enterprise PKI, and how BastionXP approaches revocation in a Zero Trust security architecture.

1. Why Certificate Revocation Exists — The Problem It Solves

X.509 certificates are designed to be verified offline. A relying party — a RADIUS server, a browser, a VPN gateway — can validate a certificate’s authenticity entirely locally: check the cryptographic signature against the issuing CA’s public key, check the validity period, check the subject fields. No network request required.

This offline verification model is one of PKI’s great strengths. It is fast, scalable, and works without a connection to the CA. But it creates a structural problem: the certificate carries no information about what has happened since it was issued.

A certificate issued to a corporate laptop two years ago says nothing about whether that laptop was stolen last Tuesday, whether the private key was exposed in a breach, or whether the employee who used it was terminated this morning. The signature is still valid. The expiry date has not passed. The certificate passes every static check.

Revocation is the mechanism that communicates post-issuance status. When a certificate needs to be invalidated before its expiry date, the CA records this fact and makes it available to relying parties through a published mechanism — either a list (CRL) or a real-time query service (OCSP).

When Revocation Actually Matters

• Lost or stolen device: The device certificate must stop granting Wi-Fi and VPN access the moment the device is reported missing — not two years from now when the certificate expires
• Employee termination: The device certificate belonging to a terminated employee’s laptop should be revoked as part of offboarding — independent of when the certificate would naturally expire
• Private key compromise: If a private key is exposed — in a breach, through a software vulnerability, or by a malicious insider — every certificate associated with that key must be invalidated immediately
• CA key compromise: If the CA’s own signing key is compromised, every certificate ever issued by that CA is suspect and must be revoked, regardless of individual certificate status

2. What is a CRL (Certificate Revocation List)?

A Certificate Revocation List is a signed, periodically published document that contains the serial numbers of all certificates the CA has revoked before their natural expiry date. It is the digital equivalent of a published blacklist.

How CRL Works — Step by Step

Step 1 — CA revokes a certificate. An administrator triggers revocation in the CA system. The CA records the certificate’s serial number, the revocation date, and optionally a reason code (keyCompromise, affiliationChanged, cessationOfOperation, etc.).

Step 2 — CA publishes the updated CRL. At the next scheduled publication interval (hourly, daily, or weekly depending on CA configuration), the CA compiles the full list of revoked serial numbers, signs the CRL with its private key, and publishes it to one or more CRL Distribution Points (CDPs) — URLs embedded in every certificate the CA issues.

Step 3 — Relying party downloads the CRL. When a relying party (RADIUS server, browser, VPN gateway) needs to validate a certificate, it reads the CDP URL from the certificate’s X.509 extension, downloads the CRL from that URL, and caches it locally.

Step 4 — Relying party checks the serial number. The relying party searches the downloaded CRL for the certificate’s serial number. If found: the certificate is rejected. If not found: the certificate is accepted as valid.

Step 5 — CRL is used until its “Next Update” timestamp. Every CRL contains a Next Update field specifying when the next CRL will be published. Relying parties use the cached CRL until this timestamp, then download the next one.

Delta CRLs

Full CRLs grow over time as more certificates are revoked. To reduce download size, CAs can publish delta CRLs — incremental updates that contain only the certificates revoked since the last full CRL. Relying parties combine the base CRL with the delta to reconstruct the complete revocation list. Delta CRLs can be published much more frequently than full CRLs, reducing the latency of revocation propagation.

CRL File Sizes in Practice

• A small enterprise CA with infrequent revocations: a few kilobytes
• A large enterprise CA with hundreds of device certificates: tens to hundreds of kilobytes
• A public CA (DigiCert, Sectigo) that has issued millions of certificates: multi-megabyte CRLs that clients must download, parse, and cache

3. What is OCSP (Online Certificate Status Protocol)?

OCSP (RFC 6960) is a real-time query protocol that lets a relying party ask the CA’s responder about the status of a specific certificate — without downloading a full list.

How OCSP Works — Step by Step

Step 1 — Relying party reads the OCSP responder URL. The certificate’s Authority Information Access (AIA) X.509 extension contains the URL of the CA’s OCSP responder. This URL is embedded by the CA at issuance time.

Step 2 — Relying party sends an OCSP request. The relying party constructs an OCSP request containing the certificate’s serial number and the issuing CA’s identity, and sends it to the OCSP responder via HTTP.

Step 3 — OCSP responder queries the revocation database. The OCSP responder (operated by the CA) looks up the serial number in its revocation database and constructs a signed response.

Step 4 — Responder returns a signed status. The response contains one of three values:

• Good — the certificate has not been revoked
• Revoked — the certificate has been revoked (with revocation date and optional reason)
• Unknown — the responder does not have information about this certificate

Step 5 — Relying party accepts or rejects. If the response is Good (and the response signature is valid and fresh), the certificate is accepted. If Revoked or if the response cannot be verified, the certificate is rejected.

OCSP Stapling

In standard OCSP, the relying party makes a separate HTTP request to the OCSP responder for every new TLS connection. This adds latency and exposes the relying party’s query to the CA.

OCSP stapling solves this: the TLS server pre-fetches its own OCSP response from the responder and caches it. The cached OCSP response is then “stapled” to the TLS handshake and sent directly to the client. The client does not need to make a separate OCSP request — it validates the stapled response inline.

OCSP stapling eliminates both the latency of a separate OCSP request and the privacy concern of the CA seeing per-connection queries.

Soft Fail vs Hard Fail

When an OCSP responder is unreachable — due to a network outage, maintenance window, or deliberate attack — the relying party must decide what to do:

• Soft fail (default in most browsers and clients): If the OCSP responder is unreachable, treat the certificate as valid and proceed. The rationale: availability matters more than enforcing revocation checking when the responder is simply down.
• Hard fail: If the OCSP responder is unreachable, reject the certificate. More secure, but causes availability incidents.

The soft-fail default is one of OCSP’s most significant security problems. We will discuss more about it in section 5 below.

4. CRL vs OCSP: Head-to-Head Comparison

Neither mechanism is universally superior. CRL is better for privacy and offline availability; OCSP is better for revocation latency. Both have failure modes that matter in different contexts — which is why the industry is increasingly asking whether either is the right answer at all.

5. The Three Critical Problems with OCSP

In August 2023, the CA/Browser Forum passed Ballot SC-063, which began the formal process of deprecating mandatory OCSP support for public TLS certificates. The reasons behind that ballot reflect three structural problems that have accumulated over decades of OCSP deployment.

Problem 1: OCSP is a Privacy Leak

Every OCSP query sent by a relying party tells the CA’s OCSP responder three things: which certificate is being validated, which IP address is making the request, and the exact timestamp of the connection.

For public TLS on the internet, this means a CA like DigiCert or Sectigo builds a detailed log of which browsers visited which websites, when, and from which locations — without the user’s knowledge or consent. The CA becomes an involuntary surveillance infrastructure.

In an enterprise context, the privacy concern shifts: an external CA operating your OCSP responder builds a behavioral record of every device connection event across your fleet. Even if you operate your own OCSP responder (as BastionXP does), the query pattern reveals connection behavior to whoever has access to OCSP logs.

OCSP stapling mitigates this for TLS servers that implement it — the server fetches its own OCSP response, removing the per-client query. But stapling is not universally implemented, and it does not help for client certificate validation (where the client, not the server, must query OCSP).

Problem 2: OCSP Soft-Fail is a Security Hole

The soft-fail default — accept a certificate as valid when the OCSP responder is unreachable — effectively means that an attacker who can block OCSP traffic can disable revocation checking entirely.

The attack is straightforward: compromise a certificate (or steal one from a lost device), then block the relying party’s ability to reach the OCSP responder. A firewall rule, a DNS manipulation, or a targeted DDoS against the OCSP responder is sufficient. The relying party falls back to soft-fail, accepts the revoked certificate, and grants access.

This is not a theoretical attack. It is a documented technique in certificate abuse scenarios, and it undermines the security guarantee that OCSP is supposed to provide. The protection exists only when the OCSP responder is reachable — which an attacker who already has a revoked certificate is motivated to prevent.

Hard-fail solves this problem theoretically: if OCSP is unreachable, reject the certificate. In practice, hard-fail causes significant availability incidents when OCSP responders have planned or unplanned downtime, and organizations that deploy it often revert to soft-fail after the first production outage.

Problem 3: OCSP Infrastructure is Expensive and Operationally Fragile

The CA must operate a globally distributed, highly available OCSP responder capable of responding to every TLS connection validation request across all relying parties — potentially millions of requests per second for a large public CA.

The responder must:

• Stay in continuous sync with the CA’s revocation database
• Respond with sub-100ms latency (any slower and it measurably delays TLS handshakes)
• Maintain near-100% availability (downtime causes soft-fail across all relying parties)
• Handle traffic spikes caused by mass certificate deployment or revocation events

This is expensive infrastructure to build and operate. For a private enterprise CA, operating an OCSP responder at the required availability and latency is a significant ongoing cost — one that scales with the size of the certificate fleet and the number of relying parties.

6. The Three Critical Problems with CRL

CRL does not escape criticism. The problems are different but equally real, particularly in enterprise PKI.

Problem 1: Revocation Latency Can Be Hours or Days

CRLs are published on a schedule, not in real time. A certificate revoked at 9:00 AM may not appear in the next CRL until the scheduled midnight publication. During that 15-hour window, the revoked certificate is accepted as valid by every relying party using the cached CRL.

For enterprise device revocation — a stolen laptop, a terminated employee — this window is a meaningful security gap. The device can authenticate to corporate Wi-Fi and VPN for hours after the revocation was triggered.

Delta CRLs reduce this latency by enabling more frequent incremental updates, but they add complexity and are not universally supported by relying parties.

Problem 2: CRL Size Grows with Revocation Volume

Every revoked certificate’s serial number remains on the CRL until the certificate’s original expiry date. An enterprise CA that revokes 50 device certificates per month, with 2-year certificate lifespans, will have 1,200 entries on its CRL within 2 years — and growing.

For a large enterprise or public CA, full CRL downloads become multi-megabyte operations. Parsing and searching a large CRL adds latency to the first connection check after a cache miss. This is the original motivation for delta CRLs and for CRL-alternative approaches like Chrome’s CRLSets (a curated, compressed subset of revocation data distributed via browser update).

Problem 3: CRL Distribution Point Availability

CRL distribution points must be highly available — a relying party that cannot download a CRL falls back to the cached (potentially stale) version or, in strict configurations, fails closed. An internal enterprise CDP hosted on a private server is a hidden single point of failure: if that server is down, all certificate validation across the enterprise degrades to using a potentially outdated CRL.

CDN-hosted CDPs are the mitigation — a globally distributed CDN makes the CRL effectively always available — but this adds infrastructure and requires the CDP URL to be reachable from every relying party, including RADIUS servers and VPN gateways behind internal firewalls.

7. What the Industry is Moving Toward: Short-Lived Certificates

The CA/Browser Forum’s 2023 movement away from mandatory OCSP reflects a broader consensus that is reshaping enterprise PKI: the most effective revocation mechanism is a certificate that expires before the revocation gap matters.

The Logic of Short-Lived Certificates

If a certificate is valid for 24 hours, a device compromised at noon becomes unauthenticated by midnight — without any revocation action by an administrator. The certificate expires before an attacker can make sustained use of it. This method is called as passive revocation (versus active revocation methods such as CRL and OCSP).

If a certificate is valid for 8 hours, a stolen device’s certificate is dead before the end of the business day.

With certificates this short-lived, CRL and OCSP become secondary concerns:

• CRL latency — a multi-hour revocation delay is irrelevant when the certificate expires in 8 hours regardless
• OCSP soft-fail — an attacker blocking OCSP gains nothing if the certificate expires in hours
• Revocation infrastructure cost — a CA that does not need to maintain a 2-year CRL or a high-availability OCSP responder saves significant operational overhead

The Prerequisite: Automation

Short-lived certificates only work if renewal is fully automated. A certificate that expires every 24 hours and requires a human to renew it is operationally catastrophic — it generates more help desk work than any password rotation policy ever did.

ACME (Automated Certificate Management Environment) is the protocol that makes this viable. ACME automates the full certificate lifecycle — issuance, renewal, and revocation — without human intervention. The ACME client on the device requests a new certificate before the current one expires, the CA validates the request and issues the new certificate, and the device installs it seamlessly in the background.

BastionXP is built around this model. Short-lived device certificates are issued via ACME, renewed automatically by the device’s OS ACME client or MDM before expiry, and re-attested against hardware security (Secure Enclave / TPM) at every renewal cycle for Apple and modern Windows devices. For a complete guide to this automation model, see ACME certificate automation for internal PKI.

CRL and OCSP Are Still Required — For Now

Short-lived certificates do not fully replace CRL and OCSP in all contexts:

• Some relying parties — older RADIUS servers, VPN gateways, legacy TLS clients — require either a CRL or OCSP endpoint and reject certificates that lack them
• Compliance frameworks may mandate revocation checking regardless of certificate lifespan
• Infrastructure certificates (CA intermediates, RADIUS server certificates) typically have longer lifespans and genuinely require revocation checking

BastionXP provides CRL and OCSP endpoints for all issued certificates, so relying parties that require them continue to work. The recommendation is to use short-lived device certificates as the primary revocation mechanism, with CRL/OCSP as a backstop for infrastructure and legacy relying parties.

8. OCSP and CRL in Enterprise PKI — What Actually Matters for Wi-Fi and VPN

The CRL vs OCSP debate plays out differently in an enterprise PKI context than in the browser/public CA world. Here is what the choice means in practice for the authentication workflows BastionXP supports.

Revocation Checking in EAP-TLS Wi-Fi Authentication

When a device connects to a WPA2-Enterprise SSID via EAP-TLS, the RADIUS server validates the device’s client certificate at Step 8 of the handshake. This validation includes a revocation check — and the choice of CRL vs OCSP determines how that check behaves.

RADIUS with CRL: The RADIUS server downloads the CRL from the CDP URL embedded in the certificate, caches it locally, and performs a serial number lookup. The check is fast (local lookup after initial download) and works without connectivity to the CA after the CRL is cached. The trade-off: revocation latency is bounded by the CRL publication interval — a certificate revoked at 9:00 AM may still authenticate until the next CRL is published.

RADIUS with OCSP: The RADIUS server sends a real-time query to the OCSP responder for every EAP-TLS authentication. The revocation check is current to within seconds. The trade-off: the RADIUS server must have network connectivity to the OCSP responder, and soft-fail behavior must be configured carefully — a RADIUS server that soft-fails on OCSP unreachability will accept revoked certificates when the responder is down.

BastionXP’s approach: Because BastionXP CA and RADIUS are the same platform, the RADIUS server database is always kept in sync (push updates) with the CA’s internal database — not via an external CRL download or OCSP request. Revocation is immediate and always current. When an administrator clicks “Revoke” in the BastionXP portal, the next EAP-TLS handshake from that device fails — no CRL publish cycle, no OCSP query latency.

Revoking a Stolen Device — The Real-World Timeline

With long-lived SCEP certificates + CRL:

1. IT administrator revokes the certificate in BastionXP
2. CRL is updated internally immediately
3. RADIUS server’s cached CRL still shows the certificate as valid until the next CRL download interval
4. Device may authenticate to Wi-Fi for hours after revocation

With long-lived SCEP certificates + OCSP:

1. IT administrator revokes the certificate
2. OCSP responder reflects revocation immediately
3. RADIUS server queries OCSP at next EAP-TLS handshake — device is rejected within seconds
4. Risk: if attacker blocks OCSP, soft-fail may allow authentication

With BastionXP short-lived ACME certificates:

1. IT administrator revokes the certificate in BastionXP
2. BastionXP RADIUS checks its internal revocation database directly — device rejected at next handshake
3. Even if the revocation is somehow missed: the certificate expires in a day or few hours, after which the device cannot renew without re-attestation
4. A stolen device that cannot reach BastionXP for renewal loses access automatically when the certificate expires

For the complete picture of how ACME Device Attestation secures corporate Wi-Fi and VPN with short-lived certificates, see our dedicated use-case guide.

9. How BastionXP Handles Certificate Revocation

Revoking a Certificate

In the BastionXP portal, navigate to Certificates → Issued Certificates, locate the certificate by device name or serial number, and click Revoke. The revocation is recorded immediately in BastionXP’s internal revocation database.

BastionXP’s built-in RADIUS server reflects this revocation at the next authentication attempt — because RADIUS queries its internal database that is always kept in sync with the CA’s database, there is no propagation delay.

CRL Configuration

BastionXP CA publishes a CRL at a configurable interval (default: every 24 hours). The CRL Distribution Point URL is automatically embedded in every certificate BastionXP issues. External RADIUS servers, VPN gateways, and TLS clients that require CRL checking can download the CRL from this URL.

OCSP Configuration

BastionXP operates an OCSP responder for all issued certificates. The OCSP responder URL is embedded in the Authority Information Access extension of every certificate. OCSP responses are signed by a dedicated OCSP signing certificate (not the CA root) and are valid for a configurable response lifetime.

For external relying parties that require OCSP, no additional configuration is required — the OCSP URL is embedded in the certificate and BastionXP’s responder is reachable from the internet.

Recommended Configuration by Use Case

10. Certificate Revocation Frequently Asked Questions

What is the difference between CRL and OCSP?

CRL is a periodically published list of revoked certificate serial numbers — relying parties download the full list and check it locally. OCSP is a real-time query protocol — the relying party asks the CA’s responder about a specific certificate and gets an immediate response. CRL is better for privacy and offline availability; OCSP is better for revocation latency and bandwidth efficiency for large CAs.

Which is faster — CRL or OCSP?

For revocation propagation, OCSP is faster — a certificate revoked at the CA is reflected in OCSP responses within seconds. CRL propagation depends on the publication interval — hours or days in a typical deployment, or minutes with delta CRLs. For the actual validation check (once the CRL is cached), CRL lookups are faster than OCSP queries because they are local.

Is OCSP more secure than CRL?

Not unambiguously. OCSP provides faster revocation propagation, which is a security advantage. But OCSP’s soft-fail default — accepting certificates when the responder is unreachable — creates a vulnerability that CRL does not have in the same way (a cached CRL is valid until its Next Update, providing a bounded security window). OCSP with hard-fail and OCSP stapling is more secure than CRL; OCSP with soft-fail and no stapling may actually be less secure in adversarial conditions.

What is OCSP stapling and why does it matter?

OCSP stapling allows a TLS server to pre-fetch its own OCSP response and include (“staple”) it in the TLS handshake. The client validates the stapled response without making a separate OCSP request. This eliminates the per-connection latency of OCSP queries, removes the privacy exposure of per-client OCSP queries to the CA, and removes the client’s dependency on the OCSP responder’s availability. Stapling is the recommended way to deploy OCSP for server certificates.

What happens if the OCSP responder is down?

In soft-fail mode (the default in most browsers and TLS clients): the certificate is treated as valid and the connection proceeds. In hard-fail mode: the certificate is rejected and the connection fails. Soft-fail means OCSP downtime does not cause service disruptions but also means revocation checking is bypassed. Hard-fail is more secure but causes availability incidents during OCSP outages.

What is a delta CRL?

A delta CRL is an incremental CRL update that contains only the certificates revoked since the last full CRL publication. Delta CRLs are much smaller than full CRLs and can be published much more frequently — reducing revocation propagation latency while keeping download sizes manageable. Relying parties combine the base full CRL with the delta to reconstruct the complete revocation list.

Are CRL and OCSP still required with short-lived certificates?

Not always. If a certificate expires in 24 hours, the revocation gap — the window during which a revoked certificate might be accepted — is at most 24 hours even without any revocation checking. For most enterprise device use cases, this is acceptable. However, some relying parties require a CRL or OCSP endpoint regardless of certificate lifespan, and CA/Browser Forum baseline requirements mandate CRL or OCSP for publicly-trusted certificates. BastionXP provides both for all issued certificates.

Does BastionXP support both CRL and OCSP?

Yes. BastionXP CA publishes a CRL at configurable intervals and operates an OCSP responder for all issued certificates. Both CRL Distribution Point and OCSP responder URLs are automatically embedded in every certificate BastionXP issues.

How does certificate revocation work with EAP-TLS Wi-Fi authentication?

In EAP-TLS, the RADIUS server validates the device’s client certificate during the 802.1X handshake. Revocation checking is part of this validation — the RADIUS server checks whether the certificate has been revoked via CRL lookup or OCSP query. See the EAP-TLS authentication guide for the full authentication flow.

What did the CA/Browser Forum decide about OCSP in 2023?

In August 2023, the CA/Browser Forum passed Ballot SC-063, which began the formal deprecation of mandatory OCSP support for publicly-trusted TLS certificates. The primary reasons were OCSP’s privacy implications (CAs learning per-connection browsing behavior), the soft-fail security gap, and the infrastructure cost of running globally available OCSP responders. The ballot accelerated the industry’s shift toward shorter certificate lifespans and CRL-based revocation (via mechanisms like Chrome’s CRLSets) as more practical alternatives.

Conclusion: CRL, OCSP, or Neither?

CRL and OCSP are not competing products where one is simply better than the other. They are different answers to the same question — “how does a relying party know if a certificate has been revoked?” — with different trade-offs that matter differently depending on the context.

CRL is better for: enterprise internal PKI with predictable revocation patterns, environments where privacy matters, RADIUS and VPN scenarios where the CA is co-located with the relying party, and contexts where offline availability is important.

OCSP is better for: public TLS where certificate lifespans are long and real-time revocation latency matters, scenarios where OCSP stapling is implemented on the server side, and environments that can sustain and operate a high-availability responder.

Short-lived certificates with ACME automation are better than both for device identity in enterprise Zero Trust architectures — they reduce the revocation gap without requiring revocation infrastructure, eliminate the soft-fail vulnerability, and integrate naturally with continuous device attestation via SCEP and ACME.

BastionXP supports all three from a single platform. CRL and OCSP are available for relying parties that require them. Short-lived ACME certificates are the recommended model for device credentials in Wi-Fi, VPN, and ZTNA authentication. The CA, RADIUS server, and revocation database are co-located — so revocation is always current, regardless of which mechanism your relying parties use.

Try BastionXP CA for free or read how EAP-TLS certificate authentication works end to end to see how revocation fits into the complete authentication flow.