Certificate revocation: when it is required and how

Revocation withdraws a certificate before its expiry date arrives. The authority that issued it publishes the withdrawal, and clients that check learn not to trust it any more. The qualification in that sentence is the whole subject: checking is neither universal nor guaranteed.

This page is for the operator deciding whether to revoke and how. If you are a visitor seeing a revoked-certificate error and want it to go away, that is a different situation: ERR_CERT_REVOKED is the site owner's to fix, with a new certificate.

When revocation is required

One case is not optional, and the rest are judgement.

Key compromise. If the private key has been exposed, or you have reason to believe it may have been, the certificate must be revoked. Anyone holding that key can impersonate your site with a valid certificate, and the only thing that withdraws it is revocation. This obligation is part of the rules authorities operate under, and reporting suspected compromise is expected rather than discretionary.

"May have been" covers more than people assume: a key committed to a repository, present in a backup that left your control, held on a server that was compromised, or handled by a contractor whose access ended badly. Certainty is not the threshold.

• Improper issuance

  A certificate obtained by someone without authority, or issued with incorrect details, is revoked by the authority once established.

• Decommissioning, sometimes

  A certificate for a service that no longer exists is worth revoking if the key's whereabouts are uncertain. If the key was destroyed with the system, letting it expire is reasonable.

When it is not required

Two situations prompt revocation requests that are not needed.

• Replacing a certificate normally

  Renewal issues a new certificate and the old one expires on schedule. Revoking it adds nothing unless its key is in question, and it introduces a window where an old certificate still in service somewhere starts failing.

• Changing hosting or providers

  The certificate remains valid and its key remains yours. Unless the key travelled somewhere you do not control, this is not a compromise.

How to request it

Through the authority that issued the certificate, using whatever channel it provides, and the request must be authenticated: an authority will not withdraw a certificate on an unverified request, since that would itself be an attack. Revoking a certificate and publishing its status is part of what a certificate authority does, alongside issuing it.

Have three things ready. The certificate in question, so the authority can identify it precisely. The reason, since reasons are recorded and some are handled with more urgency. And the replacement plan, because revocation takes effect for clients that check and your site needs a valid certificate either way.

Where issuance is automated, revocation usually is too, through the same interface that requested the certificate. Confirm that before you need it: discovering the route during an incident costs time you will not have.

The order that avoids an outage

Revocation and replacement are separate actions, and doing them in the wrong order takes the site down.

Obtain and install the replacement first, together with its certificate chain, verify it is being served, and revoke afterwards. The old certificate remains valid during the overlap, which is harmless in the ordinary case.

The exception is key compromise, where the overlap is what you are trying to end. There, revoke immediately and accept the disruption, because a valid certificate in an attacker's hands is worse than an interruption you control. Generate a new key and a new certificate signing request for the replacement, since reissuing on the compromised key restores the exposure while removing the symptom.

CRL and OCSP: how clients check revocation

A client can learn that a certificate was revoked in two standard ways, and both addresses are written into the certificate itself.

• Certificate revocation list (CRL). The authority publishes a signed list of the serial numbers it has revoked, with the date and reason for each, and replaces it on a schedule. The certificate's CRL Distribution Points extension says where the list is. CRLs are defined in RFC 5280.

• Online Certificate Status Protocol (OCSP). The client asks the authority's responder about one certificate and receives a signed answer: good, revoked or unknown. The responder's address is in the certificate's Authority Information Access extension. OCSP is defined in RFC 6960.

The balance between the two has shifted. Since 2024 the CA/Browser Forum rules require publicly trusted authorities to publish CRLs and make OCSP optional, and Let's Encrypt ended its OCSP service in 2025. Browsers mostly do not fetch either for each site; they download revocation data compiled from CRLs by their vendor, such as Chrome's CRLSets and Firefox's CRLite.

To see where a certificate publishes its status:

$ openssl x509 -in cert.pem -noout -ext crlDistributionPoints
$ openssl x509 -in cert.pem -noout -ocsp_uri

A downloaded CRL is read with openssl crl -in list.crl -inform DER -noout -text. More commands are on OpenSSL commands.

Why revocation works less well than it sounds

The mechanism exists and its reliability is limited, which changes what you should expect from it.

Clients learn about revocation by one of two routes. They ask the authority about a specific certificate at the moment they meet it, using the online certificate status protocol specified in RFC 6960, or they consult a certificate revocation list, the periodically published catalogue of withdrawn serial numbers defined in RFC 5280. Browsers have also supplemented both with lists compiled by their own vendors and shipped with the software. Consulting costs a round trip on every connection, so clients handle the trade differently, and some skip the check rather than delay the page when an answer is slow to arrive.

The consequence is that a revoked certificate may keep working for a share of visitors. Revocation is a real measure and not a switch that takes effect everywhere at once.

That limitation is also the reason certificate lifetimes have shortened over the years: bounded validity achieves by expiry what revocation is supposed to achieve by announcement, without requiring any client to check anything. There is one arrangement that removes the round trip rather than the check, in which the server obtains the signed status itself and hands it over during the handshake, a mechanism named OCSP stapling.

What to do besides revoking

Revocation addresses the certificate. A compromised key usually means something else went wrong, and treating the certificate as the whole incident leaves the cause in place.

• Establish how the key was exposed

  A key in a repository points at a process problem; a key from a compromised server points at that server. The replacement certificate is safe only if the new key does not travel the same route.

• Check what else used that key

  Keys are reused more often than people remember, across environments, across services, and sometimes across certificates. Every certificate on the exposed key needs the same treatment.

• Look at what the certificate could have been used for

  Someone able to present a valid certificate for your name could intercept traffic to it during the exposure window. Whether that matters depends on what moved over those connections.

• Write down the window

  When the key was exposed and when the replacement went live bounds every subsequent question, in the same way the window matters after a domain hijack.

None of this is certificate work, which is precisely why it gets skipped: the visible task ends when the new certificate is serving.

FAQ