Automated Cert Renewal Fails Silently — and the 47-Day Cliff Turns 'If' Into 'When'

You automated certificate renewal years ago. Certbot, or an ACME client baked into your ingress, or your CDN doing it for you. It has worked every time since. So the certificate is a solved problem — right up until the morning a browser throws NET::ERR_CERT_DATE_INVALID on production and you discover the renewal has been failing quietly for six weeks in a log nobody reads.

The uncomfortable thing about automated renewal is this: automation issues the certificate, but nothing in that loop is obligated to tell you when it stopped. A cron job that fails is still a cron job that ran. And the industry is about to run that loop a lot more often.

The 47-Day Cliff: The Failure Surface Is About to Multiply

In April 2025 the CA/Browser Forum — the body whose rules every public certificate authority and browser follow — passed Ballot SC-081v3, 29 votes to 0. It shortens the maximum lifetime of a publicly trusted TLS certificate on a schedule:

The full schedule, the sources, and the renewal arithmetic live on the TLS certificate lifetime timeline. The operational takeaway is simpler than the table: by 2029 you reissue each certificate roughly eight times a year instead of once, and you re-prove domain control every ten days on top of that. Across a portfolio the number compounds — fifty domains at 47-day certs is on the order of 400 renewal events a year.

Here is the part that matters for reliability. Every one of those renewal events is a chance for the automation to fail. Going from one renewal a year to eight does not make renewal eight times more likely to succeed — it makes the silent failure eight times more likely to happen to you, and it shrinks the window between "the automation broke" and "the certificate is dead" from months to days. A 398-day cert that failed to renew still had weeks of runway. A 47-day cert that fails to renew is a near-term outage.

Why It Fails Quietly

Certificate automation is a chain — DNS, an ACME challenge, a CA, a file written, a service reloaded — and a chain fails at whichever link is weakest that week. The failures that bite are the ones that leave the old certificate in place and working, so nothing looks wrong until it expires:

• Port 80 got closed. A security review or a new firewall rule blocks inbound HTTP, and the HTTP-01 challenge can no longer be served. The last cert is still live, so no alarm — until renewal.
• A CAA record three labels up the tree. An apex issue "digicert.com" set years ago silently forbids a subdomain's Let's Encrypt renewal, because CAA inherits down the DNS tree. The CA obediently refuses; the failure surfaces weeks later as an "expired certificate," not a CAA error.
• A DNS-01 record that moved. The _acme-challenge TXT record points at a provider you migrated off, or an API token for the DNS plugin quietly expired. The challenge can't be answered.
• A rate limit. A misconfigured loop, a staging environment sharing a domain, or a burst of reissues trips the CA's rate limit and issuance is refused for the rest of the window.
• A hook that exits 0 but didn't reload. The renewal succeeds, writes a fresh certificate to disk — and the reload hook silently no-ops, so the server keeps serving the old cert from memory until it restarts. This one is especially cruel: the automation genuinely worked, and you still go down.
• DCV reuse shrinking underneath you. Under the new schedule, cached domain-control validation expires faster every stage. Automation that assumed a year of reuse and re-validates lazily starts hitting fresh validation requirements it was never exercised against.

None of these throw at the moment they happen. They all wait for the clock.

"It Exited 0" Is Not "The Certificate Is Fine"

The core mistake is treating the renewal command's exit code as proof of the served certificate's state. They are not the same fact, and the gap between them is exactly where outages live:

• The renewer can exit 0 and the reload can fail (the hook case above).
• The renewer can be skipped entirely — a disabled timer, a drained node, a container that no longer runs the cron — and a job that never runs emits no failure at all. Silence reads identically to success.
• The renewer can succeed for www and fail for api. on the same box, because they hit different challenge paths or different CAA policies.

The only ground truth is the certificate a client actually receives when it connects: its real notAfter, its issuer, its chain, from outside your own infrastructure. Everything else is a proxy for that, and every proxy has a failure mode where it lies by omission.

The Safety Net Automation Cannot Be

Automation and monitoring solve two different problems, and you need both:

• Automation issues and installs the certificate. It removes the human from the happy path.
• Monitoring is the independent observer that tells you when the happy path stopped — before the certificate lapses, not after a customer does.

The reason monitoring has to be independent is that a monitor built into the same automation inherits the same blind spots. If the thing that renews is also the thing that checks, then when the renewer is skipped, so is the check. An external observer that opens a real TLS connection to the live hostname and reads the served certificate's actual expiry has no such dependency: it doesn't care whether your cron ran, whether the hook reloaded, or whether the job even exists. It only reports what a browser would see.

As certificates move to 47 days, this stops being a nice-to-have. The margin for a missed renewal collapses from "you have weeks to notice" to "you have days," and the number of renewal events that could go wrong multiplies. A safety net that catches the miss early is the difference between a quiet fix and a public outage.

I write this while building Merlonix, which is that kind of independent observer. On every check it opens a real TLS handshake to your hostname, reads the served certificate's actual expiry, issuer, and chain, and marks it expiring soon before it lapses — then clears the alert automatically when a fresh certificate lands, so a successful renewal is confirmed, not assumed. Because it also walks the CAA inheritance chain, watches Certificate Transparency logs for certificates issued for your domain, and sits on the same DNS-security surface as DNSSEC, the "expired certificate" that is really a stale CAA policy or a broken chain surfaces as its actual cause, not as a dead-end symptom.

You can check any domain's live SSL, CAA, DNSSEC, and DNS posture right now without signing up, and the free tools hub has the rest. Automating renewal was the right move. Assuming it will tell you when it breaks is the one that ends in a NET::ERR_CERT_DATE_INVALID on a Monday — and every stage of the 47-day schedule makes that Monday arrive sooner.