Infrastructure

Infrastructure2026-10-16· By Franz Senn

64-day certificates from February 2027: what Let's Encrypt changes and what your renewal rules can take

On 7 October 2026 Let's Encrypt announced that from 10 February 2027 it will only issue certificates with a lifetime of 64 days, unless you explicitly pick an even shorter profile. The sentence that matters for operations follows right after: automatically renewing clients with ACME Renewal Information (ARI) are fine. Anyone who counts a hard-coded number of days from issuance should move to roughly two thirds of the lifetime.

In our Caddy frontend all 26 responding endpoints serve a Let's Encrypt certificate. (Quelle: Wikimedia Commons, file Let's Encrypt textlogo.svg, public domain, Internet Security Research Group)

The date to test is not 2027. The announcement says the staging environment switches to issuing 64-day certificates on 14 October 2026. For everyone with their own ACME pipeline or a home-built renewal routine, this is the right time for a dry run.

What changes and what stays

The numbers from the announcement, one by one:

From 10 February 2027 all issued and renewed certificates have a 64-day lifetime, unless you choose 45 or 6 days.
By Let's Encrypt's own count, the last 90-day certificate expires on 11 May 2027.
Valid certificates are not revoked for the switch.
The staging environment switches on 14 October 2026.
Authorization reuse drops from 30 to 10 days, and to seven hours in 2028.
The ACME endpoints, the issuance chains and the rate limits stay as they are.

The stated reason for the shorter lifetime is risk reduction: less time with a compromised key, less time in which a mis-issuance is effective. A second reason comes from validation. While reuse periods are long, an issuing party has to re-check the domain's CAA records for older validation material. With a reuse period of seven hours that re-check practically disappears, because it would cost more than the new validation.

Limits from section 6.3.2 of the TLS Baseline Requirements v2.3.1. The SHOULD values sit one day below each limit. (Quelle: CA/Browser Forum, TLS Baseline Requirements v2.3.1, section 6.3.2)

The real template is at the CA/B Forum

Anyone who stops at the Let's Encrypt news may take 64 days for one issuer's decision. Section 6.3.2 of the TLS Baseline Requirements holds the staging behind it: 398 days for issuance before 15 March 2026, 200 days until 15 March 2027, 100 days until 15 March 2029 and 47 days from 15 March 2029. The staging was introduced with ballot SC081, adopted on 11 April 2025 and effective with version 2.1.5 of the requirements on 16 May 2025. We checked this against the published requirements v2.3.1 and compared the table line by line with the text.

One number is likely to circulate in many articles: 460 days. That limit belongs to the Code Signing Baseline Requirements. It does not apply to TLS certificates. The string 460 appears zero times in the TLS requirements document v2.3.1. A runbook that says "maximum 460 days" quotes the rulebook for code signing.

The second staging, which hurts more in practice, concerns the reuse of validation data under section 4.2.1: 398 days, then 200, then 100, and from 15 March 2029 ten days. This curve is exactly what justifies the jump from 30 to 10 days of authorization reuse at Let's Encrypt and the seven hours for 2028.

The bottleneck is the renewal window, not the lifetime

A certificate that expires after 64 days is only as safe as the routine that renews it. ACME clients decide today when to renew. RFC 9773, standardised in June 2025, reverses the direction: the client queries the issuer's renewalInfo and picks a uniformly random time in the suggested window. It says literally that clients must renew at a time of their choosing within the suggested window, and that cron-based clients may need to run more often.

For the common clients we measured, from their documentation, release notes and source, which rule they renew by and whether ARI is already in.

Client	ARI	Renewal rule according to the project	Threshold configurable
Caddy	yes, since v2.8.0 (29 May 2024)	ratio 0.3333 of remaining lifetime, so from 30 days left on 90 days	yes, global and per site
Certbot	yes, since v4.1.0 (10 Jun 2025)	fixed 30 days before expiry before 4.0.0, one third of the lifetime since 4.0.0	yes, renew_before_expiry
lego (library)	yes, since v4.12.0 (2023), on by default since v4.20.2 (2024)	NotAfter minus one third of the lifetime	yes, renew.days
nginx-acme	yes, since v0.4.0 (20 Apr 2026), always on	two thirds of the lifetime, plus two percent jitter	no, no directive documented
acme.sh	yes, per README without opt-in	every 30 days, DEFAULT_RENEW=30	yes, --days
Traefik	no	30 days before expiry for managed 90-day certificates	only via certificatesDuration
HAProxy (from 3.2)	no	expiry less than one twelfth of the lifetime away, otherwise seven days; timer wakes every 12 hours	no
Proxmox VE	no	expired or expiring within 30 days, via pve-daily-update	no, only force
Stalwart	no	renewBefore as a fraction, default R23	yes, four levels

Applying these rules to a 64-day lifetime gives two groups. The ratio-based clients, that is Caddy, Certbot from 4.0, lego, nginx-acme and Stalwart, shrink the buffer proportionally and end up with about 21 days left. Clients with a fixed window keep their 30 days and simply renew earlier, with a shrinking distance to the limit. It gets tight with the rigidly small windows: HAProxy starts renewal at one twelfth of the lifetime, which is 7.5 days on 90 and 5.3 days on 64, and its scheduler only wakes every twelve hours anyway. lua-resty-acme works with a fixed seven days, which is eleven percent of a 64-day lifetime.

Traefik sits between the groups. Its documentation says 30 days before expiry and points to certificatesDuration for other lifetimes, whose default is 2160 hours. If you set that option to the new lifetime, Traefik's own staging table applies and the buffer jumps from 30 to 10 days. An ARI call cannot be found in the release notes of the last 100 Traefik releases, although their go.mod pins lego v5.5.2 and lego has supported ARI since v4.12.0. That is a finding from release notes, dependency list and configuration documentation. There is no vendor statement on it.

Self-check: what our own pipeline shows

On 13 October 2026 we queried every hostname from the Caddy frontend of our homelab domain individually over TLS. 27 names are in the configuration, 26 answered, one was unreachable from this network. Result: all 26 responding endpoints serve a Let's Encrypt certificate, all with exactly 90 days of validity, remaining lifetime between 36 and 88 days, median 85 days. Expiry distribution: eight names in November 2026, five in December 2026, thirteen in January 2027. 33 stored Let's Encrypt certificates hang on one frontend. Arithmetically, after the switch the same frontend will renew each name about every two months in 2027 instead of about every four.

ARI moves the decision from the client to the issuer. Anyone who only turns the cron interval keeps the problem. (Quelle: RFC 9773, ACME Renewal Information, June 2025)

The second strand is the company pipeline. There, nginx-proxy-manager 2 ships a bundled certbot, measured at version 5.8.0, which is well past the ARI version 4.1.0. All 32 active proxy configurations point to the same certbot-managed wildcard certificate in the ACME store, validity measured 30 September to 29 December 2026. The homelab edge runs Caddy v2.11.4, and the binary contains renewalInfo and suggestedWindow as strings; ARI has been on board since v2.8.0. On both edges there is no cron-based renewal job, no certbot, lego or acme.sh installation in the PATH and no systemd timer related to certificates. Renewal therefore runs entirely ACME-driven, which is the group Let's Encrypt says is fine.

Two findings from the same scan belong on the list anyway. In the folder for manually uploaded certificates on the company pipeline there is a Sectigo wildcard certificate for the same domain, issued on 18 August 2025 and expired on 23 April 2026, next to a manually placed Let's Encrypt certificate expiring on 22 December 2026. No active proxy host points at these files, only disabled configurations and backup files from August and September do. Dead material that surfaces only at the next clean-up, because no browser complains.

The part we could not measure is the internal side. The virtualisation hosts were not reachable over SSH from this network, and the admin ports of internal systems return no TLS handshakes from here. Proxmox sits behind the edge proxy with insecure on node ports 8006 and 8007, so the visible certificate comes from the frontend and was counted above. How long the node certificates run internally and who renews them is open in this measurement. That is exactly where most fleets have a gap, because the browser never complains. A second, quite different pattern is running at our site in Windows Update and certificate rotation 2027: there no ACME client renews anything, an operating system pulls new signing certificates instead.

What operators say in the discussion

The announcement ran on Hacker News in two submissions, the larger with 59 points and 28 comments (thread), the second with 18 points and 10 comments (thread). We summarise the arguments in our own words. They are opinions of individual commenters and no evidence.

Approval comes with two reasons. Shorter lifetimes force operators to automate, which large organisations often have not done, and they limit the damage of stolen keys, because forged certificates show up in transparency logs while a stolen long-lived certificate is hard to revoke. Criticism targets the process: browser vendors steer the CA/B Forum, the benefit of short lifetimes is limited against a hijacked domain registrar, and devices with old interfaces are hard to automate. One practical remark concerns testing: there is supposedly no ACME profile yet to request 64 days early. That is a statement from the thread which we could not confirm; the documented profiles are classic at 90, tlsserver at 45 and shortlived at 6 days. Commenters answer the question why 64 days with "two long months plus slack". We found no explanation from the project.

Separately, SecurityWeek and Help Net Security reported it, with no facts beyond the announcement.

Checklist for the staging test

Record the client and version and compare it with the table above. Certbot 3.x renews at a fixed 30 days, Certbot from 4.1 follows ARI.
Search cron jobs, wrapper scripts and runbooks for the numbers 83, 80 and 60. The announcement recommends this literally, because these numbers mean hard distances from issuance.
Force the 64-day lifetime against the staging environment, which has issued 64 days since 14 October. Check that the client really renews in the new window and not only after expiry.
Prove reload and alerting. A renewal that nobody notices failing is half the job. Alerting on remaining lifetime alone fires twice as often with 64 days of validity.
List internal and self-signed certificates one by one, because no ACME rule covers them. For Proxmox, the 30-day rule via pve-daily-update applies to ACME certificates, and certificates from the PVE's own CA follow a separate branch with 14 days of remaining validity or validity over two years.
Plan monitoring throughput. Shorter lifetimes mean more issuances, more reloads and more measuring points per year.

Limits of this measurement

The announcement sits at letsencrypt.org/2026/10/07/64-day-certs. During the measurement run that page was repeatedly unreachable from our network, so we read the full text from the feed and compared it against the feed again on 16 October. Every date in this post comes from that announcement. The ARI statements on Traefik, HAProxy and Proxmox rest on proven absence in documentation and release notes. There is no statement from the projects, and whether HAProxy processes renewalInfo internally anyway remains unmeasured. The internal and self-signed certificates of the fleet stay open because we cannot reach them from this network.

How we measured

On 13 October 2026 we queried every hostname from the Caddy frontend individually over TLS and read issuer, start and end of validity of the certificate, 27 names, 26 answers. For the company pipeline we read the nginx-proxy-manager configuration, the bundled certbot and the certificate store. We did not run the ACME clients; the table rests on their documentation, release notes and source, with the evidence level shown in the table itself. Statements about what a client cannot do are findings from missing entries, no vendor confirmation.