Private Key Compromise: Incident Response Playbook

This is different from a lost key — losing a key means you no longer have it; a compromise means someone else might have a copy while you still do. That distinction changes the urgency entirely: a lost key is an inconvenience you fix on your own schedule, a compromised key means an attacker could be actively impersonating your server right now.

Immediate (within the hour)

1. Revoke the certificate. Do this before anything else, through your CA's portal or ACME client's revoke command — see our revocation guide for the exact commands. Every minute the old certificate remains valid is a minute an attacker with the key can use it.
2. Generate a completely new key pair. Never reuse the compromised key, even temporarily — a new CSR needs a new key, not just a new certificate. See our CSR generation guide if you need the exact commands.
3. Issue and install the replacement certificate using the new key, on every server that was using the old one.

Short-term (within 24 hours)

1. Identify how the key was exposed. Common causes: a key file accidentally committed to a public code repository, an overly permissive file permission on a shared server, a compromised backup, or a breached CI/CD pipeline with the key stored as a secret. You cannot close the actual hole until you know what it was.
2. Check whether the key was used maliciously before you caught it. Certificate Transparency logs (searchable via our CT Log Search tool) show every certificate issued for your domain — if an attacker used the compromised key to get a different CA to issue them a certificate, it would appear there. Also check your own server logs for connections you can't account for.
3. Rotate anything else that shared the exposure path. If the key leaked via a compromised CI/CD secret store or a breached backup, other secrets in that same location (API keys, database credentials) are under the same suspicion and need their own rotation — a private key rarely leaks in complete isolation from everything else stored alongside it.

Follow-up (within the week)

1. Set up monitoring so this is caught faster next time. Our certificate monitoring guide covers alerting on unexpected certificate issuance for your domain — the earlier a compromise or mis-issuance is caught, the smaller the exposure window.
2. Review file permissions and secret storage practices for private keys specifically — who has read access, whether keys are ever logged or included in backups without encryption, and whether your deployment process ever transmits a private key somewhere it shouldn't (email, chat, an unencrypted config file in version control).
3. Document what happened while it's fresh — a short internal record of the exposure cause, the timeline, and what changed afterward is genuinely useful the next time (there's often a next time, at a different company or a different key) you need to move quickly under similar pressure.

What not to do

• Don't wait to "confirm" the compromise is real before revoking. Revocation is reversible in the sense that you can always issue a new certificate; the exposure window from a genuinely compromised key is not reversible. When in doubt, revoke.
• Don't reuse the old key "just this once" to save time. A key you know or suspect is compromised should never be used again, for any certificate, on any server.
• Don't skip the "how did this happen" step. Revoking and reissuing fixes the immediate exposure but does nothing to prevent the same leak path from happening again next month.