A lost private key can't be recovered or regenerated — the certificate that used it is now effectively unusable, and there's no support ticket or recovery process that gets it back, since the CA never had a copy of it in the first place.
What to actually do
- Generate a new key pair and a fresh CSR — the same process as an original certificate request.
- Submit the new CSR to your CA. If your existing certificate is still within its validity period, most CAs will reissue at no extra cost using the new CSR under your existing order.
- If the key loss might have involved exposure (rather than simply misplacing a backup with no risk of anyone else having accessed it), also revoke the old certificate with your CA, since a certificate whose key might be compromised shouldn't remain valid and usable by anyone who obtained it.
- Install the newly issued certificate and confirm it's being served correctly before considering the incident resolved.
Preventing a repeat
Store private keys in a proper secrets manager, or ensure your server backup process includes them in a way that's actually recoverable — a private key that only ever existed on the one server that generated it, with no backup at all, is a single point of failure worth avoiding for any domain that matters.
What to do immediately upon realizing a private key is lost or potentially compromised
Immediately requesting revocation of the certificate associated with the lost key, then generating an entirely new key pair and CSR for reissuance, is the correct sequence — there is no way to recover or regenerate a lost private key itself, since it was never stored anywhere recoverable by design.
How to prevent this situation through better key backup practices going forward
Storing private keys in a properly secured secrets manager or encrypted backup system, rather than only on the single server where they're used, provides a recovery path if that server is ever lost or corrupted — though even with backups, a suspected compromise still warrants revocation and reissuance rather than simply restoring the old key.
What evidence to gather if you suspect a key was stolen rather than simply misplaced
If theft rather than simple loss is suspected, preserving any available logs, access records, or other evidence before taking remediation action can be valuable for a subsequent security investigation, even though the immediate remediation steps (revoke and reissue) remain the same regardless of the specific cause.
How to update every system referencing the old certificate after reissuance
Maintaining a list of every system, application, or integration referencing a certificate, whether through direct file installation or a pinned key, ensures you can systematically update each one after reissuance rather than discovering forgotten references only when they unexpectedly break.
Why this scenario specifically underscores the value of automated, short-lived certificates
A private key compromise on a certificate with a 90-day lifespan carries meaningfully less residual risk after remediation than the same compromise on a certificate that would otherwise have remained valid for years — one more concrete argument for automated, short-lived certificates as a general practice beyond just convenience.
What to do if you're unsure whether a key was actually compromised or simply misplaced
When genuinely uncertain whether a key was compromised or just misplaced without exposure, treating the situation as a potential compromise and proceeding with revocation and reissuance is the safer default, given how low the cost of reissuance is compared to the potential cost of an actual undetected compromise.
How to establish a clear internal policy for this scenario before it ever happens
A brief, documented policy stating that any suspected key exposure triggers immediate revocation and reissuance by default, without requiring definitive proof of exploitation first, removes ambiguity and hesitation during an actual incident, when quick, confident action matters most.
A closing note on treating this scenario as a when, not an if, for any long-running infrastructure
Given enough time managing enough infrastructure, encountering a lost or potentially compromised key eventually becomes a matter of when rather than if — having the response process covered in this guide already understood, rather than researched for the first time under pressure, makes a real difference when it happens.
A final thought on prevention over remediation
Reviewing and periodically testing your organization's key security practices, secure storage, limited access, backup procedures, before an incident occurs is considerably more valuable than only reviewing them after a loss has already happened.