From February 10, 2027, Let's Encrypt issues 64-day certificates by default, and its staging environment already switched on October 14. Automated renewals keep working, but scripts with a hardcoded 60, 80 or 83 days need a look.
What Changes, and When
Let's Encrypt announced on October 7 that any certificate it issues or renews on or after February 10, 2027 will be valid for 64 days instead of 90. Nothing is revoked as part of the change. Certificates issued before that date keep their 90 days, and Let's Encrypt expects the last of them to expire on May 11, 2027.
The staging environment started issuing 64-day certificates on October 14, 2026, so the new lifetime can be tested today without touching production.
Shorter lifetimes are already available for anyone who wants them, 45 days or 6 days through certificate profiles. The 64-day default is a step on the way to a 45-day default in 2028.
Who Needs to Do Anything
If your ACME client supports ACME Renewal Info (ARI), Let's Encrypt tells it when to renew, and the shorter lifetime needs no work. Clients that renew a fixed number of days before expiry, such as certbot with its default of 30 days, also keep working, because they count back from the expiry date.
The setups that break are the ones that count forward from the issue date. Let's Encrypt suggests grepping cron jobs, wrapper scripts and runbooks for numbers like 83, 80 or 60. A job that renews 80 days after issuance would now run 16 days after the certificate expired. One that renews at day 60 leaves a four-day margin, which is gone the first time a renewal fails over a weekend.
The recommended fix is to renew at about two thirds of the certificate's lifetime, which for 64 days is roughly day 43. These commands find the usual suspects and show when a certificate actually expires.
grep -rnE "\b(60|80|83)\b" /etc/cron* /etc/systemd/system 2>/dev/null | grep -iE "cert|acme|renew"
openssl x509 -in /etc/letsencrypt/live/example.com/cert.pem -noout -enddate
Authorization Reuse Gets Shorter Too
A second change is easy to miss. Today a validated domain can be reused for 30 days before Let's Encrypt asks for a new challenge. That window will drop to 10 days, and in 2028 to seven hours. Let's Encrypt says no changes are needed unless your client relies on reusing an earlier validation.
What Stays the Same
Rate limits are not affected. ACME endpoints and certificate chains do not change either, so no client needs a new URL.
What We Would Check First
Run one renewal against staging with the same client you use in production, then read the expiry date on the certificate it returns. Make sure whatever serves the certificate reloads it on its own after renewal, and that a failed renewal raises an alert somewhere a person will see it. Let's Encrypt recommends automating both.
If you are also weighing other free certificate authorities, our look at whether your ACME client works with Cloudflare's new free CA covers the same clients from a different angle. Certificate automation across a fleet is part of our server management work.
Sources: Let's Encrypt, 64-day certificates
Or read how we handle it in Servers Management.
Related News
Ubuntu 26.10 Removes SysV Init Script Support. Check Yours
Ubuntu 26.10 shipped on October 15 with systemd 261.3, which no longer runs old SysV init scripts. It also completes the move to Rust coreutils and changes several server defaults, so it is worth a read before the next LTS.
Server & DevOpsKubernetes 1.35 Is the Last Version That Runs containerd 1.x and Most Clusters Have Not Noticed
Kubernetes 1.35, released December 17, 2025, is the last minor release whose runtime support still includes a containerd 1.x version. To upgrade beyond it, every node has to move to containerd 2.x first, and containerd 1.7 itself reaches end of support in September 2026. The trap is not a single date: it is the upgrade path, and most clusters have not noticed because nothing is broken yet.
Server & DevOpsGitHub Will Stop Running Your Jobs When Your Self-Hosted Runners Fall Behind
GitHub is enforcing a minimum self-hosted runner version (2.329.0) plus a rule that runners must take updates within 30 days of release, or they stop running jobs. Full enforcement lands 2026-07-31 for Enterprise Cloud with Data Residency and 2026-09-25 for Enterprise Cloud. GitHub-hosted runners are unaffected.