How to Prepare Your ACME Setup for Let’s Encrypt 64-Day Certificates

Let’s Encrypt announced on October 7 that its default certificates are shrinking, and 64-day certificates will reach every subscriber on February 10, 2027. That sounds distant until you look at what hides in cron files and runbooks: renewal windows hard-coded for 90-day certificates, many written years ago and rarely read since.

Most setups will cope without changes. The ones that will not are those renewing a fixed number of days from issuance, those relying on cached domain validation, and those that nobody watches. Four months is enough time to find them, and the staging environment opens for testing on October 14.

This guide turns the Let’s Encrypt announcement into a work plan: the dates, a search for fragile renewal settings, the arithmetic behind the new renewal point, notes for Certbot and cert-manager, the validation-reuse change that touches DNS challenges, and the monitoring that makes the switch safe. Facts come from that announcement and from client documentation unless a sentence says otherwise.

The Timeline

Valid certificates will not be revoked as part of the change, and rate limits, ACME endpoints and issuance chains are unaffected. Subscribers who want shorter lifetimes sooner can already choose opt-in profiles of 45 days or 6 days. Let’s Encrypt also notes that changes reach staging about a month before each production date, so the October 14 test window follows that pattern.

Step 1: Hunt for Hard-Coded Renewal Windows

Let’s Encrypt asks subscribers to search cron jobs, wrapper scripts and runbooks for hard-coded values such as 83, 80 or 60, and to replace them with a renewal point near two thirds of the lifetime. Those numbers are not arbitrary. They are what a 90-day habit looks like: renew a week early, ten days early, or two thirds of the way through.

sudo grep -rnE "\b(83|80|60)\b" /etc/cron* /etc/systemd/system /usr/local/bin /opt 2>/dev/null \
  | grep -iE "cert|renew|acme"

# In an infrastructure repository
git grep -nE "(certbot|acme|renew)" -- "*.yml" "*.yaml" "*.sh" "*.tf"

Adjust the paths to wherever your scripts live, then read each hit rather than trusting the match. The danger depends on what the number means, and the arithmetic cuts differently for each reading.

• If the number counts days since issuance, a renewal at day 80 or 83 now lands after a 64-day certificate has already expired. A renewal at day 60 leaves only four days of margin.
• If the number counts days remaining, a rule such as renew when 60 or 80 days are left fires almost immediately on a fresh certificate and keeps firing, which burns through issuance attempts for no reason.

The target is the two-thirds point. For a 64-day certificate that is about day 43 after issuance, which leaves roughly 21 days before expiry for retries.

Step 2: Know What Your Client Does by Default

Certbot

According to the Certbot documentation, versions 4.0.0 and later renew when less than one third of the lifetime remains, and use one half for certificates of 10 days or less. Older versions use a fixed 30 days. On a 64-day certificate, the one-third rule renews at about day 43 and the fixed rule at day 34. Both are safe, so Certbot users mainly need to confirm their version and that the scheduler is alive.

certbot --version
systemctl list-timers | grep -i certbot
sudo certbot certificates

Per-certificate settings live in /etc/letsencrypt/renewal/CERTNAME.conf. Certbot also offers --preferred-profile and --required-profile flags for choosing an ACME profile, though its documentation lists no profile names. Let’s Encrypt’s December announcement names classic as the default profile and tlsserver as the opt-in one.

cert-manager

The cert-manager documentation says that when neither spec.renewBefore nor spec.renewBeforePercentage is set, renewal happens at two thirds of the certificate’s lifetime, which already matches the new guidance. An absolute renewBefore needs more care. A value of 720h, meaning 30 days, suits a 64-day certificate but would trigger continuous renewal on a 6-day one, because the window is longer than the lifetime. The documentation recommends renewBeforePercentage to avoid exactly that loop, and notes that duration must exceed renewBefore and that durations use hours, so 90 days is written as 2160h.

Everything else

For acme.sh, Caddy, Traefik, lego, win-acme and the rest, read each tool’s documentation for two answers: how it chooses the renewal moment, and whether it supports ACME Renewal Info. I have not verified the current behavior of those clients, so treat that as homework rather than a given.

Step 3: Prefer ARI Where Your Client Supports It

ACME Renewal Info, usually shortened to ARI, lets the certificate authority tell the client when to renew. Let’s Encrypt’s guidance is blunt: if your renewals are automated and your client supports ARI, you should be set, since the server then supplies the timing and your configuration stops mattering. If it does not, fall back to the percentage-based rule from Step 2, and optionally add alerts for renewal failures and automated reload and deployment after each renewal.

Step 4: Test Against Staging From October 14

Staging begins issuing 64-day certificates on October 14. Certbot’s dry run already targets the staging server by default and saves nothing, so it exercises your renewal path without producing a certificate you can inspect. To see the new lifetime itself, request a real staging certificate once the window opens.

sudo certbot certonly --staging --webroot -w /var/www/html \
  -d test.example.com --cert-name staging-check
sudo openssl x509 -noout -dates -in /etc/letsencrypt/live/staging-check/cert.pem
sudo certbot delete --cert-name staging-check

Compare the notBefore and notAfter dates, and expect a 64-day span. Staging certificates are deliberately untrusted, so use a hostname you control and never point production traffic at them. Keep an eye on the Let’s Encrypt community forum, because I could not confirm the exact moment the staging change will go live.

Run your full renewal chain at least once, hooks included. Certbot runs pre and post hooks during a dry run but runs deploy hooks only when you add --run-deploy-hooks, and a deploy hook is usually the step that reloads the web server.

Step 5: Check Your DNS Challenge Automation

Authorization reuse is the quieter half of the announcement. The period during which Let’s Encrypt will accept an earlier successful validation drops from 30 days to 10 days, and in 2028 it shrinks to seven hours. Let’s Encrypt says no changes are needed unless your ACME client was specifically built to rely on validation reuse.

In practice, routine renewals already revalidate, since a certificate renewed around day 43 or day 60 is past either window. The change bites when you issue repeatedly in a short span: adding names to a certificate, rebuilding a server from scratch, or looping on a failing deployment. Each of those used to ride on a recent validation and will increasingly need a fresh challenge. For DNS-01 automation, that makes a few details matter more.

• The API token for your DNS provider must stay valid and scoped correctly, because every issuance depends on it.
• Propagation delays should be configured generously, since a slow provider that merely annoyed you before will now fail more often.
• Challenge records should be cleaned up after each attempt, so failed runs do not leave stale TXT entries behind.

Step 6: Monitor Lifetime, Not Calendar Days

A flat alert threshold that suited 90-day certificates will misbehave on 64-day ones. A warning at 30 days remaining fires at about day 34, nine days before a healthy client would even attempt renewal at day 43, so it would raise a false alarm every cycle. Anchor alerts to the renewal point instead: warn when a certificate has under 14 days left and escalate under 7, a state healthy automation should never reach.

# Prometheus alert expression using the blackbox exporter metric
probe_ssl_earliest_cert_expiry - time() < 86400 * 14

Probing from outside matters here for a reason documented in Certbot’s manual. A failing hook does not directly change the exit code, and renew exits non-zero only when a renewal attempt itself fails. A certificate that renewed on disk but never reached the running server can look healthy to the scheduler. The outside probe sees what clients see. The Grafana write-up shows the alert wired into a full setup.

A One-Page Checklist

1. Inventory every ACME client and its version.
2. Search scripts, cron jobs, systemd units and infrastructure code for hard-coded renewal windows, and replace them with percentage-based timing or ARI.
3. Confirm that each scheduler is running, using systemctl list-timers or your platform’s equivalent.
4. Test against staging after October 14, hooks included.
5. Review DNS challenge automation for token scope, propagation delays and cleanup.
6. Alert from outside at 14 and 7 days remaining.
7. Run the whole list again before February 10, 2027, when the default changes.

Common Questions

Do I need to do anything today?

No. Nothing changes in production until February 10, 2027, certificates issued before then keep their existing lifetime, and the last 90-day certificate is expected to expire on May 11, 2027. Use the time to test, not to rush.

Will my existing certificates be revoked?

No. Let’s Encrypt says valid certificates will not be revoked as part of this change.

Does this change my rate limits?

Let’s Encrypt says rate limits are not affected, and neither are ACME endpoints or issuance chains.

Can I get shorter certificates before 2027?

Yes, through opt-in profiles. Let’s Encrypt cites 45-day and 6-day lifetimes as options, and its December announcement says the tlsserver profile moved to 45-day certificates on May 13, 2026. Shorter lifetimes make automation mistakes show up sooner, so opt in on a service you can afford to break.

Sources

• 64-day certs, Let’s Encrypt (October 7, 2026)
• From 90 to 45 days, Let’s Encrypt (December 2, 2025)
• User guide, Certbot documentation
• Certificate resource, cert-manager documentation
• Certificate expiry alerts with Grafana and Prometheus, Grafana Labs