Let's Encrypt's 64-day certificates will squeeze renewal buffers from February 2027

The change

Let's Encrypt will shorten certificate validity from 90 days to 64 days beginning in February 2027, according to a post on dev.to. At first glance the change looks minor — the same renewal rhythm, just with a smaller number attached. The post's argument is that it isn't minor: a large amount of renewal automation encodes assumptions about the 90-day cycle, and those assumptions quietly stop holding once the cycle compresses.

Why a shorter lifetime shrinks the safety margin

Certbot's default, as the post describes it, is to attempt renewal 30 days before a certificate expires. On a 90-day certificate that puts the attempt around day 60 of the cycle, leaving roughly a month of valid certificate to diagnose and retry if anything fails.

Carry the same 30-day window onto a 64-day certificate and the renewal attempt lands on day 34. The margin left over if something goes wrong collapses to about four days. The dev.to author expects most operators will move to a 20-day window instead, which shifts renewal to day 44 — workable, but noticeably tighter than the old schedule.

Hardcoded day counts are the fragile part

The post singles out a widely copied shell-script pattern: parse the certificate's expiry date with openssl, compare it against a hardcoded number of days, and invoke certbot renew once the remaining time falls below that number. The pattern itself survives the change; what goes stale is the number, which was tuned against a 90-day rhythm, along with the cron schedule around it, which may now fire too rarely relative to the tighter window.

The recommended fix is to stop treating day counts as constants. Read the certificate's start and end dates, compute its real lifetime, and trigger renewal when a fixed fraction of that lifetime remains — the post's example renews once about 30 percent of the lifetime is left. Because the threshold is derived from the certificate itself rather than a fixed number, the same check behaves sensibly on a 90-day, 64-day, or hypothetical 45-day certificate, a scenario the author raises as plausible.

Monitoring needs the same audit

Expiry monitoring usually follows the same shape: a static "days until expiry" threshold that raises an alarm. A 30-day threshold made sense against 90-day certificates, firing roughly once per cycle. Against a 64-day certificate paired with a 20-day renewal window, the post suggests alerting at around 15 days instead — late enough to avoid noise, early enough to notice a failed renewal and fix it before the certificate actually lapses. The warning here is that these numbers tend to sit in monitoring configuration that nobody revisits.

Why it matters

The post's core observation is that "90 days" was never the number that mattered; the slack it bought for absorbing failures was. Renewal scripts and alerts that hardcode the old arithmetic will keep running and keep reporting success while the margin they were designed around disappears. Before the shorter certificates arrive, operators should inventory every place a day count is baked in — renewal scripts, cron schedules, alert thresholds — and either recalculate the values or switch to lifetime-relative checks that scale with whatever validity period comes next.