FlawPilot
From the blog

The Certificate Renewal Nobody Put on a Calendar

Quick answer: TLS certificates aren't permanent. They expire on a set schedule, often every 90 days for a free certificate, longer for a paid one, and renewal is supposed to happen automatically…

The FlawPilot TeamSecurity research21 Sept 20267 min read

Quick answer: TLS certificates aren't permanent. They expire on a set schedule, often every 90 days for a free certificate, longer for a paid one, and renewal is supposed to happen automatically in the background. Automatic renewal depends on several things working correctly at once, a DNS record staying in place, a script actually running, a certificate authority not rejecting the request, and if any one of those quietly breaks, nothing looks wrong until the day the certificate actually expires. Then a visitor opens your site and gets a full-page browser warning instead of your homepage.

Everything else covered in a typical security check, a missing header, an exposed key, a misconfigured record, gives you a window to notice and fix it before anyone outside the team is affected. A certificate doesn't work that way. It's fine for 89 days, and then, all at once, it isn't.

What actually happens when a certificate expires

This isn't a subtle finding buried in a technical report. Most browsers show a full-page interstitial warning, not a small icon change, when a certificate has expired: "Your connection is not private," with the padlock gone and a warning that discourages the visitor from continuing. Most browsers still let a visitor click through an advanced option to proceed anyway, but for a domain on the HSTS preload list, that bypass is blocked entirely, the browser refuses to load the site at all until the certificate is valid again.

For a business, that's not a degraded experience, it's effectively an outage, and it looks exactly as bad as it sounds to a first-time visitor who has no idea the site was working fine yesterday. The traffic doesn't drop off gradually. It stops at whatever moment the certificate's expiration timestamp passes, whether that's 3am on a weekend or the middle of a product launch.

Why "it renews automatically" isn't as reliable as it sounds

Automated certificate renewal, through Let's Encrypt or a similar system, works by proving to the certificate authority that you still control the domain, usually by placing a specific DNS record or file that the authority checks before issuing a new certificate. That process has several links, and any one of them can quietly break without an error that anyone notices in time:

A DNS change breaks the validation record. If renewal uses a DNS-based challenge and something changes your DNS setup, a provider migration, a cleanup of "unused" records, a nameserver change, the validation record can disappear or stop resolving correctly. The renewal attempt fails, silently, and tries again on its normal schedule, failing the same way each time.

A renewal script stops running and nobody notices. Automated renewal is often a cron job or scheduled task running on a server. If that server gets replaced, migrated, or reconfigured, and the renewal job isn't carried over to the new setup, the certificate simply stops getting renewed. There's no error message anyone sees, because the thing that was supposed to run just isn't running anymore.

A CDN or load balancer has its own separate certificate. A common setup has a certificate at the edge, handled by a CDN or load balancer, and a separate certificate on the origin server behind it. Renewing one doesn't automatically renew the other, and a "we already sorted out certificates" conversation can quietly forget that there are two of them.

Rate limits or validation failures get silently retried into nothing. Certificate authorities like Let's Encrypt impose limits on how many certificates can be issued for a domain in a given period. A renewal attempt that hits an unrelated issue, a misconfigured account, an expired API token for the automation, can fail in a way that looks like a transient error and simply doesn't happen again until someone checks manually.

Why this stays invisible until the exact day it doesn't

Every one of those failure modes has the same shape: the certificate keeps working normally right up until its expiration date, because the old certificate is still valid and nothing about the live site changes in the meantime. There's no early warning built into the experience of visiting the site. The countdown is happening in the background, invisible, and the first visible signal is the expiration itself.

That's the opposite of most of the other things worth checking on a website. A missing security header or an exposed API key sits there, checkable, for as long as it's unfixed. A certificate expiration date is also checkable the entire time, the date is public information anyone can look up, but nothing about using the site day to day prompts anyone to actually look.

How to actually catch this before a visitor does

The expiration date on a certificate is public information, visible to anyone who checks, no login or server access required. From a terminal:

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

That returns the certificate's validity window directly. If you're not comfortable with a terminal command, most browsers will show the same date by clicking the padlock icon and viewing certificate details, though checking that manually on a schedule is exactly the kind of thing that quietly stops happening after the first few weeks.

The more durable fix is monitoring the expiration date on a recurring basis rather than relying on remembering to check, and treating a certificate that's approaching expiration with no confirmed renewal in progress as an active issue, not a future one. If there's a CDN or load balancer in front of the origin server, check both certificates separately, they can be on completely different renewal schedules and completely different failure modes.

Final Thoughts

A certificate expiring isn't a sophisticated failure. It's a maintenance task that was supposed to be automatic, quietly stopped being automatic at some point, and nobody found out until the exact moment it became visible to every single visitor at once.

The fix isn't complicated once it's caught early, renew the certificate, fix whatever broke in the automation, confirm it actually renews next cycle. The expensive version of this is finding out the same day a visitor does.

Frequently asked questions

It depends on the issuer. Free certificates from Let's Encrypt typically last 90 days and are meant to auto-renew well before that. Paid certificates from other authorities can last up to a year. Shorter validity periods are becoming more common industry-wide, which makes reliable automated renewal more important, not less.

How FlawPilot helps

FlawPilot finds security and quality issues in your AI-built app and shows you how to fix them. It checks your deployed site across security, performance, infrastructure, and SEO, and scans your source code for vulnerabilities, hardcoded secrets, and vulnerable dependencies.

Every finding is prioritized and explained in plain English, with the actual fix: the configuration change, DNS record, security header, or code change needed. For supported findings, AI-powered guidance adds step-by-step instructions and suggested code fixes.

Connect your Git provider to scan your repository alongside your live site, so application findings, code vulnerabilities, secrets, and dependency issues all land in one place.

It fits your existing workflow too: a REST API for scores and findings, an embeddable security badge, and an MCP server so tools like Claude, Cursor, or ChatGPT can read your findings and help you work through them.

The boundaries are clear: the public website scan reads only publicly accessible signals, with no agent or credentials required, and source-code scanning is opt-in and read-only. Fixes are never applied or merged without your review.

TLS certificatesSSLWebsite infrastructureAutomated renewalWebsite security

Verify your AI-generated app is production-ready.

117 security checks in 60 seconds - free, no account needed.

Scan one page

Enter a URL - no account, no install.

Run a Site Health check

Requires a free account

Crawls every page we can reach and scores each one, so a slow template deep in the site stops hiding behind a healthy homepage.

Scan your source code

Requires a free account

Connect a Git provider to check for vulnerabilities, secrets, and risky dependencies.

Featured on