I deleted the commit with the key a minute later. Do I still need to replace the certificate?

Yes. Bots scan public repositories for keys continuously, and deleting a commit doesn't remove copies that were already made. Treat the key as compromised, replace the certificate with a new key, and revoke the old one.

Will revoking the old certificate take my site down?

Only if the old certificate is still installed somewhere. Install the new certificate everywhere first, then revoke the old one. Do both the same day, because a CA that learns of the compromise must revoke within 24 hours anyway.

Can I reuse the leaked key for the new certificate?

No. A new certificate with the same key is just as compromised. Generate a new key and CSR. Let's Encrypt also refuses keys that were revoked for key compromise.

Private Key Leaked? What to Do in the Next Few Hours

Your certificate's private key ended up somewhere it shouldn't: pushed to a public GitHub repository, pasted in a ticket, left in a shared folder or a container image. Treat it as copied, even if you deleted it a minute later. Bots scan public repositories for keys all the time, and deleting a commit doesn't delete the clones.

What someone can do with your key

With the private key, anyone can pose as your site to people whose traffic they can intercept, such as on public Wi-Fi or a compromised network. The certificate stays usable for them until it expires or is revoked.

They can't decrypt traffic they recorded earlier if your server uses forward secrecy, which TLS 1.3 always does and TLS 1.2 does with ECDHE cipher suites. Old RSA key exchange has no forward secrecy, so that traffic is at risk too.

What to do, in order

1. Generate a new private key

Never reuse the leaked key, not even for the replacement certificate. Make a new key and a new certificate signing request (CSR) on the server, or wherever your keys normally live.

2. Get a new certificate for the same names

With Let's Encrypt or another ACME CA, request a new certificate with the new key; it takes minutes. With a paid CA, use its reissue option with the new CSR.

3. Install it everywhere the old one runs

Every server, load balancer, CDN and appliance that used the old key needs the new certificate and key. If the same key was used for more than one certificate, for example a wildcard and a few single names, all of them are compromised and all of them need replacing.

4. Revoke the old certificate

Revoke it with the reason keyCompromise. With certbot:

certbot revoke --cert-path /etc/letsencrypt/live/example.com/cert.pem --reason keycompromise

Let's Encrypt also blocks a key revoked for key compromise from being used in new certificates. With a paid CA, revoke from its dashboard or ask its support.

Install first, then revoke, but do both today. Under the CA/Browser Forum Baseline Requirements (section 4.9.1.1), a CA that gets evidence your key is compromised must revoke the certificate within 24 hours. If someone reports the leak to your CA before you act, the old certificate can be revoked while it's still installed, and your site goes down.

5. Clean up the leak

Remove the key from the repository and its history, and rotate any other secrets that leaked with it. This stops the next person from finding it; it doesn't undo the leak, which is why steps 1 to 4 come first.

Check the result

Scan the domain and confirm it serves the new certificate, with the full chain, from every address. Scan your domain free. If several servers sit behind a load balancer, check each one directly: one server still on the old certificate is enough for some visitors to get it.

Keep it from happening again

Keep private keys out of repositories altogether: add key files to .gitignore, turn on secret scanning, and load keys from a secrets manager at deploy time. And keep a list of where each certificate is installed, because step 3 is only fast if you already know the answer.