SSL certificate expiry on client sites: how to stop surprise outages

Why certificates still expire

Most certificates renew on their own, and that is the problem: nobody watches a process that works for two years. Renewal stops when something around it changes.

• A DNS or hosting move. The renewal job validates the domain over HTTP or DNS. After the move it asks the old server, or checks a record that no longer exists, and fails quietly.
• A firewall or redirect rule. A new rule that redirects everything, including the validation path, or blocks the certificate authority’s checks.
• A payment or account lapse. A paid certificate, or the hosting plan it lives on, expires with the card.
• A forgotten staging copy or subdomain. shop.client.com was set up by a freelancer three years ago and nobody owns it.
• The renewal ran but the web server was never reloaded. The new certificate sits on disk while the old one is still served.
• A change in who is in charge. The client moves hosting, a developer leaves, a plugin is deactivated.

None of these shows up as “down” for a long time. The site works until the day the old certificate stops being valid.

What a visitor sees

An expired certificate stops the TLS handshake from being trusted. Browsers show an interstitial warning. If the site has sent a Strict-Transport-Security header, the browser will not offer a click-through: RFC 6797 says a browser must end the connection on any secure transport error, certificate validity included, and recommends giving the user no way to override it. That header is good practice, and it is also why an expired certificate on an HSTS site is a hard outage rather than a warning.

An uptime check that only asks “does the server answer on port 443” still passes. It has to complete the TLS handshake and read the certificate to notice.

The new lifetimes: more renewals, less slack

Publicly trusted certificates are getting shorter lives. The CA/Browser Forum schedule adopted in 2025 (ballot SC-081v3) lowers the maximum validity from 398 days to 200 days on 15 March 2026, to 100 days on 15 March 2027 and to 47 days on 15 March 2029. The limits apply when a certificate is issued, so a certificate issued earlier stays valid until its own end date.

Let’s Encrypt, a widely used free certificate authority, has published its own plan: an optional 45-day profile from 13 May 2026, 64-day certificates by default from 10 February 2027 and 45 days by default from 16 February 2028.

What this means for an agency:

• A client with one certificate used to have one renewal a year. With 100-day certificates it has about four, and with 47-day certificates about eight.
• Manual renewal stops being realistic. A certificate bought once a year and installed by hand will need automation.
• Automation moves the risk. The risk is no longer “did someone remember”, it is “is the automation still working after the last change”.

The honest conclusion: certificates will not expire more often because authorities are careless. They will fail more often only where automation is unwatched. Watching the result is the cheap fix.

A routine that catches expiry early

1. List every hostname that serves a certificate for each client. The main site, www, the shop subdomain, the staging site that is still public, the mail web interface. Expiry on a forgotten subdomain is still a call from the client.
2. Record the expiry date and the issuer for each. A spreadsheet is enough to start. A note of who renews it (hosting platform, Let’s Encrypt on the server, the client’s IT) matters more than the date.
3. Alert at 30, 14 and 7 days. With 47-day certificates a 30-day warning is more than half of the lifetime, so alert on “renewal did not happen by the time it should have”, not only on days left. A certificate whose expiry date did not move when you expected it to is the signal.
4. Alert on replacement as well as on expiry. An unexpected new issuer or a different certificate on one region only is worth knowing about: it can be a move, a CDN change or a misconfiguration.
5. Check from outside. Your own server cannot tell you what the public sees, especially behind a CDN, which may serve its own certificate.
6. Decide who acts. An alert that goes to a shared inbox is read by nobody. Name the person.

What to do when an alert says 7 days left

1. Open the certificate details and find out which authority issued it and where it is installed.
2. Run the renewal by hand (for Let’s Encrypt with certbot, the dry-run option tests the whole chain without issuing).
3. Reload the web server or CDN, then re-check from outside to confirm the new expiry date.
4. Find out why automation failed and fix that, not only the certificate.
5. Write one line in the client log. A renewal you caught is exactly the kind of work a care report should show.

Mistakes that look like expiry but are not

• A name mismatch. The certificate is valid but does not list the hostname (www is missing, or only the apex is covered).
• A missing intermediate certificate. Desktop browsers may recover, mobile apps and older clients do not.
• A clock problem on the visitor’s device. Rare, and not yours to fix.
• A staging certificate in production. Test authorities issue certificates that no browser trusts.

The fix for each is different, so look at the actual error before changing anything.

Questions

Sources

Read on 26 October 2026. Standards and vendor pages change; confirm the current text before you rely on it.

• CA/Browser Forum ballot SC-081v3 timeline, as summarised by SecureW2 (securew2.com)
• Let’s Encrypt: Decreasing Certificate Lifetimes to 45 Days (letsencrypt.org)
• RFC 6797, HTTP Strict Transport Security (www.rfc-editor.org)