--- title: "How SSL Certificates Expire Silently: The Failure Modes | FourSight" description: "Renewal automation fails without an error reaching a human. The seven ways certificates expire silently — and how to catch each one before browsers do." lang: en json-ld: | [ { "@context": "https://schema.org", "@type": "Article", "headline": "How SSL Certificates Expire Silently: The Failure Modes", "description": "Renewal automation fails without an error reaching a human. The seven ways certificates expire silently — and how to catch each one before browsers do.", "author": { "@type": "Organization", "name": "FourSight" }, "publisher": { "@type": "Organization", "name": "FourSight" }, "url": "https://foursight.cloud/guides/how-ssl-certificates-expire-silently", "mainEntityOfPage": "https://foursight.cloud/guides/how-ssl-certificates-expire-silently", "datePublished": "2026-07-14", "dateModified": "2026-07-14", "wordCount": 1600 }, { "@context": "https://schema.org", "@type": "BreadcrumbList", "itemListElement": [ { "@type": "ListItem", "position": 1, "name": "Home", "item": "https://foursight.cloud" }, { "@type": "ListItem", "position": 2, "name": "Guides", "item": "https://foursight.cloud/guides" }, { "@type": "ListItem", "position": 3, "name": "How SSL Certificates Expire Silently: The Failure Modes", "item": "https://foursight.cloud/guides/how-ssl-certificates-expire-silently" } ] }, { "@context": "https://schema.org", "@type": "FAQPage", "mainEntity": [ { "@type": "Question", "name": "Why do SSL certificates expire silently instead of warning anyone?", "acceptedAnswer": { "@type": "Answer", "text": "Because the warning systems all have failure modes of their own: renewal automation fails without surfacing errors, CA reminder emails go to stale inboxes (and Let's Encrypt stopped sending them entirely in 2025), and internal dashboards only show what the renewal tool believes — not what your servers actually serve. The only warning that can't be silenced by the same failure is an independent external check of the certificate being served." } }, { "@type": "Question", "name": "Is there any grace period after a certificate expires?", "acceptedAnswer": { "@type": "Answer", "text": "No. Clients enforce the notAfter timestamp exactly — the moment it passes, browsers show full-page warnings and TLS libraries fail the handshake. There is no soft-fail window, which is why alerting needs to happen weeks before expiry, not at it." } }, { "@type": "Question", "name": "My certificate renewed — why is the old one still being served?", "acceptedAnswer": { "@type": "Answer", "text": "Renewal writes a new certificate to disk; serving it requires the web server, load balancer, or CDN to load it. A missing reload hook, a load balancer holding the old cert in memory, or an un-synced CDN edge all produce this gap. Externally monitoring the served certificate (rather than the file on disk) is what catches it." } }, { "@type": "Question", "name": "How early should I be alerted before expiry?", "acceptedAnswer": { "@type": "Answer", "text": "30 days for the first warning, escalating at 14 and paging at 7 — assuming a 90-day certificate renewed around the 30-day mark. As certificate lifetimes shrink toward 47 days later this decade, compress the ladder proportionally; the principle is that the first alert should mean 'your automation has already missed at least one renewal attempt.'" } }, { "@type": "Question", "name": "Do wildcard certificates change any of this?", "acceptedAnswer": { "@type": "Answer", "text": "They concentrate the risk: one silent renewal failure takes every covered subdomain down simultaneously, and wildcard renewal via ACME requires DNS-01 validation, which adds the DNS-provider API credential as an extra silent failure point. See our wildcard vs SAN monitoring guide for the details." } } ] } ] --- [FourSight ](/) [Features](/#features)[Pricing](/pricing)[Guides](/guides)[Glossary](/glossary)[FAQ](/faq) [Login](/auth)[Start free](/auth?signup=true) [Start free](/auth?signup=true) [All Guides](/guides) Reliability & Infrastructure # How SSL Certificates Expire Silently: The Failure Modes Renewal automation fails without an error reaching a human. The seven ways certificates expire silently — and how to catch each one before browsers do. 8 min read Guide Published Jul 14, 2026 ## Why Certificates Expire Silently [SSL](/glossary/ssl-tls "Glossary: SSL") certificates expire silently because the systems responsible for renewing them fail without ever surfacing an error to a human. Renewal automation — an ACME client, a cloud certificate manager, a hosting provider's built-in renewal — either stops running, runs but fails, or succeeds without the new certificate actually reaching the servers your users connect to. In every variant, no dashboard turns red and no email lands in a monitored inbox; the countdown to the notAfter timestamp just continues. Then, at the exact second the certificate expires, every browser, API client, and webhook sender simultaneously starts refusing to connect. The failure was weeks in the making, but the outage arrives as a cliff. This guide catalogs the specific ways that silence happens, because each one has a different fix — and one shared detection strategy. Related Reading - [→ Feature: SSL certificate monitoring](/features/ssl-monitoring) ## What Actually Happens at the Moment of Expiry A certificate's validity is bounded by two timestamps in the certificate itself — notBefore and notAfter, defined by the X.509 standard (RFC 5280). Clients enforce notAfter with no grace period whatsoever. The instant it passes, browsers show a full-page 'Your connection is not private' interstitial that most visitors will not click through. Mobile apps that pin certificates fail their TLS handshakes outright, usually surfacing as a vague 'network error.' API consumers with default TLS verification — which is to say, nearly all of them — throw certificate errors and stop calling you. Webhook senders like Stripe and GitHub treat the failed handshake as a delivery failure and begin their retry-and-eventually-disable cycle. Monitoring tools that only check for HTTP 200 may keep reporting success if they're configured to skip TLS verification, which is how some teams stay blind through the entire event. Related Reading - [→ Monitoring Stripe webhook reliability](/guides/monitoring-stripe-webhooks) ### Monitoring a Commercial SaaS? FourSight's free plan includes 10 commercial-safe monitors with multi-region validation — free forever, no card. [Start Monitoring Free](/auth?signup=true) ## The Seven Silent Failure Modes Post-incident writeups of certificate expiries converge on a small set of recurring causes. If you've operated production systems for more than a couple of years, you will recognize several of these personally. ### 1\. The Renewal Job Died The certbot systemd timer was disabled during an OS upgrade, the renewal cron entry was lost in a server rebuild, or the container that ran acme.sh was replaced by one that doesn't. The automation isn't failing — it's absent. Nothing logs an error because nothing runs. This is the single most common cause, and it's invisible from inside the box: the machine has no process whose job is to notice a missing process. ### 2\. The Challenge Path Broke ACME validation requires the certificate authority to reach your infrastructure — over HTTP for HTTP-01 challenges or via a [DNS](/glossary/dns "Glossary: DNS") [TXT record](/glossary/txt-record "Glossary: TXT record") for DNS-01. A tightened firewall rule, a new redirect-all-to-HTTPS rule that mangles /.well-known/acme-challenge/ requests, or a [CDN](/glossary/cdn "Glossary: CDN") placed in front of the origin can all break validation. The client runs on schedule, fails, logs the failure to a file nobody reads, and retries into the same wall for 30 days. ### 3\. Credentials Silently Rotated DNS-01 renewals depend on an API token for your DNS provider; cloud-managed certificates depend on IAM permissions. A routine security rotation, an expired API key, or a permission-boundary change breaks renewal months before the certificate expires. The rotation was correct and deliberate — the renewal dependency on it was just undocumented. ### 4\. Renewed but Never Deployed The new certificate exists on disk, but the web server never reloaded, the load balancer kept the old cert in memory, or one CDN edge configuration didn't get the update. From the renewal system's perspective everything succeeded. From the internet's perspective, the old certificate is still being served — and still counting down. A missing --deploy-hook that should have run 'systemctl reload nginx' is a classic instance. ### 5\. The One-Off Manual Certificate Somewhere in your estate is a certificate that was issued by hand for a special case — a partner integration domain, a country-specific TLD, an internal admin panel, a webhook receiver behind a proxy. No automation has ever renewed it; a person did, once, and then changed jobs. Manually issued certs are heavily overrepresented in expiry incidents relative to how few of them exist. ### 6\. Reminders Sent to the Void CA reminder emails go to whoever created the certificate — frequently a departed employee, a defunct distribution list, or an agency no longer under contract. And the industry is retiring reminders anyway: [Let's Encrypt](/glossary/lets-encrypt "Glossary: Let's Encrypt"), which issues the majority of certificates on the web, ended its expiration notification emails in 2025 and explicitly told users to rely on monitoring instead. An email that might reach the right inbox is not a control. ### 7\. The Infrastructure Moved On You migrated from Heroku to Vercel, or from VMs to Kubernetes, eighteen months ago. Renewal for one forgotten domain still lives on the old platform — sometimes literally on a decommissioned box or an ex-employee's laptop. The migration checklist covered the app; nobody inventoried which certificates renewed where. ## Shrinking Lifetimes Are Raising the Stakes The maximum lifetime of publicly trusted certificates is shrinking on an industry-agreed schedule. Under the CA/Browser Forum's 2025 decision, certificates issued since March 2026 are capped at roughly 200 days, the cap drops to about 100 days in 2027, and it lands near 47 days by 2029. Let's Encrypt certificates were already 90 days, and even shorter-lived options are appearing. The direct consequence: renewal stops being an annual ceremony and becomes a continuous background process that must work every few weeks, forever. Every failure mode above gets more chances to occur per year, while the window between 'automation broke' and 'certificate expired' compresses. Manual renewal as a fallback strategy stops being merely tedious and becomes operationally impossible at fleet scale — which makes detecting broken automation early the whole game. ## The One Detection Strategy That Covers All Seven Notice what the seven failure modes have in common: in every single one, the certificate actually being served to the public is approaching expiry without being replaced. That shared symptom is the detection point. An external monitor that performs a real TLS handshake against each endpoint, reads the served certificate's notAfter date, and alerts on a countdown — 30, 14, and 7 days out is FourSight's default ladder — catches all seven modes with one mechanism, without needing to know anything about your renewal tooling. It doesn't matter whether the cause was a dead timer, a blocked challenge, or an undeployed renewal: if the cert your users receive is 29 days from expiry, someone gets told, while there's still time to debug calmly. Pair the countdown with chain validation and host-mismatch detection and you also catch the certificate problems that aren't about expiry at all. **💡** Monitor every hostname you serve, not every certificate you know about. The certificates you know about are precisely the ones your automation is probably handling — the outage lives in the ones you forgot. [How FourSight's SSL monitoring works →](/features/ssl-monitoring) Related Reading - [→ Let's Encrypt auto-renewal failures: ACME failure modes explained](/guides/lets-encrypt-renewal-failures) - [→ Designing an SSL expiry alerting policy](/guides/ssl-expiry-alerting-policy) - [→ How to audit SSL certificates across your fleet](/guides/auditing-ssl-certificates-across-fleet) ## Frequently Asked Questions ### Why do SSL certificates expire silently instead of warning anyone? ### Is there any grace period after a certificate expires? ### My certificate renewed — why is the old one still being served? ### How early should I be alerted before expiry? ### Do wildcard certificates change any of this? #### Related Guides [What Is Uptime Monitoring? The Complete Guide 12 min ](/guides/what-is-uptime-monitoring)[Multi-Region Monitoring Explained 8 min ](/guides/multi-region-monitoring-explained)[SSL Certificate Expiry Monitoring 10 min ](/guides/ssl-certificate-expiry-monitoring)[Let's Encrypt Auto-Renewal Failures: ACME Failure Modes Explained 9 min ](/guides/lets-encrypt-renewal-failures) #### Compare FourSight [vs UptimeRobot →](/compare/uptimerobot-alternative)[vs StatusCake →](/compare/statuscake-alternative)[vs Pingdom →](/compare/pingdom-alternative) 10 free commercial-safe monitors [View Pricing](/pricing) ## Protect Your SaaS Revenue Start monitoring in under 60 seconds. [Start Monitoring Free](/auth?signup=true)[View Pricing](/pricing) FourSight © 2026 [TetraCore](https://tetracorehq.com/). All rights reserved. FourSight is a TetraCore product — Bowling Green, Ohio. Product [Pricing](/pricing)[Guides](/guides)[Glossary](/glossary)[FAQ](/faq)[About](/about)[For Agencies](/solutions/agencies)[For Startups](/solutions/startups)[Privacy](/privacy)[Terms](/terms) Features [Cron Job & Heartbeat Monitoring](/features/cron-job-monitoring)[SSL Certificate Monitoring](/features/ssl-monitoring)[Status Pages](/features/status-pages)[Domain Expiry Monitoring](/features/domain-expiry-monitoring)[DNS Monitoring](/features/dns-monitoring)[Port Monitoring](/features/port-monitoring) Compare [All comparisons](/compare)[vs UptimeRobot](/compare/uptimerobot-alternative)[vs StatusCake](/compare/statuscake-alternative)[vs Freshping](/compare/freshping-alternative)[vs Pingdom](/compare/pingdom-alternative)[vs Pulsetic](/compare/pulsetic-alternative)[vs Better Stack](/compare/better-stack-alternative)[vs Uptime Kuma](/compare/uptime-kuma-alternative)[vs Cronitor](/compare/cronitor-alternative)[vs Healthchecks.io](/compare/healthchecks-alternative)[vs Hyperping](/compare/hyperping-alternative) Pricing Guides [UptimeRobot Pricing](/compare/uptimerobot-pricing)[StatusCake Pricing](/compare/statuscake-pricing)[Pingdom Pricing](/compare/pingdom-pricing)[Better Stack Pricing](/compare/better-stack-pricing)[Uptime Kuma Pricing](/compare/uptime-kuma-pricing)[Cronitor Pricing](/compare/cronitor-pricing)[Healthchecks.io Pricing](/compare/healthchecks-pricing)[Hyperping Pricing](/compare/hyperping-pricing)[Pulsetic Pricing](/compare/pulsetic-pricing)