Skip to main content
← All articles
self-hosting

64-day certificates are coming — and the dangerous change is the config edit you'd make in response

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 / certbot wrappers with a fixed assumption. Grep your crontabs, deploy scripts and runbooks for hard-coded numbers like 83, 80 or 60 days. (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.

Links

BM
Blue Moose
The moose behind Blue Moose. Full-stack PHP developer — Drupal by day, Symfony by night, tests always.