The Road to 47-Day Certificates: When Renewal Automation Fails Silently

The bottom line: a certificate that auto-renews on schedule can still take your site down, because the cert your server holds on disk is not always the cert it is serving in memory, the chain it sends can break even while the leaf is valid, and a green days-remaining badge cannot see either of those. Maximum public TLS certificate lifetimes are shrinking on a fixed schedule, from 398 days down to 200 as of March 15 2026, then 100 in 2027, then 47 in 2029, which multiplies renewal events and with them the chances for a silent failure. To catch these failures you need a check that talks to the live socket and confirms a real client can complete the handshake and load the page, not just a number that counts down the leaf certificate. Start for free.

The road to 47 days (and why it changes the math)

For years the practical answer to "how long does a certificate last" was about a year, and renewal was a once-a-year chore you could half forget about. That era is ending on a published schedule. The maximum lifetime of a public TLS certificate is stepping down, and each step means you renew more often, which means the renewal machinery runs more often, which means it has more opportunities to fail quietly.

What actually got decided, and when

In April 2025 the CA/Browser Forum, the body that sets the baseline rules every public certificate authority and major browser follows, adopted Ballot SC-081v3. It was proposed by Apple's Clint Wilson and endorsed by Sectigo, Google Chrome, and Mozilla (CA/Browser Forum, Ballot SC-081v3, verified 2026-06-03). It sets a schedule that ratchets the maximum TLS certificate validity down in steps:

• 398 days, the prior maximum, before the schedule begins.
• 200 days starting March 15 2026.
• 100 days starting March 15 2027.
• 47 days starting March 15 2029.

Domain-validation data-reuse windows shrink in lockstep over the same timeline, trending toward roughly ten days for the validation tied to the names on a certificate. The exact day-counts at each intermediate step are detailed in the ballot itself, so treat the precise numbers as a moving target and the direction as the certainty: re-validation has to happen far more often, so the parts of issuance you used to set and forget now run on a much tighter loop.

More renewals = more chances to fail silently

The lifetime number is not the risk. The risk is the renewal event, and shorter lifetimes give you more of them. A certificate that renews once a year exercises your renewal automation, your reload hook, and your chain configuration once a year. Drop to 47 days and the same machinery fires roughly eight times a year. Every one of those runs is a chance for the cron to be stopped, for a deploy hook to be missing, for a reload to be skipped, or for the served chain to drift. The failure modes are not new. Shorter lifetimes just hand you many more rolls of the same dice, and a once-a-year problem becomes a several-times-a-year problem.

That is the whole argument for watching renewals as a recurring event rather than treating a fresh certificate as a job done. Set-and-forget was always optimistic. On the road to 47 days it stops being viable at all.

A separate timeline you should not conflate

One thing to keep straight: Let's Encrypt is also shortening its certificates, but that is a separate decision from the CA/Browser Forum mandate above. Let's Encrypt has said it intends to cut its own default lifetime from 90 days toward 45 by 2028, and it offers an opt-in short-lived profile of around six days for setups that want it (Let's Encrypt, from 90 to 45, verified 2026-06-03). Do not merge the two timelines in your head. The CA/B schedule is the industry-wide ceiling everyone lives under; the Let's Encrypt change is one issuer moving faster than the ceiling requires. Both point the same way, shorter lifetimes and more renewals, which is the only takeaway you need for monitoring.

Why a "days remaining" badge is structurally blind

A days-remaining check reads one field off the leaf certificate: the notAfter date. It subtracts today from that date and shows you a number. That number is genuinely useful for one job, catching a certificate that is about to lapse, and you should run it. For the expiry-countdown setup and the 30-15-7 threshold rule that governs how to act on that number, see our guide on SSL certificate expiry monitoring. That post owns the countdown. This one starts where the countdown goes blind.

The badge is structurally blind because both of the failures in this post leave the leaf's notAfter date completely healthy. A renewal that succeeds on disk but never reloads the server still has a valid leaf; the number is fine. A served chain that breaks because an intermediate is missing or a cross-sign expired still has a valid leaf; the number is fine. In both cases the page is down for real clients while the badge stays green. That is the most dangerous shape an outage can take, a green dashboard over a broken site, and it is exactly the pattern we walk through in the anatomy of a silent outage.

The fix is not a better expiry number. It is a different question. Instead of asking "how many days until the leaf expires," you ask "can a standard client complete the handshake and load the page right now." The rest of this post is the two ways the answer to that second question goes no while the first question still looks fine.

Cert on disk is not cert in memory

The first trap is that renewal and serving are two separate acts. Renewal writes new certificate files to disk. Serving reads a certificate that the web server loaded into memory when it last started. Those two can drift apart, and when they do, a check that inspects the file on disk will swear everything is fine while the live socket serves a different cert.

The renew-without-reload gap

Here is the exact sequence. Your renewal client, certbot for example, wakes up on its timer, talks to the certificate authority, and writes a fresh certificate and key to disk. The renewal command reports success. The files are correct. The expiry date on disk is now months out. And your web server keeps serving the old certificate, because Nginx, Apache, and most load balancers load the certificate into memory at startup and do not re-read the file just because it changed. Until the process is reloaded, what is on the wire is the previous certificate, counting down toward its real expiry while the disk says all is well (Certbot documentation on deploy hooks, verified 2026-06-03).

The fix is a deploy hook, sometimes called a reload hook, that runs only when a certificate actually changes and reloads the web server as the last step of renewal. Certbot has first-class support for this; you give it a command to run on a successful renewal, and that command reloads the server so memory catches up with disk. Without that hook, renewal and serving stay decoupled, and you have manufactured a window where the files lie about what your visitors are actually getting. The reason this is worth a whole section is that it defeats the most common do-it-yourself check, a script that reads the cert file or asks certbot when things expire. That script reads disk. Your customers hit memory.

The stale cert cached at the load balancer or CDN

The same disk-versus-memory split happens one layer out, at your load balancer or CDN, and it is sneakier because the box that renews and the box that serves are not even the same machine. A renewal completes on the origin, but the certificate that actually faces the internet lives on a load balancer, a reverse proxy, or a CDN edge that holds its own copy. If the new certificate is not pushed to that layer, or the layer does not reload, the edge serves a stale cert to the world while the origin is perfectly up to date.

This gets worse with a CDN that has many points of presence, because the new certificate can propagate to some edges and not others. Now the cert a visitor sees depends on which edge they hit, which usually means it depends on where in the world they are. One market gets the fresh certificate, another market gets the stale one, and a single-location check sees whichever edge happens to answer it. The only way to catch a geo-divergent certificate is to look from more than one place at once, which is the multi-region angle the closing section comes back to.

The chain can break while the leaf is valid

The second trap has nothing to do with expiry dates at all. A certificate is not trusted in isolation. A client trusts it by building a path from your leaf certificate, through one or more intermediate certificates, up to a root certificate it already trusts. If any link in that path is missing or expired in the chain your server sends, the client cannot complete the path, and it rejects the connection, even though your leaf says it is valid for months.

How a served chain breaks

The most common cause is the simplest: the server is configured to send only the leaf certificate and omits the intermediate bundle. A lot of clients paper over this by fetching the missing intermediate themselves or by caching one they have seen before, which is exactly why it is so dangerous. It works in your browser, it works on your laptop, and it fails on the strict client that does not do that extra fetching. The chain was always incomplete; you just had a forgiving client.

The other cause is timing inside the chain itself. Certificate authorities sometimes cross-sign an intermediate or root with an older, more widely trusted certificate so that older devices can still build a path. That cross-signing certificate has its own expiry date, separate from your leaf. When the cross-sign expires, clients that were relying on it to reach a trusted root suddenly cannot, even though your leaf and the newer chain are completely valid. The mechanism is the same as a missing intermediate: a path that used to resolve no longer does, and your leaf is innocent the whole time.

A dated illustration: the DST Root CA X3 cross-sign expiry, 2021

The clearest real example is history, not a current threat, so read it as a 2021 case study rather than a live warning. On September 30 2021, the DST Root CA X3 cross-sign that Let's Encrypt had relied on reached its expiry date. Servers were sending a chain that built up to that old root for the benefit of older clients. When it expired, those older clients, notably older Android versions and systems on OpenSSL 1.0.x, could no longer build a trusted path and started rejecting connections, even when they actually did trust Let's Encrypt's own newer root, ISRG Root X1 (Let's Encrypt, DST Root CA X3 expiration, September 2021, verified 2026-06-03).

The point of the example is not the specific roots. It is the shape. Every affected leaf certificate had a perfectly valid notAfter date the entire time. A days-remaining check would have shown green through the whole event. The thing that expired was a link in the chain, not the certificate the badge was watching, and the clients that broke were the ones with no human to click through. For diagnosing a chain on a specific host, the right tool is a chain inspector like SSL Labs, which walks the served chain and grades it.

Automated clients hard-fail where browsers click through

Both traps above share a property that makes them genuinely hard to notice: the way you check matters more than whether you check. Open the site in your own browser and you are using the most forgiving client that exists. An interactive browser that hits a broken chain or an expired cert shows a full-page warning and, in most cases, offers a way to proceed anyway. A human reads the warning, clicks through, and the page loads. From your chair, the site works.

Automated clients do not get that choice. A cron job calling your API, a server-side SDK talking to a partner, a webhook delivery from a payment processor, a mobile app refreshing data, and an external monitor all fail the TLS handshake and throw an error. There is no "proceed anyway" for a machine. So the exact integrations you depend on, machine to machine, the ones with nobody sitting there to override a warning, are the ones that break first and loudest, while your own browser tells you everything is fine.

This is why a real client check beats a human spot-check, and it is the same reasoning behind treating any automated dependency as something you verify on a schedule rather than trust by default. The patterns for proving an automated client can actually complete a call live in our API health check patterns guide. A broken cert is just one more reason a machine-to-machine call fails closed while a browser sails through.

What catches this when a days-remaining check can't

Here is the honest scope of what Velprove does, because the wedge only works if it is true. Velprove's SSL probe reads the leaf certificate: its expiry date and its issuer. It does not introspect or report the certificate chain. So Velprove does not inspect your chain, and any tool that claims to walk and grade your full chain is doing something Velprove's SSL probe does not. For that, use a dedicated chain inspector like SSL Labs, the same recommendation as our expiry guide.

What Velprove does catch is the symptom, which is the part your customers actually feel. Run an HTTP monitor with a content assertion against your live URL, and it fails closed whenever the server serves a chain a standard client will not trust, because the fetch itself errors out on the handshake. The content assertion goes further: it checks that a known piece of your page actually rendered, so a broken page, a mixed-content failure, or a wrong certificate being served all surface as a failed assertion that a bare leaf-expiry reading sails straight past. You are not asking "is the leaf expiry date fine." You are asking "can a real client load this page," which is the question both traps in this post answer no to.

Because every Velprove monitor runs from a region you choose, and 5 regions are available on every plan including free, the same check catches a CDN serving a stale or geo-divergent certificate in one market. Deploy the same monitor in more than one region and the market where the edge is serving the wrong cert goes red while the others stay green. That is the geo-divergence problem from the disk-versus-memory section, caught from outside.

The renew-without-reload case is caught the same way, and for the same reason. The monitor talks to the live socket, not the file on disk. If the edge or origin is still serving the old certificate from memory, the monitor sees the old certificate, because that is what a real visitor sees. A check that reads the file would be fooled. A check that opens a connection cannot be, because it is asking the same thing your customer is.

One safety note if you wire this up against an authenticated path. Use a dedicated, low-privilege test account, never real admin credentials, so a monitoring credential can do nothing more than confirm a page loads. That same least-privilege rule shows up in the broader monitoring mistakes small businesses make, which already lists having no SSL alerts at all as one of them. The upgrade this post argues for is going one step past an expiry alert to a functional check that proves a real client can connect.

Velprove is a solo-founder uptime tool built for exactly this kind of gap. Its standout feature, the free no-code browser login monitor that signs into your own application with a real browser, is overkill for a pure HTTPS health check, but it is there on the free plan if your site sits behind a login. For this job, a single HTTP monitor with a content assertion, run from the regions you care about, is enough to turn a silent cert failure into an alert. Commercial use is allowed on every plan, including free, with no credit card.

Frequently asked questions

My cert auto-renewed but the site still serves the old one. Why?

Because the new certificate is on disk, but your web server is still holding the old one in memory. Tools like certbot can renew the certificate files successfully and write fresh ones to disk, yet Nginx, Apache, or your load balancer keep serving the previously loaded certificate until the process is reloaded. The fix is a deploy or reload hook that reloads the web server every time a renewal succeeds. Certbot supports a deploy hook that runs only when a certificate actually changes. Until that reload runs, what is on disk and what is on the wire are two different certificates, and a check that reads the file on disk would tell you everything is fine while the live socket serves a soon-to-expire cert.

What is a broken certificate chain if the certificate itself is valid?

A served chain is the leaf certificate plus the intermediate certificates a client needs to build a path back to a trusted root. The leaf can be perfectly valid, unexpired, and correctly issued, while the chain a client receives is incomplete or contains an expired cross-sign. That happens most often when a server is configured to send only the leaf and omits the intermediate bundle, or when a cross-signing certificate the chain relied on reaches its own expiry date. A standard client cannot build a trusted path, so it rejects the connection even though the leaf says it is valid for months. A days-until-expiry reading of the leaf never sees this, because the leaf is genuinely fine.

Will a "days until expiry" check catch a renewal-automation failure?

Partially, and only one kind. A days-remaining check catches the certificate that is genuinely about to lapse, which is the case the threshold rule is built for. It does not catch a renew-without-reload gap, where the disk has a fresh cert but the server still serves the old one, and it does not catch a broken served chain, where the leaf is valid but a standard client cannot trust it. Both of those fail while the days-remaining number still looks healthy. You need a check that talks to the live socket and confirms a real client can complete the handshake and load the page, not just one that reads the expiry field off the leaf.

Are SSL certificates really 47 days now?

Not yet. The CA/Browser Forum adopted a schedule that steps the maximum public TLS certificate lifetime down over several years: 200 days starting March 15 2026, 100 days starting March 15 2027, and 47 days starting March 15 2029. So 47 days is the 2029 endpoint, not today's number. The trend that matters now is the direction. Every step shortens the lifetime, which means more renewal events per year, which means more chances for a renewal to succeed on disk but fail on the wire. Shorter lifetimes do not make renewal automation more fragile by themselves; they just multiply how often you run it, and anything you run more often you should watch more carefully.

Do browsers and API clients react to a broken cert the same way?

No, and the difference is why a broken cert can be invisible to you. An interactive browser shows a full-page warning and usually offers a way to proceed anyway, so a human can click through and the page still loads for them. Automated clients do not. A cron job, an SDK, a server-to-server API call, a webhook delivery, and an external monitor all fail the TLS handshake and throw an error with no human to override it. So your own browser can look fine while every machine-to-machine integration you depend on is failing closed. The clients that break first are exactly the ones with nobody watching.

How is this different from SSL expiry monitoring?

Expiry monitoring answers one question: how many days until the leaf certificate lapses, and it is the right tool for that. For the expiry-countdown setup and the 30-15-7 threshold rule, see our guide on SSL certificate expiry monitoring. This post covers the failures that a days-remaining number cannot see: a renewal that wrote a fresh cert to disk but never reloaded the server, and a served chain that breaks while the leaf is still valid. Both show a healthy expiry number and a broken site at the same time. The two are complementary. Run an expiry check for the countdown, and run a functional check against the live socket so a real client failure surfaces even when the days-remaining badge is green.

Start watching the symptom, not just the date

Renewal automation is a good thing, and you should keep it. The mistake is believing that a successful renewal and a green days-remaining badge mean a working site. They do not. A cert can renew on disk and never reach memory, a chain can break while the leaf is valid for months, and both failures hide behind a healthy expiry number while every automated client fails closed. On the road to 47-day certificates you will run renewals several times more often than you do today, so the odds of one of these slipping through go up, not down.

Catch the symptom from outside. Point an HTTP monitor with a content assertion at your live HTTPS URL, run it from the regions your customers are in, and you get an alert the moment a real client cannot load the page, whatever the underlying cert problem is. Pair it with an expiry countdown for the leaf, and for the countdown setup and the 30-15-7 threshold rule, see SSL certificate expiry monitoring.

Set up a free HTTPS monitor with Velprove. The region you choose, a content assertion, no credit card, commercial use allowed on every plan including free.