64-day certificates are coming — and the dangerous change is the config edit you'd make in response
Let's Encrypt is shortening its default certificate from 90 days to 64, starting 10 February 2027 (announced 7 Oct; staging is already issuing them). The takes will be loud — "automate your renewals or die." For most of us running a single Traefik or Coolify box, that's overblown: nothing breaks. But there's one genuinely counterintuitive trap, and it's the "fix" you'd reach for first. So I read Traefik's renewal code to be sure.
What's changing
From the Let's Encrypt announcement: production certs default to 64 days on 10 Feb 2027 (then 45 days sometime in 2028), the last 90-day cert should expire around 11 May 2027, and — importantly — "we will not revoke valid certificates as part of this process." ACME endpoints, chains and rate limits are unchanged. One quieter change to note: authorization reuse drops from 30 days to 10 now (and to 7 hours in 2028), which matters for DNS-01 and manual flows. LE's own advice is sensible and un-paniced: ARI-capable clients "should be set," and any hard-coded renewal schedule should fire at roughly two-thirds of the certificate's lifetime.
Does the default box actually break? No.
I went into Traefik's source (master branch) to check the renewal logic, and the reassuring news is that a stock setup keeps working. Traefik's CertificatesDuration defaults to 90 days, and under that default it starts renewing when under 30 days remain, checked every 24h. On a 64-day certificate, renewing with 30 days left still leaves a 34-day margin — comfortably more than half the lifetime. Even when the default drops to 45-day certs in 2028, a 30-day trigger leaves 15 days. The docs match: "By default, Traefik manages 90-day certificates and starts renewing them 30 days before their expiry." So if you've never touched the ACME config, you can close this tab.
The trap: "helpfully" setting the duration to 64
Here's the counterintuitive part, and it's exactly the well-meaning edit someone makes after reading the news. You think: "certs are 64 days now, let me tell Traefik." So you set certificatesDuration to 1536 (64 days). But that setting doesn't just inform Traefik of the lifetime — it drives the renewal window. Reading the code: with a configured duration of ≥30 days, Traefik only renews when under 10 days remain (checked every 12h), not 30. So the "accurate" edit silently shrinks your safety margin from 34 days to 10. The honest move is to leave certificatesDuration alone — the default 90-day assumption gives you a bigger renewal buffer, not a wrong one. Telling the truth about the lifetime makes things worse here, which is the kind of footgun worth a whole post.
The dangerous change isn't Let's Encrypt's. It's the tidy one-line config edit you'd make in response to it. On a default box, do nothing; the margin is already fine.
Where you actually should look
The real exposure isn't the managed proxy — it's custom automation:
- Hand-rolled cron /
certbotwrappers with a fixed assumption. Grep your crontabs, deploy scripts and runbooks for hard-coded numbers like83,80or60days. (Modern Certbot ≥4.0.0 already renews at under 1/3 of lifetime, so stock Certbot is fine; it's the wrapper someone wrote in 2019 that isn't.) - DNS-01 and manual issuance, now that authorization reuse fell to 10 days — more frequent certs means more frequent authorizations.
- No alerting on renewal failure. Shorter certs mean a stuck renewal turns into an outage faster. If you don't already alert on "cert expiring in N days," add it; that's the single highest-value thing here.
Honest limits
I read Traefik's master source, not the exact version Coolify pins on my box, so the specific thresholds could differ on yours — check your running version's provider code or, better, run a 64-day staging cert through it. I also couldn't find any ARI / RenewalInfo support in the Traefik source and docs I read; that means "I didn't find it," not "it isn't there." And I'm not going to assert Caddy's renewal threshold from memory — if that's your proxy, read its docs. The dates and the won't-revoke promise are the solid, primary parts; the proxy behavior is my reading of code I didn't run.
The takeaway
64-day certs are a non-event for a default Traefik/Coolify setup — the stock 30-day renewal window has margin to spare. Spend ten minutes doing the opposite of the obvious: don't set certificatesDuration to match, grep your custom renewal scripts for hard-coded day counts, and make sure something alerts you when a renewal fails. Then forget about February.