Let's Encrypt's 64-Day Certificates Are Live in Staging — Your Renewal Automation Has 4 Months to Prove Itself

Two events, 48 hours apart, just redrew the calendar every renewal script on your fleet quietly depends on. On October 12, Let's Encrypt's production ACME API suffered an issuance disruption that third-party trackers logged at 5 hours 57 minutes, from 17:38 to 23:36 UTC. On October 14, Let's Encrypt's staging environment started issuing 64-day certificates instead of 90-day ones, the rehearsal window for a production cutover coming February 10, 2027.

Read together, the two events are a before-and-after of the same lesson. Lifetimes are shrinking on a fixed schedule, and issuance itself is a network dependency with its own incident history — not a pure function of local cron correctness. If your renewal automation has only ever been exercised against 90-day certs and a healthy CA, the next four months are when it gets to prove itself. February turns the tested path into the only path.

One note on where this post sits: two weeks ago we published a four-step cert-manager audit for the same countdown. If you have not run that audit, run it first. This post is the sequel — what to do now that the staging rehearsal is live and the CA has just demonstrated the failure mode.

The 4-month proof plan​

If you run ACME renewals for anything — tenant custom domains, ingress certs, internal services — here is the whole post in five bullets. The sections below unpack each one.

1. Grep for hardcoded renewal offsets this week. Any 60, 80, or 83 in a cron job, wrapper script, or runbook that means "days into a 90-day cert" is now a bug with a February trigger date.
2. Move scheduling to ARI, or to a lifetime-relative rule. If your client speaks ACME Renewal Information, let the CA pick the renewal window. If not, renew at roughly two-thirds of the issued lifetime — never at a fixed day count.
3. Run staging-canary renewals against the new 64-day staging certs. Point a staging issuer at Let's Encrypt staging, force a renewal, and watch a full cycle complete on the shorter lifetime before production moves.
4. Design retries for a multi-hour CA outage, and alert on renewal failure. The October 12 disruption is the shape of the failure: issuance down for hours while your certs keep aging. Retry with backoff across it, and page on failed renewal attempts, not just on expiry.
5. Line up a second ACME CA for anything that cannot wait. Wildcard and tenant-facing issuance should have a fallback CA configured before February, not researched during an outage.

The shrinking schedule, in one table​

Let's Encrypt's October 7 announcement lays out the dates. As Scott Helme notes, this is the first reduction to Let's Encrypt's default lifetime in the CA's history — 90 days has been the norm since before the 2015 public beta.

Two details matter beyond the headline number. First, no valid certificates will be revoked in the transition, and rate limits, ACME endpoints, and issuance chains are unaffected — this is a lifetime change, not a protocol change. Second, the authorization-reuse cut means your client re-proves domain control more often: the 30-day validation cache your DNS-01 flow may silently rely on becomes 10 days in February and 7 hours in 2028.

This is also not just a Let's Encrypt story. The CA/Browser Forum's Ballot SC-081v3, passed in April 2025, phases the maximum validity of all publicly trusted certs from 398 days down to 200 (already in effect since March 2026), then 100 days in March 2027, then 47 days in March 2029 — the full two-schedule version is in the audit post. Let's Encrypt is moving early and faster than the mandate requires. Every CA you might fall back to is walking the same direction.

What actually breaks: the hardcoded 60​

The failure mode is embarrassingly specific, which is why Let's Encrypt named it directly: "Grep for common hardcoded numbers like 83, 80 or 60 in cron jobs, wrapper scripts and runbooks if you're not sure." A renewal offset tuned for 90-day certs degrades in two stages as lifetimes shrink.

The arithmetic is worth seeing once, because it sets every schedule below. Renewing at roughly two-thirds of lifetime — the rule Let's Encrypt recommends when ARI is unavailable — lands here:

Now run the hardcoded version. A script that renews at day 60 against a 64-day cert renews with 4 days of headroom left — one bad weekend plus one CA incident away from serving an expired cert. The same script against a 45-day cert renews 15 days after expiry. It does not degrade; it flips from working to expired-cert-outage with no intermediate warning, because the script's model of the world ("certs live 90 days") is now false.

The good news is that the most common Kubernetes path already follows the lifetime-relative rule. cert-manager renews a Certificate at two-thirds of its lifetime by default, so a 90-day cert enters its renewal window 30 days before expiry — and a 64-day cert will enter it around day 43 with no config change, as long as nobody pinned an absolute renewBefore computed against 90 days. Check for that pin the same way you check cron: renewBefore values chosen as "30 days because certs last 90" deserve the same grep.

ARI: let the CA schedule you​

ACME Renewal Information, published as RFC 9773 in September 2025, inverts the scheduling responsibility: instead of your client guessing when to renew, it asks the CA for a suggested renewal window for each certificate and renews inside it. ARI was conceived after the January 2022 incident that forced renewal of roughly two million certificates — exactly the scenario where every client renewing on its own fixed schedule stampedes the same endpoint. With ARI, Let's Encrypt can spread load, pull renewals forward ahead of a planned event, and — the part that matters for this post — tell your client the right window for whatever lifetime it just issued, without your client needing to know the schedule changed.

Let's Encrypt's guidance is blunt: "If your renewals are automated and your client supports ACME Renewal Info (ARI), you should be all set." The operative word is if. Client support is the actual work item, and on Kubernetes it has a concrete answer with a version number attached: cert-manager added ARI support in v1.21 behind the ACMEUseARI feature gate, which is alpha and defaults to off. So the cert-manager upgrade checklist is two lines: run v1.21 or later, and explicitly enable the gate on the controller. Without the gate, cert-manager falls back to its own computed renewal time — which, per the previous section, is still the correct two-thirds rule, just without the CA's guidance during exceptional events.

For anything not on cert-manager — certbot cron jobs, Caddy, Traefik, bespoke ACME wrappers — the question to answer before February is one sentence per client: does it implement ARI, and if not, does it renew lifetime-relative? Anything answering "no" twice goes on the remediation list next to the hardcoded 60s. (For the full mechanics of the renewalInfo exchange — suggested windows, Retry-After, why the CA wants to stagger you — see the audit post's ARI section.)

Prove it in staging before February​

The staging cutover is the gift in this timeline: a four-month window where you can watch your automation handle shorter lifetimes with zero production risk. Let's Encrypt's recommendation is one line — test in staging before the change takes effect in production — and the procedure for a Kubernetes fleet is mechanical:

1. Create (or confirm) a staging ClusterIssuer pointing at https://acme-staging-v02.api.letsencrypt.org/directory, alongside your production issuer. Never aim the rehearsal at production; staging exists so the rehearsal is free.
2. Issue a canary Certificate from the staging issuer for a non-production hostname and confirm it comes back with a 64-day validity period.
3. Force an early renewal of the canary (cmctl renew or annotate to trigger re-issuance) and verify the renewed cert deploys, reloads, and serves — the full path, not just issuance.
4. Leave the canary in place and watch one natural renewal cycle complete inside the shorter window, with your renewal-failure alerting armed so you see the signal path work too.

Step 3 is the one teams skip and the one that catches the real bugs: issuance succeeding while the reload hook, secret propagation, or gateway pickup silently assumes the old cadence. A canary that completes steps 2 through 4 against 64-day staging certs is the receipt that your February cutover is a non-event. Anything that fails there would have failed in production, on a cert your tenants' browsers actually check.

The October 12 lesson: the CA is a dependency with incidents​

Now the second event. On October 12, Let's Encrypt's status history records an issuance disruption affecting production, which incident trackers logged as 5 hours 57 minutes against acme-v02.api.letsencrypt.org. Issuance — new certs and renewals alike — was disrupted for most of an evening while every outstanding cert kept aging toward expiry.

Note what this failure is not: it is not your cron failing, your DNS-01 hook misbehaving, or your solver pod crashing. It is the CA endpoint itself being unavailable, which no amount of local correctness routes around. As headroom shrinks from 30 days to 21 to 15, the margin that absorbs "the CA was down for six hours on the night my renewal was due" gets thinner — not catastrophically, but directionally, and 6-hour outages are not the ceiling of what a dependency can do.

Three defenses, in increasing order of commitment:

• Retry with backoff that spans hours, not minutes. A renewal loop that tries three times and gives up for 24 hours can miss its entire headroom if the outage lands wrong. Renewal attempts should retry with backoff across a multi-hour window and keep the last-known-good cert serving meanwhile — which is the default posture if you renew early, and a fire drill if you renew at day 60 of 64.
• Alert on renewal failure, not just on expiry. Expiry alerting is the smoke detector; renewal-failure alerting is the stove timer. cert-manager exposes per-certificate readiness and renewal status you can alert on; cron-based flows should page when the renewal command exits nonzero, with the cert's remaining lifetime attached so the responder knows the actual urgency.
• Configure a second ACME CA for issuance that cannot wait. ZeroSSL, Buypass, and Google's Public CA all speak ACME (ZeroSSL and Google require EAB credentials to enroll), so a fallback issuer is usually a second ClusterIssuer plus a documented switchover — or per-certificate issuer selection for wildcards, which cannot fall back to HTTP-01 and therefore concentrate DNS-01 and CA-availability risk in one path. Set this up while issuance works, because "research alternative CAs" is a terrible step to add to an outage runbook mid-incident.

The pre-February checklist​

Four months is generous if you start now and suddenly short if you start in January. The dated version of the proof plan:

• This week: grep cron jobs, wrapper scripts, runbooks, and renewBefore values for 83/80/60-style hardcoded offsets; convert each to ARI or a two-thirds-of-lifetime rule.
• This month: inventory every ACME client for ARI support (cert-manager needs v1.21+ with ACMEUseARI enabled); remediate anything fixed-schedule.
• Before year-end: complete a full staging-canary renewal cycle against 64-day staging certs, including deploy and reload — not just issuance.
• Before year-end: verify renewal retries span multi-hour outages and that renewal-failure alerts reach a human with remaining-lifetime context.
• Before Feb 10, 2027: have a tested second ACME CA available for wildcard and tenant-facing issuance.
• Feb 10, 2027: production default becomes 64 days; authorization reuse drops to 10 days. Watch the first week of natural renewals, then keep the canary — 45 days is already on the calendar for 2028.

Shorter lifetimes are the industry deciding, correctly, that automation is the only acceptable way to hold a certificate. The staging window plus the outage post-mortem is the kindest possible version of that lesson: time to rehearse, and a free example of the failure to rehearse against. Use both.

Bex.co is the open-source, AI-native Render alternative — push a git repo, get a running HTTPS service on machines you own. Star the repo on GitHub or deploy your first app today.