Protocolo de estado de certificados en línea (OCSP) frente a listas de revocación de certificados (CRL)

Introducción

Every publicly trusted TLS certificate carries a promise: if it is ever compromised, lost, or issued in error, it can be revoked before its scheduled expiration date. Online Certificate Status Protocol (OCSP) and Certificate Revocation Lists (CRLs) are the two mechanisms that make that promise enforceable, and the choice between them has shifted meaningfully in the last two years. This guide explains how each method actually works, why the industry’s own recommendation has changed since this comparison was first written, and how to decide which approach fits a given environment.

In Short: OCSP vs. CRL

OCSP and CRLs are both used to check whether a certificate has been revoked before it expires. OCSP queries a Certificate Authority’s responder in real time for the status of one specific certificate, returning good, revoked, or unknown. A CRL is a signed, downloadable list of every certificate a CA has revoked, which a client checks locally without contacting the CA directly for each lookup.

Snapshot: What Changed Since This Comparison Was First Written

• OCSP checks a single certificate’s status in real time; a CRL is a full list a client downloads and checks locally.
• Let’s Encrypt, the certificate authority behind roughly half the web’s TLS certificates, shut down its OCSP responders entirely on August 6, 2025, moving fully to CRLs.
• The main driver was not performance but privacy: every OCSP request tells the CA which IP address is visiting which certificate’s site, in real time.
• Shorter certificate lifetimes under the CA/Browser Forum’s new validity schedule reduce, but do not eliminate, the window in which revocation checking matters.
• The right choice still depends on who controls both ends of the connection: a public CA serving arbitrary browsers has different constraints than an internal Active Directory Certificate Services (AD CS) deployment serving known clients.

Why This Comparison Reads Differently in 2026

The clearest signal that this topic has shifted came from Let’s Encrypt itself. In a December 2024 announcement, the nonprofit CA laid out a phased sunset of OCSP: new OCSP Must-Staple requests stopped being honored on January 30, 2025, OCSP URLs were removed from newly issued certificates by May 7, 2025, and its OCSP responders were shut down completely on August 6, 2025. Let’s Encrypt’s stated reasoning was blunt about the privacy cost of OCSP: a CA that answers OCSP queries learns, in real time, which IP addresses are visiting which of its certificate holders’ sites, information it could be compelled to retain or disclose. CRLs, by contrast, are downloaded in bulk and checked locally, so the CA never sees a per-visit query.

DigiCert’s Trust Pulse Survey, published July 2, 2025, found that nearly half of enterprises experienced a certificate related outage in the past year, with 37.5% of those incidents tied specifically to expired certificates and 18.5% of affected organizations reporting losses exceeding $250,000. A slow or unreliable revocation check, whether through an overloaded OCSP responder or a stale CRL cache, compounds exactly this kind of outage risk rather than only affecting security posture.

Certificate lifetimes are shrinking at the same time revocation practice is shifting. Under Boleta de votación del foro CA/Browser SC-081v3, approved April 11, 2025, publicly trusted TLS certificate validity drops from 398 days to 200 days starting March 15, 2026, then to 100 days from March 15, 2027, and to 47 days from March 15, 2029 onward. A certificate valid for 47 days simply has a smaller window in which revocation matters at all, which is part of why some CAs now treat CRLs as sufficient on their own rather than layering OCSP on top.

Longer term, NIST finalized its post quantum cryptography standards, FIPS 203, 204, and 205, on August 13, 2024. Neither OCSP responses nor CRLs are commonly signed with post-quantum algorithms today, but as CAs plan crypto-agile signing infrastructure, revocation data is one more artifact that will eventually need a migration path alongside the certificates it describes.

What Is OCSP?

Online Certificate Status Protocol (OCSP) is an internet protocol that lets a client ask a Certificate Authority’s responder whether one specific certificate is still valid, without downloading a full list of every certificate that CA has revoked.

How an OCSP Request and Response Work

An OCSP client sends a status request to an OCSP responder and waits for a signed reply before proceeding. The request includes the protocol version, the type of service being requested, an identifier for the target certificate, and any optional extensions. The responder checks that the message is well formed, that it is configured to answer for the CA in question, and that the request includes the information it needs, then returns either a definitive answer or an error.

A basic OCSP response includes the version of the response syntax, an identifier for the responder, the time the response was generated, a status for each requested certificate, optional extensions, the signature algorithm’s Object Identifier (OID), and a signature computed over a hash of the response so the client can verify it came from the CA unaltered. Three status values are possible: good, meaning the certificate has not been revoked as far as the responder knows; revoked, meaning the certificate was explicitly revoked or the CA has no record of ever issuing it; and unknown, meaning the responder does not recognize the issuer for that certificate.

Grapado OCSP

OCSP Stapling addresses OCSP’s biggest weakness directly: instead of the client contacting the CA, the web server itself periodically fetches a signed, time stamped OCSP response and staples it to the TLS handshake, so visiting browsers get the revocation status without ever contacting the CA. This removes the extra round trip and the privacy exposure of a per-visitor CA query, since the CA only sees the web server’s periodic refresh requests rather than every individual visitor. Stapling is not universally implemented, however, and it does not eliminate OCSP’s other operational costs; a CA still has to run responder infrastructure capable of handling refresh traffic at scale.

What Is a Certificate Revocation List (CRL)?

A Certificate Revocation List (CRL) is a signed list, published by the issuing CA, of every certificate that has been revoked before its scheduled expiration date and should no longer be trusted. Clients retrieve the CRL from a CRL Distribution Point, an X.509v3 certificate extension that points to an HTTP or LDAP location, and check locally whether the certificate they are validating appears on it.

Revoked vs. Hold States

A CRL entry can reflect one of two states. A revoked certificate is removed irreversibly, typically because of a key compromise, a CA compromise, an affiliation change, or another reason defined in the X.509 revocation reason codes; it cannot be reinstated. A certificate placed on hold is suspended temporarily rather than permanently revoked. For example, if a private key thought to be lost turns up safe, the certificate can come off hold and become valid again, which is a meaningful operational difference from an irreversible revocation.

How CRL Distribution Works in Practice

A CRL functions much like a blacklist. A client retrieves the current CRL from the CA’s published distribution point and checks that the certificate in question does not appear in it. Because the full list has to be downloaded and parsed, a large CRL can be considerably heavier on client and network resources than a single OCSP query, and publishing a fresh CRL after a new revocation is typically slower than an OCSP responder can answer in real time. Most TLS stacks are also configured to fail open: if a client cannot download the CRL at all, it defaults to trusting the certificate rather than blocking the connection, which is a known trade-off rather than a defect.

OCSP vs. CRL: Head to Head

Factor	OCSP	CRL
Lo que comprueba	Status of one specific certificate per request	Full list of every certificate the CA has revoked
Where the check happens	Client queries the CA’s OCSP responder directly, unless stapled	Client downloads the list once and checks locally
Exposición de la privacidad	CA sees each client’s IP address and which certificate it is checking, unless stapled	CA does not see individual per-visit queries
Network and client load	Low per request, but responders must handle high query volume	Can be heavy to download for large revoked-certificate lists
Comportamiento de falla	Responder outage can block or silently skip validation depending on client configuration	Missing CRL typically fails open, defaulting to trusting the certificate
2026 industry direction	Being phased out by major CAs including Let’s Encrypt as of August 6, 2025	Increasingly positioned as the primary or sole revocation mechanism, sometimes paired with short-lived certificates

Decision Matrix: Choosing a Revocation Checking Strategy

Caso de uso	Impacto en la seguridad	Esfuerzo Operacional	Ajuste de automatización	Propietario recomendado
Public-facing TLS certificates from a public CA	Medium, shorter validity periods reduce the exposure window	Low, most public CAs now manage this centrally	High, largely CA-managed	Equipos de plataforma
Internal AD CS or private PKI serving known clients	High, a compromised internal certificate can affect authentication broadly	Medium, requires running and scaling an Online Responder role	Medium, needs configuration but is stable once tuned	Administradores de PKI
Non-browser or IoT device fleets	Medium to high, depends on how devices are authenticated	Medium, CRL distribution at scale needs planning	Medium, scheduled CRL fetch is generally simpler than OCSP for constrained devices	Equipos de plataforma
High-security environments needing near-instant revocation checks	High, delay in revocation propagation is itself a risk	High, needs OCSP Stapling plus a CRL fallback path	Medium, requires both mechanisms configured correctly	Arquitectos de seguridad
Legacy or constrained clients without OCSP Stapling support	Media	Low, CRL checking is broadly supported without special configuration	High, CRLs work as a universal fallback	Compliance, Platform Teams

Choosing Between OCSP and CRL

There is no single universally correct answer, but the decision usually comes down to who controls both ends of the connection, how sensitive revocation timing is, and what the client population can actually support.

Una guía de decisiones rápidas

1. If every client and the CA both support OCSP Stapling, use stapling as the primary mechanism, with a CRL as a documented fallback for clients that do not support it.
2. If minimizing what the CA can observe about visitor behavior is a priority, prefer CRLs, or pair short-lived certificates with CRLs so the exposure window stays small even without real-time checking.
3. If the client population includes non-browser software, IoT devices, or network appliances that cannot implement stapling, CRLs are usually the simpler and more universally supported path.
4. If the environment is an internal AD CS deployment or private PKI where the organization controls both the CA and every client, OCSP with a properly scaled Online Responder role remains a practical option, since the privacy concern that drove Let’s Encrypt’s decision applies mainly to public CAs serving unknown clients.

Pros y contras de un vistazo

• OCSP pros: checks only the certificate in question rather than an entire list, and returns a real-time answer when the responder is healthy.
• OCSP cons: exposes visitor IP addresses and site visits to the CA unless stapled, and responder outages have historically been handled inconsistently across clients.
• CRL pros: no per-visit query to the CA, works as a reliable fallback everywhere, and is now the primary or sole mechanism at CAs the size of Let’s Encrypt.
• CRL cons: full-list downloads can be large for a CA with many revocations, and publishing delays mean a very recent revocation may not appear immediately.

¿A quién debería importarle esto?

The shift away from OCSP at major public CAs changes concrete operational decisions for several roles.

Administradores de PKI

Configure and maintain the Online Responder or CRL Distribution Points your CA actually depends on. Action item: confirm which of your certificates still reference OCSP URLs from a CA that has since deprecated the service, and verify CRL Distribution Points are reachable and current.

Arquitectos de seguridad

Decide the revocation checking posture for high-security systems. Action item: document a fallback path for any system still assuming OCSP availability, since responders at some public CAs no longer exist.

Equipos de plataforma

Own client configuration across servers, load balancers, and device fleets. Action item: verify TLS termination points that expect OCSP Stapling responses have a CRL fallback configured rather than failing silently.

Equipos de cumplimiento

Confirm that revocation checking evidence still matches how certificates are actually validated in production. Action item: update audit documentation that still cites OCSP as the default mechanism if the relevant CA has moved to CRLs.

CISO

Weigh the privacy and reliability trade-offs of revocation checking as part of the broader certificate lifecycle strategy. Action item: ask whether shorter certificate lifetimes under the CA/Browser Forum’s schedule change how much the organization needs to invest in real-time revocation infrastructure versus CRL-based checking.

Our Take: How Encryption Consulting Supports Certificate Revocation and Lifecycle Management

Whether an environment relies on OCSP, CRLs, or a mix of both, the underlying requirement is the same: know which certificates exist, how they are validated, and whether that validation path still matches how the issuing CA actually operates today.

Nuestros Administrador de CertSecure platform gives teams full machine identity inventory and certificate discovery across an environment, so a CA level change like Let’s Encrypt’s OCSP sunset does not surface as a surprise outage. For teams weighing whether to keep managing revocation infrastructure in-house, our PKI como servicio platform runs the CA hierarchy, including revocation publishing, on FIPS 140-3 Level 3 HSM-backed keys while your organization retains ownership and control. For a deeper look at related revocation mechanics, see our guides on the OCSP Magic Number, a Windows-specific threshold that silently switches from OCSP to CRL checking, and CRL reason codes, which cover what each revocation code actually means in practice. On the crypto-agility side, our Centro de Excelencia PQC y Evaluación de preparación de PQC help teams plan for a future where revocation data itself needs post-quantum-safe signing, and our CBOM seguro cryptographic discovery and inventory platform gives security architects visibility into exactly which certificates in an environment still depend on a deprecated OCSP responder.

Conclusión

OCSP and CRLs solve the same problem, confirming a certificate has not been revoked, through different trade-offs between real-time accuracy, privacy, and operational simplicity. What has genuinely changed since this comparison was first useful is that the industry’s default answer flipped: Let’s Encrypt’s full OCSP shutdown on August 6, 2025 shows that CRLs, once treated as the older and heavier option, are now the primary mechanism at the CA level that issues more certificates than any other. Teams that still assume OCSP is universally available, or that have not checked whether their CA has followed Let’s Encrypt’s lead, should treat that as an overdue configuration review rather than a settled assumption.

Preguntas frecuentes

What is the main takeaway from Online Certificate Status Protocol (OCSP) vs Certificate Revocation Lists (CRLs)?

OCSP checks a single certificate’s status in real time but exposes visitor activity to the CA unless stapled, while CRLs are a downloadable list checked locally. Major CAs, including Let’s Encrypt as of August 6, 2025, have shifted from OCSP to CRLs as the primary mechanism.

¿Por qué es importante esto para los equipos de PKI empresariales?

Configurations and audit documentation written when OCSP was the default assumption may no longer match how a given CA actually validates certificates today, which can create silent gaps in revocation checking.

What risks increase if revocation checking is handled manually or left unreviewed?

Systems can end up silently trusting certificates that should have been rejected, either because an OCSP responder they depend on has been shut down or because a stale CRL cache is never refreshed, and no one notices until an incident occurs.

Which teams should own this decision?

PKI administrators own the responder and distribution point configuration, security architects set the revocation checking posture for sensitive systems, platform teams own client-side configuration, compliance verifies documentation matches reality, and the CISO weighs the overall privacy and reliability trade-off.

¿Cómo se relaciona esto con la gestión del ciclo de vida de los certificados?

Revocation checking is one stage of the certificate lifecycle alongside issuance, renewal, and expiration. Certificate lifecycle management tooling that provides full discovery and inventory makes it possible to know which certificates depend on which revocation mechanism before a CA changes its infrastructure.

How should organizations measure whether their revocation checking strategy is working?

Track whether any certificates still reference OCSP URLs from a CA that has deprecated the service, confirm CRL Distribution Points resolve and are current, and monitor for outages tied to failed or slow revocation checks rather than only tracking certificate expiration.

¿Qué se debe auditar o supervisar periódicamente?

Regularly confirm which revocation mechanism each issuing CA actually supports, verify OCSP Stapling is functioning where configured, check that CRL fetch intervals are appropriate for the certificate population, and revisit assumptions any time a CA publishes an infrastructure change.

How does this topic affect cloud, hybrid, or multi-CA PKI environments?

An environment that mixes a public CA like Let’s Encrypt with an internal AD CS hierarchy or a cloud-native CA may need different revocation strategies for each, since a public CA’s move to CRLs does not require or imply the same change for an internal PKI serving a known client population.

¿Qué errores comunes deben evitar los equipos?

Common mistakes include assuming OCSP is universally available without checking whether the issuing CA still runs a responder, treating a missing CRL’s fail-open behavior as a bug rather than a known design trade-off, and never revisiting revocation configuration after initial deployment.

What should be refreshed quarterly for a revocation checking strategy?

Review whether any issuing CA has announced changes to its OCSP or CRL infrastructure, confirm certificate inventories are updated, revisit the CA/Browser Forum’s published validity schedule for changes, and check whether shorter certificate lifetimes have reduced the practical need for real-time revocation checking in a given environment.