Certificate revocation invalidates a certificate before its natural expiry date — a step that's easy to forget exists, since most certificates are simply left to expire naturally, but genuinely necessary in specific situations where waiting for natural expiry isn't acceptable.
When revocation is actually necessary
- The private key has been exposed or potentially compromised — committed to a public repository, found on a decommissioned server without secure wiping, or any scenario where someone other than you might now hold a copy.
- The certificate was issued in error (wrong domain, wrong organization details) and needs to be invalidated rather than just left unused.
- A domain has changed ownership, and the previous owner's certificate for it should no longer be considered valid, even if it hasn't expired.
- An employee or contractor who had access to a private key (in an mTLS or internal certificate context) has left, and their client certificate should no longer authenticate successfully.
How revocation actually happens
You request revocation through your CA — most CAs offer a revocation option in their customer portal, or via the ACME protocol's revocation endpoint for Let's Encrypt and similar automated CAs. The CA then adds the certificate's serial number to its CRL and updates its OCSP responder to report it as revoked, which is what allows browsers and other clients checking revocation status to discover it's no longer valid.
Revoking a Let's Encrypt certificate with Certbot
certbot revoke --cert-path /etc/letsencrypt/live/yourdomain.com/cert.pemWhy revocation alone isn't instant or fully reliable
As covered in our OCSP vs CRL guide, revocation checking has real practical gaps — not every client checks revocation status promptly, and some browsers historically soft-fail (allow the connection) if a revocation check itself fails or times out, rather than blocking outright. This is exactly why, for a genuine private key compromise, revocation should be paired with immediately reissuing a new certificate with a fresh key pair — don't treat revocation alone as having fully closed the exposure, since not every client checking your old certificate will necessarily catch the revocation in a timely way.
After revoking: reissue immediately
Revocation without reissuing a working replacement leaves your domain without a valid certificate at all — the two steps go together for anything beyond an unused, decommissioned domain. Generate a new key pair, submit a fresh CSR, and get the new certificate installed before considering the incident fully resolved, rather than treating revocation itself as the finish line.
Documenting the incident
For anything beyond a routine, low-stakes revocation (an unused test certificate, for instance), keep a record of what was revoked, why, and when — the reissued certificate's serial number will differ from the revoked one, and having a clear record avoids confusion later if the old certificate's revocation status needs to be referenced (during a security review, for example, or if the same key material is ever encountered again unexpectedly).
What information a CA typically requires to process a revocation request
Most CAs require the certificate's serial number or the original order/certificate ID, along with a stated reason (key compromise, superseded, no longer needed, and similar standard categories) — having this information ready before starting the revocation process, typically available in your CA account dashboard, speeds up the request.
How revocation reason codes affect how the revocation is communicated to clients
The specific reason code submitted with a revocation (keyCompromise carries different urgency than superseded, for instance) can affect how quickly and prominently the revocation propagates through CRLs and OCSP responses — selecting the accurate reason, particularly for a genuine key compromise, ensures appropriately urgent handling.
Why documenting the specific reason for revocation matters for future reference
Keeping an internal record of why a certificate was revoked and when, beyond just the reason code submitted to the CA, provides valuable context if the same domain or infrastructure is ever audited or reviewed later, especially for a security-relevant revocation like a suspected key compromise.
What the practical timeline looks like from revocation request to full propagation
A revocation request typically takes effect at the CA within minutes, but full propagation to every client checking via CRL or cached OCSP responses can take longer, up to the cache duration those mechanisms use — meaning a revoked certificate may still be briefly accepted by some clients immediately after revocation, reinforcing why reissuance with a new key should happen immediately alongside revocation, not instead of it.
How to handle revocation for a certificate covering multiple domains or subdomains
Revoking a multi-domain or wildcard certificate invalidates it for every hostname it covered simultaneously, not just one — meaning a compromise affecting only one covered domain still requires revoking and reissuing coverage for every other domain the certificate included, since they all shared the same now-compromised private key.
Why revoking proactively, even without confirmed compromise, is sometimes the right call
When compromise is suspected but not fully confirmed, for instance a key that was briefly exposed in a way that might have been observed, revoking proactively rather than waiting for definitive proof of exploitation is generally the safer choice, given how low the cost of reissuance is compared to the potential cost of a confirmed compromise going unaddressed.
What CAA DNS records add as a preventive measure against future unauthorized issuance
A CAA (Certification Authority Authorization) DNS record explicitly specifies which CAs are permitted to issue certificates for your domain — any compliant CA will refuse to issue for your domain if a CAA record doesn't authorize them, adding a meaningful preventive layer against unauthorized issuance beyond just monitoring Certificate Transparency logs after the fact.
How to communicate a revocation internally if it affects a team beyond just yourself
For any revocation affecting shared infrastructure, notifying whoever else might be monitoring, deploying to, or relying on that certificate before executing the revocation avoids confusion when a team member suddenly sees certificate errors they weren't expecting or briefed on.
Why practicing the revocation process once, even without an actual incident, builds useful familiarity
Walking through the revocation process once in a low-stakes, non-urgent situation, revoking and reissuing a test certificate, for instance, builds familiarity with your specific CA's exact revocation interface and process, meaning you're not learning the mechanics for the first time during an actual, higher-pressure security incident.
What a quick closing checklist for certificate revocation looks like
Before considering a revocation properly handled, confirm: a replacement certificate with a fresh key pair is issued and installed immediately, the revocation reason is accurately recorded, and anyone relying on the affected infrastructure has been informed if the revocation affects shared systems.
Why understanding revocation well before you need it reduces panic during an actual incident
A genuine key compromise is stressful enough without also needing to learn your CA's revocation process for the first time under pressure — understanding the mechanics in advance, ideally through the kind of low-stakes practice run covered earlier in this guide, means you can execute quickly and correctly when it actually matters.
What a complete incident response sequence looks like from suspected compromise to resolution
A complete sequence: confirm the compromise indicator, revoke the affected certificate immediately with an accurate reason code, generate a fresh key pair and issue a replacement certificate, deploy the replacement across every affected server, and document the incident timeline and resolution for future reference.
How automated certificate management changes the calculus around revocation urgency
With certificates renewing automatically every 90 days through ACME automation, the practical exposure window from a delayed revocation is inherently much shorter than it was in the era of multi-year manually-managed certificates — though immediate revocation upon confirmed compromise remains the correct response regardless of how short the certificate's remaining validity happens to be.