SSL/TLS certificate expiration: why it still takes websites down

When a TLS certificate expires, browsers stop trusting the connection and show a full-page warning instead of your website. APIs, mobile apps and integrations that connect to the same host usually fail outright, because their clients refuse an expired certificate without asking anyone. The site itself may be running perfectly, but for visitors it is down.

Renewal has been automated for years, so why does this still happen? Because automation covers the certificates someone remembered to automate. Expiry outages usually come from the forgotten ones: a subdomain set up for a campaign, a load balancer with a manually uploaded certificate, a mail server, or a renewal job that has been silently failing for weeks.

Certificate lifetimes are also getting shorter, which means every renewal process gets exercised more often.

Certificate lifetimes are shrinking

The CA/Browser Forum sets the rules publicly trusted certificate authorities follow. In April 2025 it passed ballot SC-081v3, and the current TLS Baseline Requirements (section 6.3.2) set this schedule for the maximum validity of a certificate:

• issued before 15 March 2026: a 398-day maximum,
• issued from 15 March 2026: a 200-day maximum,
• issued from 15 March 2027: a 100-day maximum,
• issued from 15 March 2029: a 47-day maximum.

In practice this means that by 2029 a manually renewed certificate would need replacing roughly every 6 to 7 weeks. Any certificate still renewed by hand, from a calendar reminder, becomes a recurring outage risk.

Reminders from the certificate authority are not something to count on either. Let's Encrypt, for example, ended its expiration notification emails on 4 June 2025.

Why renewals fail

The common causes are mundane:

• Validation fails. HTTP validation breaks after a redirect or firewall change; DNS validation breaks after a DNS provider change or an expired API token.
• Renewal succeeds but the service is not reloaded, so the web server keeps serving the old certificate.
• Certificates were copied by hand to a load balancer, CDN, appliance or mail server that the automation does not reach.
• Nobody owns the host. Staging servers and old marketing subdomains often have certificates but no owner. See forgotten staging and test servers.
• The account or payment for a commercial certificate lapsed.
• The intermediate chain is incomplete, which some clients reject even before expiry.

How to check certificate expiry yourself

For a single host, openssl shows the dates the server actually presents:

echo | openssl s_client -connect example.com:443 -servername example.com 2>/dev/null | openssl x509 -noout -dates -issuer

Look at notAfter. Check every name separately, including www, API hosts and mail hosts. For a mail server using STARTTLS:

echo | openssl s_client -starttls smtp -connect mail.example.com:25 2>/dev/null | openssl x509 -noout -enddate

To find hosts you may have forgotten, search Certificate Transparency logs on crt.sh for %.example.com. Every certificate issued for your domain is listed there, including ones for subdomains nobody remembers. Our article on Certificate Transparency logs explains how to read the results.

How to keep certificates from expiring

1. Automate issuance and renewal with ACME wherever possible, and make the renewal job reload the service afterwards.
2. Renew well before expiry, early enough to leave time to fix a failed validation.
3. Alert on renewal failures, not only on success. A cron job that exits with an error and tells no one is the classic cause.
4. Keep an inventory of every host with a certificate, built from Certificate Transparency results, not from memory.
5. Monitor from outside. Check the certificate the server actually presents, because that is what clients see. An internal record saying "renewed" is not the same thing.
6. Remove what you no longer use. A subdomain that no longer serves anything should lose its DNS record and its certificate.

If a certificate has already expired

• Renew or reissue it, deploy it, and reload the service.
• Confirm with openssl s_client from outside your network that the new notAfter date is served.
• Check that the full chain is served, not only the leaf certificate.
• Check dependent clients: mobile apps, partners' integrations and webhooks may need a retry.
• Find out why the alert did not fire and fix that.

Checklist

• Inventory of all hosts with certificates, including mail and API hosts.
• ACME automation with service reload.
• Alerts on failed renewals.
• External expiry check on every host.
• Readiness for 100-day and 47-day lifetimes.

Domains expire too, with very different consequences. See what happens when your domain expires.

How Datahorses helps

Guarding watches your company from the outside and checks the certificates your servers actually present, including expiry, broken chains and self-signed certificates, with reminders 30, 14 and 3 days before a certificate or domain expires. We do not enter your systems and need no access. See what we guard, and the example dashboard for how it looks.