Skip to content
RO
← All writing

SSL certificates are shrinking to 64 days: why "automatic" renewals still take websites down

  • ssl
  • hosting
  • maintenance
  • infrastructure

Public SSL and TLS certificates are getting much shorter lives. Under CA/Browser Forum Ballot SC-081v3, the maximum lifespan for a paid certificate dropped from 398 days to 200 days on 15 March 2026, and it drops again to 100 days on 15 March 2027. Earlier this month, Let’s Encrypt confirmed its own schedule is moving even faster: default 90-day certificates shrink to 64 days on 10 February 2027, and down to 45 days in February 2028.

Every hosting company will tell you this changes nothing because renewals are automatic. They are automatic right up until an IPv6 record drifts, a firewall blocks port 80, or Nginx forgets to reload its configuration, and a customer rings you on a Monday morning to ask why Chrome is showing a full-screen security warning on your checkout page.

Why you no longer get a warning email before it breaks

For years, small business owners and developers had a safety net they barely thought about. If the `certbot` timer or cPanel auto-renew script on a server started failing quietly in the background, Let’s Encrypt would send an email twenty days before expiry, and another at seven days, warning you that the certificate was about to die.

That safety net is gone. Let’s Encrypt shut down its expiration notification emails in June 2025 and deleted the email addresses attached to ACME accounts for privacy reasons. If your renewal script starts failing silently on a Tuesday night, nobody at the Certificate Authority is going to email you. And when a 64-day or 45-day certificate renews roughly a third of the way before expiry, the gap between the first silent failure and a dead website shrinks from a month down to about two weeks.

The four ways “automatic” SSL renewals fail on real servers

When I take over a site on my £49 a month website care plan or audit a Linux server, a broken SSL renewal is almost never caused by the certificate authority going down. It is caused by a tiny change somebody made three weeks earlier without thinking about the renewal script.

First, the certificate renews on disk, but the web server never reloads it. Certbot fetches the new `.pem` files cleanly and writes them into `/etc/letsencrypt/live/`, so the renewal log says success. Meanwhile, Nginx or Apache is still holding the old certificate in memory because nobody added a `deploy-hook` to reload the service after a renewal. Everything looks fine until the old certificate in memory hits its expiry second.

Second, somebody changes a DNS record or turns on a proxy. A marketing agency adds a stale IPv6 `AAAA` record that points at an old server, or flips a Cloudflare DNS toggle without matching the SSL mode. Because the ACME verification bot checks IPv6 first when an `AAAA` record exists, the challenge fails even though the site loads normally on IPv4.

Third, port 80 gets blocked during a firewall tidy-up. Someone locks down the server firewall and closes port 80 because all live traffic runs over HTTPS on port 443. Two months later, the HTTP-01 renewal challenge tries to reach `/.well-known/acme-challenge/` over port 80, hits the firewall wall, and times out.

Fourth, commercial OV and EV certificates still rely on a human with a calendar reminder. Businesses that buy annual certificates from a registrar and paste the `.crt` file into a load balancer by hand already had their validity cut to 200 days in March 2026. Next March, at 100 days, doing it by hand means repeating the paperwork four times a year.

The new certificate timeline from 2026 to 2029

If you look after a company website, an API, or an internal portal, here are the exact dates the industry is enforcing:

Effective dateWhat changesWho enforces itWhat it means for your server
15 March 2026 (Live now)Maximum public certificate validity cut from 398 days to 200 daysCA/Browser Forum (Ballot SC-081v3)Annual manual SSL renewals are dead; paid certs must be replaced at least twice a year
10 February 2027Default Let’s Encrypt lifetime drops from 90 days to 64 days (auth reuse cut to 10 days)Let’s EncryptRenewal runs roughly every 40 to 45 days; broken scripts take sites down in half the time
15 March 2027Maximum public certificate validity drops to 100 daysCA/Browser ForumManual installs now require changing certificates every two to three months
16 February 2028Default Let’s Encrypt lifetime drops to 45 days (auth reuse cut to 7 hours)Let’s EncryptRenewal runs every 30 days; DNS or firewall drift leaves only days of grace to fix
15 March 2029Maximum public certificate validity drops to 47 days (domain validation reuse cut to 10 days)CA/Browser ForumEvery public website must use automated ACME deployment or break constantly

How to check your own server in thirty seconds

Just like a Linux server that says it is patched while running an old kernel, checking whether `certbot.timer` is enabled is not enough. You need to know two things: whether a dry-run renewal succeeds against your live DNS right now, and whether the certificate actually being served over port 443 matches the one on disk.

On my own servers and client machines, I do not trust the local cron job to police itself. An external monitor connects to port 443 from outside the network every day, reads the actual expiry date presented by the TLS handshake, and flags an alert the moment a certificate drops below twenty-one days (or fourteen days once the 64-day cycle starts in February). That way, if a DNS change or a missing reload hook broke the renewal, a human being fixes it quietly two weeks before a single visitor sees a browser warning.

Common questions

Why are browser makers and Let’s Encrypt making certificates so short?
Because certificate revocation on the web is unreliable. When a private key leaks or a domain changes hands, browsers cannot always check revocation lists quickly. Shorter certificates mean a compromised certificate expires naturally in a few weeks rather than staying valid for thirteen months.

Do I need to pay extra for a 200-day or 100-day commercial SSL certificate?
For almost every small business website, no. A free, properly automated Let’s Encrypt certificate uses the exact same encryption strength as a £150 commercial certificate, and handles the move to 64-day and 45-day lifetimes automatically via the ACME protocol without anyone having to paste files into a control panel.

How do I stop my website going down when 64-day certificates start in February 2027?
Make sure your server uses an automated ACME client with a working web-server reload hook, keep port 80 open for `.well-known/acme-challenge/` requests (or use DNS-01 validation), and run an external check against port 443 so you do not rely on the server emailing you when its own timer fails.

If you would rather not think about certificate lifetimes, reload hooks, or server patches, have a look at my £49 a month Website Care Plan or my Servers and Infrastructure work, or send me a message with your domain and I will check how your current certificate is set up.