A leaked private key turns your SSL certificate into a tool anyone can use to impersonate your site, so certificate revocation has to happen within hours, not at the next maintenance window. This article explains why revoking a certificate after a private key leak cannot wait, what revocation actually achieves, how to run the response step by step, and where the usual advice stops working.
The reader here is usually a sysadmin or DevOps engineer who has just found a .key file somewhere it shouldn’t be. You’ll leave with a clear sequence of actions and a realistic picture of how much protection revocation gives you.
What an Attacker Can Do With Your Private Key
A certificate is public. The private key is the only thing that proves a server is really yours. Anyone who holds that key and can intercept traffic – on a compromised Wi-Fi network, through DNS hijacking, or via a BGP route leak – can present your valid certificate and complete a TLS handshake that every browser accepts.
No warning appears and the padlock looks normal. HTTPS still “works” from the user’s side, which makes this worse than an expired certificate, because nobody notices anything is wrong.
If the server still allows RSA key exchange without forward secrecy, the risk extends to the past. Recorded traffic encrypted under the leaked key can be decrypted after the fact. TLS 1.3 and ECDHE cipher suites protect earlier sessions, but they do nothing against impersonation going forward.
A Familiar Leak Scenario
A typical case: a developer builds a Docker image for a staging environment and copies the whole nginx config directory into it, including privkey.pem for the production wildcard certificate. The image gets pushed to a public Docker Hub repository on a Friday afternoon. GitHub secret scanning or a tool like TruffleHog flags a similar commit on Monday.
By then the key has been public for 60+ hours. Automated scrapers watch public repositories and registries continuously, and exposed credentials are often picked up within minutes. The only safe assumption is that the key is in someone else’s hands.
The wildcard detail matters. One *.example.com key now puts every subdomain at risk – the API, the customer portal, the admin panel.
Myth: Reissuing the Certificate Kills the Old One
This is the most common misunderstanding in incident response. Installing a new certificate on your servers does nothing to the old one. The leaked certificate stays cryptographically valid until its notAfter date, whether that’s 30 days or 11 months away.
Rekeying protects your servers. Revocation is what tells clients to stop trusting the old certificate wherever an attacker might present it. You need both.
A second myth sounds smarter: “Revocation is pointless because browsers don’t check it.” That was roughly true in the OCSP soft-fail era, but it no longer holds. Chrome’s CRLSets give priority to revocations with the keyCompromise reason code, and Firefox’s CRLite ships compressed revocation data for all publicly trusted certificates. Revocation propagates imperfectly, but it does propagate. Our comparison of CRLs and OCSP covers the mechanics. One recent change: Let’s Encrypt shut down its OCSP responders in 2025 and now relies entirely on CRLs.
Responding to a Leaked Private Key: Step by Step
An experienced incident responder works in this order, and aims to finish within 24 hours of discovery:
1. Contain the leak. Delete the public repository, image, or paste, and rotate any other secrets that were exposed with it. Assume the key has already been copied anyway.
2. Generate a completely new key pair. Don’t reuse the old CSR. Run openssl genpkey or your HSM workflow again and create a fresh CSR.
3. Issue and deploy the replacement. Push it to every endpoint that used the old certificate, including load balancers, CDNs, and API gateways. Then check each one with openssl s_client -connect host:443 -servername host to confirm the new serial number is being served.
4. Revoke with the correct reason code. Use keyCompromise (reason code 1). With certbot that is certbot revoke –cert-path /etc/letsencrypt/live/example.com/cert.pem –reason keycompromise. Commercial CAs such as DigiCert and Sectigo offer this in their portals and APIs.
5. Verify and document. Check that the serial number appears on the CA’s CRL, search crt.sh for any unexpected certificates issued for your domains, and record the timeline for your post-incident review.
Deploying before revoking is a deliberate choice. If you revoke first, browsers that pick up the revocation will block your own site until the new certificate is live. The exception is evidence of active exploitation, such as a phishing site already serving your certificate. In that case, revoke immediately and accept a short outage.
The CA/Browser Forum Baseline Requirements oblige public CAs to revoke within 24 hours once key compromise is shown. That means the CA can revoke without you. Anyone holding the key can request revocation, and through ACME the key itself can sign the request. If a researcher reports your key to the CA before you act, your certificate may be revoked while your servers are still using it.
Common Mistakes During Key Compromise Response
Revoking with the wrong reason code. Teams choose “superseded” or leave the reason unspecified because it sounds less alarming. That can lower the revocation’s priority in browser revocation sets. Let’s Encrypt also blocks future issuance for keys revoked as keyCompromise, which stops someone from accidentally reusing the leaked key later.
Missing every place the key was deployed. The same key often sits on six load balancers, a CDN edge configuration, and a forgotten mail server. If one of those keeps serving the revoked certificate, it breaks right after revocation. Teams without a certificate inventory find out from customer complaints.
Treating private-CA leaks as low priority. Internal PKI clients such as Java services, IoT devices, and older .NET apps often don’t check CRLs at all. For these, revocation alone protects nothing. You have to rotate the key and, if the issuing CA’s own key was exposed, replace trust anchors on every client.
Edge Cases Where Standard Advice Falls Short
Mobile apps that pin the leaf key will stop working once you rotate it, unless a backup pin was shipped beforehand. Pin the intermediate CA or a backup key, never only the leaf key. Keys stored in an HSM or cloud KMS such as AWS KMS or Azure Key Vault rarely leak as files. More often the access credentials leak, so the response starts with IAM rotation and audit logs.
Shorter certificate lifetimes help. The CA/B Forum schedule caps validity at 200 days from March 2026, 100 days from 2027, and 47 days from March 2029. A leaked key for a 47-day certificate has a limited window, but 47 days is still plenty of time for an attacker. Short lifetimes reduce the damage from a leak. They don’t replace revocation. The guide to private key protection covers how to keep leaks from happening in the first place.
FAQ
How fast must a CA revoke a compromised certificate?
Under the CA/Browser Forum Baseline Requirements, a publicly trusted CA must revoke within 24 hours after key compromise is reported and verified.
Can I keep using the same private key with a new certificate?
No. A new certificate on the old key is just as compromised as the original. Always generate a new key pair and CSR.
Does revocation work if my users’ browsers don’t check OCSP?
Partially. Chrome’s CRLSets and Firefox’s CRLite cover keyCompromise revocations without live OCSP lookups. Older clients and many non-browser TLS libraries may still accept the revoked certificate until it expires.
Final Practical Tip
Practice key-compromise response before you need it. Run a tabletop exercise once a year. Pick one certificate, time how long it takes to find every deployment, rekey, revoke, and confirm the new serial on each endpoint. Teams that have practiced finish in under 2 hours, while teams doing it for the first time often take 2-3 days. For broader playbooks, see these revocation detection and response strategies.