Leaked TLS Private Key Response: Revoke, Reissue and Find Every Copy

When the private key behind a TLS certificate leaks, anyone holding it can impersonate your service to clients that trust that certificate, and once your CA learns of it the certificate will be revoked within 24 hours whether you are ready or not. Keys leak through public repositories, container images, support bundles, backups, compromised build servers and third-party platforms that held a copy. This playbook covers a single organisation's key compromise: confirming the exposure, finding every server, load balancer and CDN that uses the same key, reissuing with a new key, requesting revocation, and the evidence and notifications that follow. It is for incident responders, PKI owners and platform engineers. For a CA distrust or a mass replacement across many certificates, use the CA Compromise and Mass Certificate Replacement Playbook instead.

Key takeaways

• Replace before you revoke, but not by much. Deploy a certificate on a new key pair everywhere first, then request revocation; the CA/Browser Forum Baseline Requirements oblige the CA to revoke within 24 hours of evidence of key compromise, so the window to replace is short.
• The key, not the certificate, is what leaked. Every certificate issued for that public key, including renewals that reused it, is compromised; reissuing with the same CSR fixes nothing, and CAs must reject a key already reported as compromised.
• Key reuse decides the blast radius. The same key is often on origin servers, load balancers, CDNs, WAFs and staging; find every copy by public key fingerprint, not by hostname.
• Revocation is necessary but weak protection. Many clients do not enforce revocation checks reliably, so short certificate lifetimes and rapid replacement do more than the revocation itself.
• Ask whether past traffic is exposed. With forward secret (ECDHE) key exchange a stolen key does not decrypt recorded sessions; with legacy static RSA key exchange it can, which changes your notification analysis.

How the incident shows up

Attackers who obtain the key can run adversary-in-the-middle interception (T1557) wherever they can control the network path or DNS, and private key theft itself maps to Unsecured Credentials: Private Keys (T1552.004). See the Private Keys in Repositories Guide and the Certificate Transparency Monitoring Guide for Web Teams.

Triage questions

1. Is it really a live key? Compute the public key (SPKI) hash of the leaked key and compare it with the public keys of your certificates. A test or expired key changes the severity, not the need to remove it.
2. Which certificates use this key? Search your certificate inventory and CT logs for every certificate with the same public key. Renewals that reused the CSR share the key.
3. What names do they cover? A wildcard or a certificate with many subjectAltNames widens impersonation to every listed name.
4. Where is the key deployed? List servers, load balancers, ingress controllers, CDN and WAF configurations, API gateways, mail servers and appliances that hold it.
5. How was it exposed, and for how long? Public repository with commit history, a supplier breach, or a host compromise each imply different exposure and different evidence.
6. Is the CA already aware? If a third party filed a report, the CA must investigate within 24 hours and revoke within 24 hours of evidence of compromise.
7. What key exchange do clients use? If any client negotiated TLS 1.2 static RSA key exchange with this key, recorded traffic could be decrypted.
8. Who depends on pinning? Mobile apps or partners that pin the leaked public key will break when you rotate. See the Certificate Pinning Guide.

Containment priorities

Containment means making the leaked key worthless as fast as possible without taking the service down.

1. Remove the exposed copy: make the repository private or delete the file, pull the image or artefact, and ask the platform to purge caches. Treat this as limiting further spread only; assume the key has already been copied.
2. Generate a new key pair in a controlled place: ideally in an HSM, a cloud KMS or certificate manager that does not allow export, and never on the host that leaked the old one if that host is compromised. See the HSM Deployment and Operations Guide.
3. Issue replacement certificates: request new certificates from your CA for the same names on the new key, using ACME automation where available. Consider splitting a large multi-name or wildcard certificate into narrower certificates so one leak cannot impersonate everything.
4. Deploy everywhere the old key lived: origins, load balancers, CDN edge configurations, WAF and gateway certificate stores, and any backup or disaster recovery configuration. Verify from outside by checking the served certificate's public key.
5. Request revocation with reason keyCompromise: through the CA's portal or API, or with ACME by signing the revokeCert request with the compromised key itself (RFC 8555 allows certificate key authenticated revocation). Revoke every certificate that shares the key. The Baseline Requirements also oblige subscribers to request revocation promptly and stop using the key.
6. Tighten the network side: if impersonation is a live risk, review DNS change controls, registrar locks and CAA records so an attacker cannot easily redirect traffic to a server using the stolen key.

Decision guidance: if you can deploy a replacement within hours (automated issuance, central certificate management), revoke as soon as deployment is verified. If deployment will take longer and the key is in a public place, revoke anyway once your critical endpoints are replaced: a public key exposure will likely be reported to the CA by someone else, and you would rather control the timing. Small organisations with a single certificate on one load balancer can often complete the whole cycle in an hour; large estates should replace by priority (internet facing customer services first, then partner endpoints, then internal).

Eradication

• Close the leak path: remove the key from repository history (history rewrite is for hygiene; it does not undo exposure), fix the build that baked it into an image, and stop support processes that collect configuration with keys.
• Hunt for other copies: scan repositories, artefact stores, backup sets, configuration management and shared drives for the old key's fingerprint and for any other private keys. Leaks rarely come alone. See the Git Secret Scanning Guide.
• Remove the old key from every system: delete it from servers, keystores and secret stores, not just unbind it, and record where it was destroyed.
• Fix host compromise first: if the key came from a compromised server, rebuild that server before putting the new key on it; otherwise you hand over the new key too.
• Review supplier copies: where a CDN or WAF held the key, confirm the provider has removed old versions, and consider provider-managed keys or keyless options so you do not hand over private keys at all. See the CDN Security Guide.

Recovery

1. Confirm the served certificate everywhere: check each hostname and IP from several networks and regions so CDN edges with stale configuration are found.
2. Confirm revocation status: check the old certificates appear in the CA's CRL with reason keyCompromise and that OCSP responds revoked.
3. Update pins and trust lists: release app updates or partner configuration changes where the old public key was pinned; use backup pins next time.
4. Monitor for misuse: watch CT logs for unexpected issuance, DNS for unauthorised changes, and threat intelligence for your domain on phishing infrastructure using the old certificate.
5. Shorten lifetimes and automate: public TLS certificate validity is capped at 200 days from 15 March 2026, falling to 100 days from 15 March 2027 and 47 days from 15 March 2029. Automation built for that schedule also makes emergency replacement routine. See the Certificate Expiry Outages and 47-Day TLS Certificates Guide.

Evidence to preserve

• The exposure itself: repository URL, commit hashes, timestamps of first public visibility, image digests or archive locations, captured before deletion.
• Key and certificate identifiers: SPKI hash of the leaked key, serial numbers and CT log entries of every affected certificate, and the replacement certificates.
• Access logs: repository access and clone logs where the platform provides them, artefact download logs, and host logs from any compromised server.
• CA correspondence: revocation request time, reason code, CA confirmation and any Certificate Problem Report received.
• Timeline of replacement: when each endpoint switched to the new key, for the post-incident review and any regulator questions.

Handle the leaked key itself as sensitive evidence: store it encrypted with restricted access and record who handled it.

Notification triggers

A key leak with forward secret key exchange and no evidence of interception often does not meet a personal data breach threshold; record the reasoning either way.

Lessons from incidents

• Supplier copies are your keys too: in the Imperva breach 2019, a stolen AWS API key exposed customer-provided SSL certificates for a subset of Cloud WAF customers, who were told to generate and upload new certificates; about 13,500 certificates were rotated. Every platform you upload a key to is part of your blast radius.
• A leaked service-wide key forces a global rotation: in the GitHub RSA SSH host key exposure 2023, a host private key briefly published in a public repository had to be replaced for every client at once, and users had to verify the new fingerprint. TLS keys shared across many hostnames behave the same way.

Metrics: time from detection to replacement deployed on all endpoints; time from detection to revocation; number of endpoints sharing one key (target one key per service); percentage of public certificates issued through automation; percentage of private keys held in non-exportable storage.

Practitioner checklist

• Confirm the leaked key matches a live certificate by public key hash.
• List every certificate and every endpoint that uses the same key, including CDN, WAF and load balancer copies.
• Generate a new key in non-exportable storage on an uncompromised system.
• Deploy replacement certificates everywhere, verify from outside, then request revocation with reason keyCompromise.
• Preserve exposure evidence, certificate serials and CA correspondence before cleaning up.
• Check whether any client used static RSA key exchange, and assess notification on that basis.
• Update pinned keys and notify partners that rely on them.
• Remove the leak path and scan for other private keys.
• Reduce key reuse and move to automated, short-lived certificates.

Standards and references

• CA/Browser Forum: Baseline Requirements for the Issuance and Management of Publicly-Trusted TLS Server Certificates
• IETF: RFC 8555 Automatic Certificate Management Environment (ACME)
• MITRE ATT&CK: Unsecured Credentials: Private Keys
• MITRE ATT&CK: Adversary-in-the-Middle
• NIST: SP 800-53 Rev. 5
• NIST: Cybersecurity Framework 2.0

Related NHI Mgmt Group resources: CA Compromise and Mass Certificate Replacement Playbook · Certificate Revocation Guide · SSH Key Compromise Response Playbook · Machine Identity, PKI and Certificate Lifecycle Guide · Private Keys in Repositories Guide