Let's Encrypt Flipped Its Staging Server to 64-Day Certs. Your Homelab Renewal Script Is on Notice.

Two days ago, on October 14, Let's Encrypt flipped a switch most of the internet will never see. Its staging servers began issuing certificates valid for 64 days instead of 90. It was a quiet dry run for the largest change to the web's certificate plumbing in a decade, and if you self-host anything with a public address, it was aimed squarely at you.

The announcement landed a week earlier, on October 7. Starting February 10, 2027, every certificate issued under Let's Encrypt's default profile will carry a 64-day lifetime instead of the 90-day standard the internet has run on since 2015. This is not a trial or an opt-in experiment. It is the default, for everyone, and it is the first stop on a roadmap that ends with 45-day certificates becoming the default on February 16, 2028. For operators who want to move faster, two shorter opt-in profiles are available, at 45 days and roughly six days.

According to W3Techs data published in October 2026, Let's Encrypt now secures 64.3 percent of all websites, more than every other certificate authority combined. When a CA that large changes the default lifetime, every cron job, Docker Compose label, reverse-proxy config, and NAS web UI that assumed 90 days has to be checked. For self-hosters, this matters more than for most, because self-hosters are the ones most likely to have set up automation years ago and never touched it since.

What actually changes, and when

The schedule is precise. Staging moved to 64-day issuance on October 14, 2026, so you can test renewal behavior against shorter lifetimes today. Production follows on February 10, 2027. Existing certificates are untouched: Let's Encrypt says it will not revoke anything as part of the transition, and it expects the last 90-day certificate to expire on May 11, 2027.

Two details beyond the headline lifetime matter. First, the period during which a domain authorization can be reused drops from 30 days to 10 days on the same February date, and then to seven hours in 2028. Most subscribers do not need to care about this unless their setup depends on authorization reuse, which some DNS-plugin-heavy or highly parallel renewals do. Second, the 64-day default is explicitly a stepping stone. The 2028 move to 45 days is already scheduled, and the wider CA/Browser Forum has voted to push the maximum public TLS validity down to 47 days. Shorter lifetimes are the direction of travel, not a one-off event.

Why homelabs are the most exposed

Enterprise teams have certificate lifecycle management, whether they like it or not. Homelabs have a certbot container that someone installed from a 2022 tutorial and a cron job that renews on day 60. That arrangement works fine at 90-day lifetimes and starts failing at 64.

The failure mode is arithmetic. An 80-day renewal timer plainly misses a 64-day certificate. Renewing at day 60 still technically works, but it leaves a four-day cushion, and any single failed run (a DNS outage, a down challenge path, a hiccup in the deploy hook) eats the entire margin. Under 90-day certs, a missed run at day 60 still had 30 days of grace. Under 64-day certs, grace becomes a rumor.

The second failure mode is subtler, and it is the one Let's Encrypt keeps warning about. Renewal is only the first half of the job. The certificate has to be installed, the proxy reloaded, and the renewed cert has to actually reach the endpoint users connect to. Plenty of homelabs renew fine and then serve a stale certificate for weeks because the Traefik, Caddy, Nginx Proxy Manager, or mail server never reloaded, or because the deploy hook wrote to a path nothing reads anymore. The shorter the lifetime, the faster that kind of rot surfaces.

The audit list is longer than it looks. It is not just your public website. It is the Nextcloud login, the Jellyfin and Immich front ends, the Proxmox web UI, the TrueNAS web UI, the mail server, the internal dashboards behind Tailscale, the monitoring console, the router or NAS appliance whose certificate renewal was configured once and forgotten. Quiet internal services have a way of being discovered the morning after they expire.

At 90-day lifetimes, a missed renewal was an embarrassment you had 30 days to fix. At 64 days, the same miss is a four-day countdown. Shorter lifetimes do not forgive sloppy automation; they just surface it sooner.

The fixes that actually work

Let's Encrypt's guidance is short. If your renewals are automated and your client supports ARI, you are probably fine. If not, renew at roughly two-thirds of the certificate's lifetime, and grep your cron jobs, wrapper scripts, and runbooks for the hardcoded numbers of the old regime: specifically 83, 80, and 60.

ARI, or ACME Renewal Info, standardized in RFC 9773, is the important one. Instead of each client guessing when to renew from a local number, the certificate authority tells the client when to come back. Certbot supports it in current versions, though the distro-packaged certbot on a long-term-support server can lag upstream, so check the actual version running, not the version you remember installing. Clients without ARI should be scheduled to attempt renewal daily and decide from the certificate's own dates, with two-thirds of 64 days landing around day 43 rather than the familiar day 60.

The old advice to "just run it weekly" deserves a second look too. One scheduled attempt per day is not a renewal strategy when the failure of any single step (validation, transfer, reload) is silent. The practical standard is this: document the full path for each certificate (domain validation, ACME account and client, key and certificate storage, transfer to the correct host or load balancer, service reload, a check against the live endpoint, and alerts for each failure), and then test the full path against staging, which has been serving 64-day certificates since October 14. A dry run that skips the deploy hook has not tested anything. Break something on purpose: a blocked DNS change, a bad hook path, a failed reload, and confirm an alert reaches a human with time to spare.

There is a broader point here for the self-hosted community. The 90-day era trained everyone to treat certificates as a solved problem: set up certbot once, forget it. The next decade will look more like key rotation at a cloud provider, a routine operational rhythm rather than a setup task. The tooling is largely there: Traefik and Caddy handle ACME natively, acme.sh and lego support modern DNS APIs, and staging gives you a free sandbox to rehearse against. What is missing, in most homelabs, is the inventory: a list of every certificate, which client renews it, which service serves it, and who gets paged when it does not.

February 2027 is four months away. That is either plenty of time or barely enough, depending on how many services you have quietly been serving from that rack in the closet. Staging is live. The clock has started.