A TLS certificate can still be inside its validity period when you need clients to stop trusting it. The private key may have been exposed, an identity may no longer be valid, or an issuing system may have made a serious mistake. Waiting for the certificate to expire leaves a gap between “we know this credential should no longer be trusted” and “clients stop accepting it.”
Certificate revocation is the mechanism for communicating that change before normal expiry. The difficult part is operational: revocation information has to reach the relying parties that make trust decisions, and their behaviour when that information is stale or unavailable may differ.
This article explains the mental model behind certificate revocation, how certificate revocation lists (CRLs) and the Online Certificate Status Protocol (OCSP) carry status, what revocation does not guarantee, and how to design a response that you can actually execute after a key compromise.
A certificate has two different clocks
A certificate contains a validity interval. In simplified form, a relying party asks:
Is the current time between notBefore and notAfter?That check answers whether the certificate is within its planned lifetime. It does not answer whether something happened after issuance that invalidated the original trust decision.
Suppose a certificate is valid for another 30 days, but its private key is copied from a compromised server today. The certificate’s expiry date has not changed. The security assumption has: possession of the private key is no longer evidence that the legitimate server is the only party able to use it.
Revocation adds a second question:
certificate is within validity period
|
v
has the issuer marked it as revoked?This distinction is the core mental model. Expiry is scheduled invalidation. Revocation is early invalidation in response to a changed trust condition.
The control is intended to reduce the period during which relying parties continue accepting a certificate that the issuer has decided should no longer be trusted. It does not erase a stolen private key, repair compromised hosts, or guarantee that every client will learn the new status immediately.
Revocation only helps when relying parties learn about it
Revoking a certificate is not the same as remotely deleting it from every client. A certificate is a signed object that may already exist in caches, configuration, logs, or network captures. Its signature remains mathematically valid after revocation.
What changes is the issuer’s status information.
A relying party can combine several facts when deciding whether to accept a certificate:
valid signature and chain
+
correct identity
+
current validity period
+
acceptable revocation status
=
trust decision under local policyThe last line matters. The relying party must obtain or already possess sufficiently fresh revocation information and apply an appropriate policy to it. If a client never checks status, or accepts a certificate when status cannot be determined, publishing revocation information alone cannot force that client to reject the certificate.
That is why certificate revocation is a distributed security control. The issuer publishes status, but relying parties enforce it.
CRLs publish a signed set of revoked certificates
A certificate revocation list, or CRL, is a signed, time-stamped list issued by a certificate authority or authorized CRL issuer. Revoked certificates are identified by information including their serial numbers.
A simplified flow looks like this:
certificate authority
|
| signs and publishes
v
current CRL
- serial 1021 revoked
- serial 1088 revoked
|
v
relying party checks certificate serialBecause the CRL is signed, it can be distributed through infrastructure that does not itself need to be trusted for integrity. The relying party still has to validate that the CRL is appropriately signed and applicable to the certificate being checked.
CRLs also introduce a freshness question. They are issued periodically. If a relying party holds an older CRL, it may not yet contain a newly revoked certificate. The interval between updates therefore contributes to how quickly revocation can become visible through that mechanism.
This is not a reason to invent an arbitrary “safe” CRL interval. The right publication and retrieval strategy depends on how quickly your environment needs revocation to propagate, how large the lists become, how clients cache them, and what availability you can provide.
OCSP asks for status of a particular certificate
The Online Certificate Status Protocol, or OCSP, lets a client request status information for an identified certificate instead of obtaining an entire revocation list.
Conceptually:
client -> OCSP responder: status of certificate X?
responder -> client: good | revoked | unknownA revoked response tells the client that the certificate should be rejected. An unknown response is different: the responder cannot determine the requested certificate’s status. Treating those states as interchangeable can create incorrect trust decisions.
OCSP responses carry timing information so clients can reason about freshness. The exact validation rules belong in the TLS or PKI implementation you use; application code should not improvise its own partial OCSP parser or trust logic.
OCSP can provide more timely status information than waiting for the next periodic CRL publication. It also introduces an online dependency unless the surrounding protocol or platform provides another way to deliver suitable status information. Availability therefore becomes part of the design.
Decide what happens when status cannot be checked
A common revocation design problem appears when the status source is unreachable:
certificate looks valid
|
revocation status unavailable
|
+--> reject connection
|
+--> continue connectionRejecting the connection reduces the chance of accepting a certificate whose revocation status cannot be established, but it can turn a revocation-service outage into an application outage. Continuing preserves availability, but it reduces the protection revocation checking provides during that period.
There is no portable rule that makes this trade-off disappear. The appropriate policy depends on the system’s threat model, the sensitivity of the connection, the platform’s certificate-validation behaviour, and whether the application controls both ends of the connection.
For a tightly controlled high-value internal protocol, inability to establish current certificate status may justify refusing the connection. For a general-purpose client that must operate across unreliable networks, a strict online dependency may create unacceptable availability failures. Some platforms and protocols have their own revocation behaviour, so application developers should understand and test that behaviour rather than assume it.
The key design decision is explicitness: know whether unavailable status means rejection, acceptance under reduced assurance, or use of another trusted source. Do not discover the answer for the first time during an incident.
Treat revocation as one step in key-compromise response
Imagine that monitoring shows a production TLS private key may have been exposed. Revoking its certificate is necessary if the certificate should no longer be trusted, but revocation by itself does not restore the service.
A practical response has several connected actions:
- Stop further exposure and investigate the system that held the key.
- Generate replacement key material in an environment you currently trust.
- Obtain and deploy a replacement certificate through the normal validated issuance process.
- Request revocation of the affected certificate through the issuer’s authenticated process.
- Verify that the issuer’s revocation information reflects the change.
- Test representative relying parties to confirm that the old certificate is rejected under the policies you depend on.
- Remove the compromised key and certificate from active systems, backups or artifacts where continued presence creates avoidable risk, while preserving evidence needed for the incident investigation.
The ordering may need adjustment to preserve service availability. For example, you may deploy the replacement certificate before revoking the old one so healthy clients have a working endpoint when revocation propagates. If active misuse creates greater risk than an outage, faster invalidation may take priority.
The important point is that replacement and revocation solve different problems. Replacement gives legitimate systems new credentials. Revocation communicates that the old certificate should no longer be accepted.
Know which certificate you are revoking
Certificate hierarchies create another boundary condition. An end-entity certificate and a certificate authority certificate do not have the same blast radius.
If one server’s private key is compromised, the response normally concerns that server certificate and key. If a CA signing key is compromised, certificates issued under that authority may be affected much more broadly. Recovery can require replacing trust relationships and invalidating many dependent certificates.
This is one reason private signing keys deserve stronger isolation and operational controls than ordinary leaf certificates. Revocation can communicate a loss of trust, but it cannot make recovery from a compromised issuing authority cheap.
Do not respond to uncertainty by revoking unrelated certificates “just in case.” Identify the key that was exposed, the certificates bound to it, the systems that trust those certificates, and the authority level of the affected credential. The response should match the actual trust boundary.
Avoid building a plan around revocation alone
Several mistakes make certificate revocation look stronger than it is.
The first is assuming that a successful revocation request means every client immediately rejects the certificate. Publication, caching, client support, freshness rules, and local policy all affect enforcement.
The second is waiting until compromise to learn the issuer’s revocation procedure. If emergency revocation requires an account, approval path, hardware credential, or separate administrative role that nobody can access during an incident, the theoretical control is not operationally useful.
The third is revoking before a replacement path exists when availability matters. A correct security action can still create an avoidable outage if credential replacement was never rehearsed.
The fourth is testing only issuance and renewal. A certificate lifecycle is incomplete if you know how to create certificates but have never verified how to invalidate one early.
Test the lifecycle before you need it
A useful revocation exercise does not require sacrificing a production certificate. Use a non-production certificate issued through the same operational process where possible, then walk through the lifecycle:
issue -> deploy -> verify -> revoke -> observe rejection -> replaceConfirm who can request revocation, what authentication and approvals are required, how quickly status becomes visible through the mechanisms your environment uses, and how representative clients behave when status is revoked, stale, unknown, or unavailable.
Also record which component owns each decision. Certificate issuance may belong to one team, load balancer configuration to another, client trust policy to a third, and incident response to a fourth. Revocation crosses those boundaries, so an undocumented ownership gap can become the slowest part of recovery.
The exercise should leave you with a small, usable runbook rather than a protocol encyclopedia: affected certificate identifiers, issuer revocation procedure, replacement path, responsible roles, verification steps, and escalation contacts.
Build for the day trust changes early
Certificates are often treated as objects that become invalid only when their expiry date arrives. Real systems need another path because trust can change before that date.
Design that path while the system is healthy. Know how your issuer communicates revocation, understand how your relying parties consume that information, choose an availability policy that matches the threat model, and rehearse replacement as well as revocation.
Then, if a private key is compromised, the response is not “click revoke and hope clients notice.” It is a controlled transition from a credential you no longer trust to one you do, with evidence that the relying parties making the final decision have moved with you.