Certificates have expiration dates, but sometimes trust needs to be withdrawn before that date arrives. Certificate revocation is the mechanism that allows organizations to invalidate a certificate immediately when something goes wrong, whether a private key has been compromised, an employee has left, or a domain has changed ownership.
When a Certificate Authority issues a digital certificate, it sets a validity period: a start date and an expiration date. Under normal circumstances, the certificate is trusted throughout that window and rejected afterward. But what happens when a certificate needs to be invalidated before it expires?
This is where certificate revocation comes in. Revocation is the process by which a CA declares that a previously issued certificate should no longer be trusted, even though it has not yet expired. Without revocation, a compromised certificate would remain valid until its natural expiration, potentially giving an attacker days, weeks, or months to impersonate a legitimate server, sign malicious code, or intercept encrypted communications.
The PKI ecosystem provides two primary mechanisms for communicating revocation status to clients: Certificate Revocation Lists (CRLs) and the Online Certificate Status Protocol (OCSP). Each approach has distinct strengths and trade-offs, and understanding them is essential for anyone managing certificates at scale.
Not every certificate issue warrants revocation, but several scenarios absolutely require it. The CA/Browser Forum and RFC 5280 define standard revocation reasons that help organizations and relying parties understand why a certificate was withdrawn.
The most urgent reason. If the private key associated with a certificate has been exposed (through a server breach, stolen backup, or leaked repository), the certificate must be revoked immediately. Anyone with the private key can impersonate the certificate's identity.
When an employee leaves an organization, their client authentication or S/MIME certificates should be revoked. Similarly, when a domain is sold or transferred, the TLS certificates associated with it must be invalidated so the new owner can obtain fresh ones.
If a Certificate Authority's own signing key is compromised, every certificate it has issued is potentially untrustworthy. The CA must revoke affected certificates and, in severe cases, its own intermediate certificate may be revoked by the root CA. Mis-issuance (a certificate issued with incorrect information or without proper validation) also requires prompt revocation.
When a certificate is replaced by a new one (for example, after a key rotation or algorithm upgrade), the old certificate should be revoked to prevent confusion and reduce the attack surface. Decommissioned servers and retired services should also have their certificates revoked.
A Certificate Revocation List is the original revocation mechanism defined in the X.509 standard. A CRL is a signed file, published by a CA, that contains a list of serial numbers of all certificates that have been revoked before their expiration date. Each entry includes the certificate's serial number, the date of revocation, and optionally a reason code.
CRLs are published at URLs specified in the certificate's CRL Distribution Points extension. When a client (such as a browser or an application) needs to verify a certificate, it downloads the CRL from this URL and checks whether the certificate's serial number appears in the list. If it does, the certificate is rejected.
CRLs are periodically updated and signed by the CA, typically on a fixed schedule (every few hours or once a day). Each CRL includes a nextUpdate timestamp that tells clients when a newer version will be available. Between updates, clients cache the CRL locally to avoid repeated downloads.
The main limitation of CRLs is scalability. For a large CA that has revoked thousands of certificates, the CRL file can grow to several megabytes. Downloading and parsing a large file just to check a single certificate is inefficient, especially on mobile devices or in constrained network environments. Additionally, the gap between CRL publications creates a window where a recently revoked certificate might still be accepted by clients using a cached, outdated CRL.
OCSP (defined in RFC 6960) was developed to address the limitations of CRLs. Instead of downloading an entire revocation list, the client sends a lightweight request to an OCSP responder asking about the status of a single certificate. The responder replies with one of three statuses: good, revoked, or unknown.
The OCSP responder URL is specified in the certificate's Authority Information Access (AIA) extension. The client includes the certificate's serial number and the issuer's identifier in the request, and the responder returns a signed response that the client can verify. Because each query targets a single certificate, the response is small (typically a few hundred bytes) and fast to process.
OCSP offers several advantages over CRLs. Responses are real-time (or near real-time), the data transferred is minimal, and clients do not need to store or parse large files. However, OCSP introduces its own challenges. The client must make a network request to the OCSP responder for every certificate it validates, which adds latency to the TLS handshake. If the responder is slow or unreachable, clients face a difficult decision: fail open (accept the certificate without verification, which is insecure) or fail closed (reject the certificate, which causes an outage). Most browsers choose to fail open, which weakens the security guarantee.
OCSP also raises privacy concerns. Because the client sends the certificate's serial number to the responder, the CA operating the responder can observe which websites or services a user is connecting to. This is a significant issue for user privacy, and it was one of the motivations behind OCSP stapling.
OCSP stapling (formally known as the TLS Certificate Status Request extension, defined in RFC 6066) elegantly solves the latency and privacy problems of standard OCSP. Instead of the client querying the OCSP responder directly, the server fetches its own OCSP response in advance and "staples" it to the TLS handshake.
The web server periodically queries the OCSP responder for the status of its own certificate. The signed OCSP response is cached locally on the server. This happens in the background and does not affect user requests.
When a client connects, the server includes the cached OCSP response in the TLS handshake (specifically, in the CertificateStatus message). The client receives the certificate and its revocation status in a single round trip.
The client verifies that the stapled OCSP response is signed by the CA, is still within its validity window, and confirms the certificate's status as "good." Because the response is signed by the CA, the server cannot forge a favorable status.
OCSP stapling eliminates the extra network round trip to the responder, removes the privacy concern (the CA never sees the client's request), and reduces the load on OCSP infrastructure. It is supported by all modern web servers (Apache, Nginx, IIS, Caddy) and recommended as a best practice for TLS deployments. The enhanced variant, OCSP Must-Staple (indicated by a certificate extension), tells clients to require a stapled response and reject the certificate if one is not provided, closing the fail-open loophole.
Both mechanisms serve the same purpose, but they approach it differently. Here is a side-by-side comparison to help you understand when each is most appropriate.
CRL provides a complete list of all revoked certificates. OCSP provides the status of one certificate at a time. CRLs are batch-oriented; OCSP is request/response.
CRLs can be large (megabytes for busy CAs), imposing significant download overhead. OCSP responses are tiny (a few hundred bytes), making them far more efficient for individual checks.
CRLs are updated on a schedule (hours or days), creating a window where stale data may be served. OCSP can provide near real-time status, especially with short-lived response validity periods.
CRLs can be cached and served from CDNs, making them highly available. OCSP requires a live responder, which can become a single point of failure. OCSP stapling mitigates this by shifting the responsibility to the server.
CRLs preserve client privacy because the CA does not know which certificate the client is checking. Standard OCSP reveals this information to the responder. OCSP stapling restores privacy by removing the direct client-to-responder connection.
Most public CAs support both mechanisms. Browsers have largely moved toward proprietary solutions (like CRLSets in Chrome and CRLite in Firefox) that aggregate revocation data for performance. OCSP stapling remains the recommended approach for server operators.
Instant revocation workflows: Evertrust CLM lets you revoke any certificate in your inventory with a single action, automatically notifying the issuing CA and updating your internal records. When a key compromise is detected, every second counts.
CRL and OCSP management: Evertrust PKI operates as a full Certificate Authority with built-in CRL publishing and OCSP responder capabilities. CRLs are generated on schedule and OCSP responses are served with configurable freshness intervals, ensuring relying parties always have access to current revocation data.
Revocation monitoring: Evertrust continuously monitors the revocation status of all certificates in your inventory, alerting you if a certificate you depend on has been revoked by an external CA. This is critical for chain integrity.
Automated replacement after revocation: Revoking a certificate is only half the job. Evertrust automates the issuance and deployment of a replacement certificate immediately after revocation, preventing the outages that often follow manual revocation processes.
