SSL Certificate Expiry Fails Silently — Here's Every Way Automated Renewal Can Break Without Warning

An SSL certificate expiring gives you almost no visible warning — and then, with no gradual degradation, the site immediately starts showing a hard browser error to every visitor simultaneously

The previous articles on this site covered certificate types (DV/OV/EV), TLS configuration (versions/cipher suites/HSTS), and certificate transparency. This article addresses certificate expiry management — specifically, why expiry failures happen at well-run organizations, what automated renewal systems like Let's Encrypt + Certbot actually do, and what the failure modes of those systems look like.

Why certificates expire (and why shorter lifetimes are now the trend)

SSL/TLS certificates have expiry dates — certificates are valid for a defined period, after which browsers treat them as invalid. Originally, certificates could be valid for multiple years; the maximum publicly-trusted certificate lifetime has progressively shortened over time due to industry standards changes.

The reason shorter lifetimes are preferred: a compromised, revoked, or misissued certificate is a potential security problem for however long it remains "valid." Shorter lifetimes reduce the window of risk — if a private key is stolen but the certificate expires in 90 days, the damage is bounded (in time) more tightly than if the certificate is valid for two years.

Let's Encrypt issues 90-day certificates — a deliberate choice that forces automation (manually renewing every 90 days at scale is impractical) and limits risk exposure. The CA/Browser Forum is moving the industry toward even shorter lifetimes, with 47-day certificates expected to become the standard.

How automated renewal actually works — and where it breaks

The standard automated renewal stack (Certbot + Let's Encrypt + cron/systemd):

1. A certificate is issued via ACME protocol — the CA validates domain control (by checking a specific file at a specific URL, or a specific DNS record)
2. A cron job or systemd timer runs certbot renew periodically (typically daily) — Certbot checks if any certificates expire within 30 days and renews them if so
3. The renewed certificate is installed and the web server is reloaded to pick it up

Where this breaks in practice:

Cron job silently fails: the renewal cron job stops running (system update, misconfiguration, cron service restart) without anyone noticing — the certificate counts down to expiry unobserved.

Web server reload fails: Certbot renews the certificate successfully but the --deploy-hook or post-renewal script that reloads the web server (nginx/Apache) fails silently — the file is renewed, but the running web server continues serving the old, expiring certificate because it was never reloaded.

Domain validation fails: if the domain ownership validation method (HTTP file placement, or DNS record via DNS plugin) breaks — perhaps because a CDN or proxy configuration changed and the ACME validation URL is no longer reachable — Certbot renewal attempts fail. If nobody is watching the Certbot logs, these failures go unnoticed.

Certificate not being served is different from certificate not being renewed: if the server is configured to serve from a path but Certbot is renewing to a different path, the certificate file is renewed but the served certificate is the old one.

Monitoring certificate expiry: the check you need even with automation

Because automated renewal has failure modes that don't produce loud alerts, a complementary external monitoring layer is essential:

External certificate expiry monitoring — services that check your domain's certificate every day/hour, alerting you when expiry is within a configurable threshold (14 days, 7 days, etc.). This is independent of whether your renewal automation is functioning — it checks what's actually being served, not what's in the certificate files.

Why "check the file" isn't enough: as described, the file can be renewed while the served certificate is stale. External monitoring that actually connects to your server and reads the TLS handshake's certificate catches this scenario; checking only the certificate file on disk does not.

Notification routing: expiry alerts should go to somewhere that gets noticed (not just a log file, not just an email alias nobody checks) — a direct Slack/Teams notification, a PagerDuty alert, or similar — with enough lead time (14+ days) to diagnose and fix whatever broke in the automation before the actual expiry.

Certificate pinning: an additional complexity for mobile apps

HTTP Public Key Pinning (HPKP) — a mechanism allowing servers to specify which specific public keys clients should accept for their certificate — was a security feature designed to prevent certificate misissuance attacks. HPKP was deprecated due to catastrophic failure modes (getting it wrong would permanently lock users out of your site) and is no longer supported in modern browsers.

Certificate pinning in mobile apps (iOS/Android) still exists as an app-level implementation — some apps implement their own pinning, refusing connections to servers presenting certificates from unexpected CAs or with unexpected keys. This creates an interaction with certificate renewal: if a pinned key changes (because you replaced the certificate with a new one using a new private key, rather than renewing the existing key), those apps will reject the connection until the app is updated to recognize the new key. Certificate renewals for organizations with mobile apps that implement certificate pinning require careful key rotation planning — not just certificate renewal.

What your SSL checker result actually tells you

An SSL checker (this site's tool) checking your domain reports:

• Certificate validity: is the certificate currently valid?
• Days until expiry: how much time remains?
• Certificate chain: is the full chain (leaf certificate + intermediate CA certificate(s)) correctly configured?
• Subject alternative names (SANs): does the certificate cover the domain(s) you're checking?

What it doesn't tell you:

• Whether your automated renewal is functioning (only that the current certificate is valid)
• Whether the certificate will successfully renew before expiry
• Whether there are problems in the renewal pipeline that will cause it to fail

Use this tool for the current-state snapshot; use separate expiry monitoring for ongoing assurance that renewal is working.

How to use the SSL Checker on sadiqbd.com

1. Check expiry immediately after deployment changes: any time infrastructure changes (server changes, CDN configuration changes, load balancer changes), re-verify the certificate being served — configuration changes sometimes interfere with which certificate is actually presented
2. Verify the certificate chain: a missing intermediate CA certificate is a common misconfiguration that causes errors in some clients even when the certificate itself is valid — the checker shows whether the full chain is present
3. Check SANs against all hostnames you use: if your site is accessible at both example.com and www.example.com, verify the certificate covers both — a certificate that covers only www.example.com will show an error for example.com visitors

Frequently Asked Questions

Should I always renew with the same private key, or generate a new one each renewal? Generating a new private key with each renewal is generally recommended. If the existing private key was ever exposed (e.g., briefly accessible, or in a compromised backup), continuing to use it means the "renewed" certificate provides less protection than it appears. The automation overhead of generating a new key at each renewal is minimal. The exception: if you have mobile apps implementing certificate pinning based on the public key — in that case, rotating the key requires coordinated app updates, making a "renew with existing key" approach sometimes necessary for operational reasons — though this should be treated as a temporary accommodation rather than a permanent policy.

Is the SSL Checker free? Yes — completely free, no sign-up required.

Try the SSL Checker free at sadiqbd.com — verify your certificate validity, expiry date, and chain configuration for any domain.