Let's Encrypt Is Cutting Certificates to 64 Days: What Your Homelab Has to Do

Let's Encrypt has announced the first reduction to its default certificate lifetime in the certificate authority's history. Starting February 10, 2027, every certificate issued or renewed through the default ACME profile will be valid for 64 days instead of 90. The last 90-day certificate should expire on May 11, 2027, and the organization says it will not revoke valid certificates to force the transition. Staging flips to 64-day issuance on October 14, 2026, which means operators can start testing against the new lifetime next week.

This is not a surprise, and it is not the end of the road. Shorter six-day certificates are already available through the shortlived profile, 45-day certificates through the tlsserver profile, and Let's Encrypt plans to make 45 days the default on February 16, 2028. The February 2027 change is a deliberate stepping stone: 64 days is short enough to matter, long enough that most existing automation survives it.

The full timeline

Here are the dates that matter:

October 14, 2026: staging starts issuing 64-day certificates. This is the safe place to test renewal automation before production changes.

February 10, 2027: production default drops from 90 days to 64 days for all certificates issued or renewed from that date. On the same day, the domain authorization reuse period shrinks from 30 days to 10 days.

May 11, 2027: the last legacy 90-day certificate expires. From this point on, the 90-day era is over.

February 16, 2028: the default drops again to 45 days, and authorization reuse shrinks to seven hours.

March 2029: the industry ceiling arrives. The CA/Browser Forum's Ballot SC-081 caps maximum certificate lifetimes at 47 days, down from 398 days. Let's Encrypt's 90-day certificates were already inside every intermediate step, which is why it is walking down voluntarily rather than waiting to be forced.

Why shorter is genuinely better

Certificate revocation is broken. It has been broken for years. Browsers check revocation lists inconsistently, OCSP responders add latency and privacy problems, and a revoked certificate often keeps working in practice. Security researcher Scott Helme has argued this point for the better part of a decade: when revocation cannot be relied on, the only dependable way to limit the damage of a compromised private key or a misissued certificate is to make sure the certificate expires quickly.

When Let's Encrypt launched in 2016, commercial certificates routinely lasted one to three years, and a stolen key could stay useful for that entire span. The 90-day default cut the worst-case exposure window by an order of magnitude, and it had a second purpose: 90 days is short enough that manual renewal becomes painful, which pushes the ecosystem toward automation. The bet paid off, and automated renewal is now the norm across the web.

Sixty-four days continues both trends. It shrinks the exposure window by another 29 percent, and it raises the bar for automation: two extra renewals per year are exactly the kind of thing that turns a holiday weekend into an outage for anyone still renewing by hand.

What actually changes in your homelab

For most self-hosters, the honest answer is: probably nothing. But "probably" is doing a lot of work in that sentence, and the exception cases are exactly the setups that fail silently. Here is how to check which camp you are in.

If your ACME client supports ARI, you are done. ACME Renewal Info lets Let's Encrypt tell your client when to renew, instead of your client guessing from the certificate's expiry date. With ARI, the lifetime of the certificate simply does not matter to your configuration. Caddy handles renewals automatically with its own scheduling, and modern clients like recent certbot, lego, and acme.sh versions support ARI. If ARI is available, enable it. This is the single highest-value action on the list.

If you renew on a fixed schedule, review it. The common pattern for 90-day certificates is a cron job or systemd timer that renews at a fixed age, often around 60 days. Let's Encrypt chose 64 days deliberately: a 60-day fixed renewal still catches a 64-day certificate before it expires, but with almost no margin left. The safer fix, and the one the organization recommends, is to renew at roughly two-thirds of the certificate's lifetime instead of a fixed number of days. Two-thirds of 64 days is about 42 or 43 days. Grep your cron jobs and scripts for hardcoded numbers like 83, 80, or 60.

A 60-day fixed renewal still catches a 64-day certificate, but with almost no margin left. Renew at two-thirds of the certificate's lifetime instead.

Certbot's default timer is fine. The standard systemd timer runs twice daily and renews any certificate with less than 30 days remaining, which triggers around day 34 of a 64-day certificate. If you never customized it, nothing to do here.

Watch the authorization reuse change. The shrink from 30 days to 10 days for reusing a completed domain authorization, and the further drop to seven hours in 2028, mostly affects pipelines that depend on skipping re-validation. Most homelab setups re-validate on every renewal anyway, so this will pass unnoticed. If you have scripts that assume a previous authorization is still fresh, February 2027 is when that assumption breaks.

Rate limits, ACME endpoints, and issuance chains are not changing. That part of the announcement is deliberately boring, and it is good news: this is a lifetime change, not an API change.

The 45-day horizon, and what it really means

Treat 64 days as a training exercise, because 45-day defaults arrive a year later and the industry ceiling of 47 days lands in 2029. At 45 days, a fixed 60-day renewal schedule does not just cut it close, it fails outright, and certificates start expiring for people who skipped the first round of cleanup. Let's Encrypt is telling you this now precisely so the February 2027 step is a gentle warning rather than an emergency.

There is also a subtle message in the staging date. October 14, 2026 is next week: point a test client at staging, watch your automation renew a 64-day certificate, and confirm nothing depends on the number 90. That is an afternoon's work, and it buys certainty for a change that touches every HTTPS service you run.

The broader trend is unmistakable. The people who automated properly in 2016 will not notice 2027; the people who hardcoded a fixed number in a cron job have about four months to fix it. Start with ARI, fall back to the two-thirds rule, and test in staging. The rest is patience.