CRL vs OCSP: Certificate Revocation Without the Hand-Waving
Revocation matters, but it is not a substitute for knowing where certificates are deployed and replacing them quickly.
Certificate revocation is the mechanism for saying, "This certificate should no longer be trusted before its expiry date." That can happen because a private key was exposed, a domain changed hands, a certificate was issued incorrectly, or an organization no longer controls the system using it.
The two classic mechanisms are Certificate Revocation Lists (CRLs) and the Online Certificate Status Protocol (OCSP). Both answer the same question: has this certificate been revoked? They differ in how that answer is distributed.
How CRLs work
A CRL is a signed list of revoked certificate serial numbers published by a certificate authority. Clients can download the list and check whether the certificate they are validating appears on it.
CRLs are simple and cacheable, but they can become large and stale. A client might not fetch the latest list immediately. A restricted network might block the CRL distribution URL. A server might be presenting a certificate that has technically been revoked, while clients continue accepting it because they cannot or do not check the list.
How OCSP works
OCSP lets a client ask an OCSP responder about one certificate at a time. Instead of downloading a whole list, the client asks for the status of a specific serial number and receives a signed response.
OCSP is more targeted than CRLs, but it introduces availability and privacy tradeoffs. If the responder is slow or unavailable, clients have to decide whether to fail open or fail closed. Many clients historically fail open for availability, which weakens revocation as a hard security control.
OCSP stapling improves this by letting the server include a fresh OCSP response during the TLS handshake. That reduces client-side lookups and keeps the status check closer to the connection. It still depends on the server fetching and refreshing the stapled response correctly.
The operational reality
Revocation is necessary, but it is not enough. If a key is compromised, the fastest reliable fix is to revoke the certificate, issue a replacement, deliver it to every affected endpoint, reload the services, and verify that the old certificate is no longer being served.
That response depends on inventory and automation. If your team does not know where the certificate is deployed, revocation tells the ecosystem not to trust it, but it does not remove the bad certificate from your infrastructure. If replacement requires manual copy-and-paste work, the exposed certificate may stay live for hours or days.
Why short lifetimes changed the conversation
The industry is moving toward shorter public TLS certificate lifetimes because revocation is inconsistent in practice. Short lifetimes reduce the maximum exposure window even when revocation checking fails. That does not make revocation irrelevant, but it shifts the operational priority toward rapid automated replacement.
For infrastructure teams, the right posture is layered: revoke when you need to, issue replacements automatically, deliver them reliably, and monitor what endpoints actually serve. CertLocker focuses on that lifecycle layer, where most certificate incidents are won or lost.