Generate a new key pair, get a new certificate, deploy it everywhere the old one ran, then revoke the old certificate with the reason keyCompromise. Do not reuse the old key for the new certificate. Then find every other place that key was copied and check how it leaked.
Why this is different from a password leak
A TLS private key proves your server's identity. With it, an attacker who can intercept traffic can pose as your site, and a copy of the key may let them decrypt some recorded traffic depending on how the session was set up. The key itself cannot be changed, so replacement means a whole new key pair and certificate.
Steps in order
- Create a new key pair on a clean system. Never reuse the leaked key.
- Request a new certificate for the new key from your certificate authority.
- Deploy it to every server, load balancer, CDN and appliance that held the old one.
- Revoke the old certificate. Choose the reason keyCompromise when the key may have been accessed by an unauthorised person.
- Find the leak path and close it. Check repositories, images, backups, logs and shared drives.
- Review related certificates that reused the same key, since they are also exposed.
- Record the incident and the new expiry dates.
How revocation works in practice
Let's Encrypt's documentation says to revoke when you have reason to believe the private key was compromised, using the keyCompromise reason, and notes that its subscriber agreement requires revoking certificates tied to compromised keys. You can revoke through the ACME API with an ACME client. If you still control the issuing account you can revoke without the key. If not, you can revoke by proving possession of the private key. Revocations may be published in certificate revocation lists, and some browsers check those lists when deciding whether to trust a certificate.
Other certificate authorities have their own procedures, so check yours.
Reduce the chance next time
| Practice | Why |
|---|---|
| Keep keys out of repositories | The most common accidental leak path |
| Restrict file permissions on servers | Limits who can read the key |
| Use short certificate lifetimes with automation | Smaller window, practised renewal |
| Generate a fresh key on renewal | A leaked old key does not carry forward |
| Scan for private key files | Catches accidental commits |
See also detect private key hooks.
Quick check
Is revocation enough without replacing the key?
No. Revoking the certificate does not make the leaked key safe for another one. Always issue a new key pair.
Do all clients check revocation?
No. Revocation checking varies by client, so replacing the certificate quickly matters as much as revoking it.
Safeguard's free scan can check repositories for committed credentials, and its policy gates can block them in pull requests.
Sources
Last reviewed: 19 October 2026.
