DisasterLab
PlaybooksTLS certificate expired
Infrastructuredisruptive20 minutes to prepare

TLS certificate expired

Browsers or API clients reject your site because its HTTPS certificate is expired, invalid, or issued for the wrong name.

01DetectConfirm the signal
02ContainStop more damage
03RecoverRestore control
04VerifyProve it works

What do you need right now?

Prepare before it happensRecover from this now

Your preparation

0 of 0 safeguards ready
0%
Continue the prevention checklist
Incident worksheet

Make the next decision with evidence

Restore a valid certificate and complete chain on every endpoint, then repair the ownership or automation failure that allowed expiry.

EvidenceDecisionActionProof

Capture before evidence disappears

  • Capture hostname, endpoint, served certificate, chain, issuer, serial, expiry, SNI behavior, DNS validation records, and renewal logs.
  • Inventory CDN, load balancer, origin, API, webhook, mail, internal service, and alternate-region certificate locations.
  • Record renewal account, order, challenge, rate-limit, permission, and deployment errors.

Decisions that change the response

QuestionAct whenAction
Renew or replace?The existing account and private key remain trustworthy and renewal is supported.Renew; otherwise issue a new key and certificate through the approved issuer.
Bypass validation?Never for production clients.Do not tell customers to ignore warnings. Use a separate trusted status channel while fixing issuance.

Proof that recovery worked

  • External clients receive the correct hostname, validity, key, and full chain from every edge and region.
  • APIs, webhooks, mobile clients, and strict trust stores complete real handshakes.
  • A forced renewal test reaches deployment and monitoring before the new expiry window.

Controls to put in place

  • Automate issuance and deployment with renewal tests well before expiry.
  • Monitor certificates externally by hostname and endpoint, not only certificate files.
  • Keep issuer account, DNS challenge, emergency issuance, and ownership details outside the failed system.
Tabletop drill

Use a short-lived staging certificate, break its renewal permission, detect the failure, repair issuance, deploy the full chain, and test strict clients.

Escalate when

Contact the issuer, DNS provider, or edge provider when rate limits, validation, account ownership, or managed-certificate deployment blocks recovery.

What this means

The site may still run, but customers cannot establish a trusted connection. The failure can come from missed renewal, broken domain validation, the wrong certificate at a proxy, an incomplete certificate chain, or an expired origin certificate behind a CDN.

Do not tell customers to bypass the browser warning. Restore a valid certificate and verify the full path.

Warning signs

  • Monitoring reports certificate expiry or a browser trust error.
  • HTTPS works on one hostname but not another.
  • Renewal logs show a failed DNS or HTTP validation.
  • A recent DNS, CDN, proxy, or hosting change altered certificate handling.
  • The certificate shown publicly differs from the one you renewed.

Recover now

First 15 minutes

  1. Read the exact certificate error. Record the hostname, issuer, expiry, subject names, and certificate served publicly.
  2. Find where TLS terminates. Check CDN, load balancer, hosting platform, reverse proxy, and origin.
  3. Renew or reissue through the normal provider. Fix DNS or HTTP validation first if automation failed.
  4. Install the full certificate chain and correct private key. Avoid copying keys through chat or email.
  5. Reload the TLS service safely. Keep the previous configuration available for rollback.

Today

  1. Test the apex domain, www, API, webhooks, mail-related hosts, and any customer domains.
  2. Verify from another network and with an independent TLS checker.
  3. Inspect renewal logs and scheduled jobs to find why automation failed.
  4. Confirm the certificate at the CDN and origin when both terminate TLS.
  5. If the private key was exposed, issue a new key and revoke the affected certificate.

Verify recovery

  • Browsers and API clients connect without warnings.
  • The certificate covers every intended hostname.
  • The public certificate has the expected issuer, chain, key, and expiry.
  • Automatic renewal completes in a dry run or provider test.
  • Expiry monitoring reaches more than one person.
  • No instructions remain telling users to bypass TLS errors.

Prepare now

Automation

  • Certificate issuance and renewal are automated.
  • Renewal does not depend on one laptop or person.
  • DNS and HTTP validation permissions are least-privilege and documented.
  • Renewal failure alerts arrive at least 30, 14, and 7 days before expiry.

Inventory

  • Every public hostname and TLS termination point has an owner.
  • CDN, load balancer, proxy, and origin certificates are tracked separately.
  • Private keys are stored securely and can be replaced.
  • A second person can reissue and deploy a certificate.

Practice

  • A renewal dry run or staging issuance has succeeded recently.

Common mistakes

  • Renewing the certificate at the wrong layer. The CDN may still serve the expired one.
  • Installing only the leaf certificate. Some clients need the full chain.
  • Telling users to click through. This trains them to ignore real attacks.
  • Reusing an exposed private key. Reissue with a new key and revoke the old certificate.
  • Monitoring only the apex domain. API and webhook hostnames can expire separately.

Sources

Last reviewed July 19, 2026Guidance changes. Confirm provider-specific actions in the linked official sources.