Testing ACME renewal: 64-day default from February 2027

What changes on February 10, 2027

The announcement is short and clear. From February 10, 2027, all Let's Encrypt subscribers will get certificates with a 64-day lifetime by default unless they have chosen an even shorter profile with 45 or 6 days (Let's Encrypt). Every certificate issued or renewed on or after that date is valid for 64 days, and the CA expects the last 90-day certificate to expire on May 11, 2027 (Let's Encrypt). Existing certificates are not revoked, and rate limits, ACME endpoints and issuance chains remain unchanged (Let's Encrypt).

For context: the 64 days are one CA's setting for its default classic profile, not a general rule. The industry-wide limit comes from the CA/Browser Forum Baseline Requirements: certificates issued on or after March 15, 2027 may be valid for at most 100 days (CA/Browser Forum). Let's Encrypt stays below that and plans its next step: on February 16, 2028, the default profile is set to drop to 45 days (Let's Encrypt). The full roadmap is covered in the article on the 200-day limit and the road beyond; this one is about what to check before February.

The timeline up to the last 90-day certificate

Until the switch is complete, two lifetimes run side by side: certificates renewed up to February 9 are still valid for 90 days, those renewed afterwards for 64. An inventory with many hostnames is mixed in spring 2027; evaluations by remaining validity have to keep both lengths apart. The milestones at a glance:

• October 14, 2026: the staging environment issues 64-day certificates so that subscribers can test (Let's Encrypt).
• February 10, 2027: the default profile in production switches to 64 days, and the authorization reuse period drops from 30 to 10 days (Let's Encrypt).
• March 15, 2027: new certificates may be valid for at most 100 days industry-wide (CA/Browser Forum).
• May 11, 2027: the last 90-day certificate from Let's Encrypt is expected to expire (Let's Encrypt).
• February 16, 2028: the default profile drops to 45 days and authorization reuse to seven hours (Let's Encrypt).
• March 15, 2029: under the Baseline Requirements, domain validation data may be reused for at most 10 days (CA/Browser Forum).

For the test plan, the first two dates matter most: testing in staging now leaves time for fixes until February.

Finding and replacing fixed renewal days

The risk is not the shorter lifetime but every place where the old one is stored as a fixed number. If the renewal point is hard-coded in days, it should be changed to approximately ⅔ of the lifetime (Let's Encrypt). As a search aid, Let's Encrypt names the numbers 83, 80 and 60, which may sit in cron jobs, wrapper scripts and runbooks (Let's Encrypt). The numbers follow from the old lifetime: with 90 days, renewing after 60 days leaves 30, after 80 days 10 and after 83 days 7 days of remaining validity.

With a 64-day certificate this arithmetic breaks. A rule that renews after 80 or 83 days only fires once the certificate has been expired for 16 or 19 days. A 60-day rule leaves 4 days of validity, hardly enough for a second attempt. A rule based on remaining days can cause trouble too: renewing whenever fewer than 70 days are left renews a 64-day certificate on every run. Without ARI, each of those orders counts against the limit of 5 certificates per exact set of identifiers every 7 days (Let's Encrypt); after that the CA refuses further certificates for those names for the time being.

The search is quick; the output shows typical hits as an example:

The search finds candidates, not verdicts: a 60 can just as well be a timeout in seconds. Every hit needs a look, as do load balancer configurations, container entrypoint scripts and wiki pages that people follow by hand. How ACME automation is built and where it typically breaks is described in the article on SSL automation with ACME.

If you keep your own script, derive the date from the certificate instead of from a constant. The example below for GNU date reads the start and end of validity and triggers renewal once two thirds have passed; it works for 90, 64 and 45 days alike:

#!/bin/sh
# Trigger renewal once two thirds of the lifetime have passed.
# Uses the lifetime of the certificate itself, not a fixed number of days.
cert=/etc/ssl/site/fullchain.pem
start=$(date -d "$(openssl x509 -in "$cert" -noout -startdate | cut -d= -f2)" +%s)
end=$(date -d "$(openssl x509 -in "$cert" -noout -enddate | cut -d= -f2)" +%s)
now=$(date +%s)
due=$(( start + (end - start) * 2 / 3 ))
if [ "$now" -ge "$due" ]; then
  exec /usr/local/bin/cert-renew.sh
fi

Testing the switch in staging now

Let's Encrypt explicitly recommends testing in the staging environment before the change takes effect. Staging is a complete ACME environment with its own address, https://acme-staging-v02.api.letsencrypt.org/directory, and its own accounts: a production account does not work there, a separate one is required, and the certificates come from a test hierarchy that browsers do not trust.

A second reason for staging is the limits. Failed attempts in production cost allowance: production permits 5 authorization failures per identifier, account and hour (Let's Encrypt), staging 200 (Let's Encrypt). New orders per account are limited to 300 every three hours in production (Let's Encrypt) and to 1500 in staging (Let's Encrypt). Reconfiguring a client several times until renewal runs cleanly is better done there.

1. Choose a test name. Use a hostname or test server that no visitor calls.
2. Point the client at staging. Swap the directory URL, let the client create a separate account and change nothing else, so the same flow as in production runs, hooks included.
3. Obtain a certificate and read its lifetime. Print the start and end of validity with openssl x509; there must be 64 days between them.
4. Read the next renewal date. The client or your own script should want to renew around day 43, not at day 60 or 80. With ARI, the suggested window shows the date.
5. Force a renewal. Trigger an unscheduled renewal and check that validation runs again and all follow-up steps fire: reload, copy to other servers, restart of other services.
6. Switch back and record it. Directory URL back to production, result documented with a date, so the test need not be repeated in February.

The first command shows that the staging directory offers the profiles and the ARI resource (retrieved on October 14, 2026), the second prints the validity of an obtained certificate (example output):

If you want to test the 2028 state right away, choose the tlsserver profile in staging. It issues certificates with a 45-day lifetime (Let's Encrypt) and limits authorization reuse to seven hours (Let's Encrypt). That lets you try both future tightenings in one pass, provided the client supports selecting a profile.

ARI: letting the CA choose the moment

The announcement names a simple case: if renewals are automated and the client supports ACME Renewal Information, you should be all set, because ARI lets the CA tell the client when to renew. The mechanism is standardized as RFC 9773 (IETF). For each certificate, the client fetches a suggested time window and renews within it. If the lifetime shrinks, the window moves along without anyone having to change a number.

Let's Encrypt recommends checking renewal information for each certificate at least twice a day (Let's Encrypt). As a backstop, should ARI not take effect, certificates should be renewed when a third of their total lifetime is left (Let's Encrypt). A useful side effect: renewals coordinated by ARI are exempt from all rate limits. How ARI interacts with monitoring at very short lifetimes is covered in the article on 6-day certificates and coupled alert thresholds.

Whether ARI is actually used shows in the client's logs: requests to the renewalInfo address from the directory must appear regularly, not only at issuance. If they are missing, the client works with a rule of its own, and the section on fixed renewal days applies.

Authorization: from 30 to 10 days

The second change on February 10 is less visible. Once an ACME account has proven control over a name, it may reuse that authorization for further orders. This period drops from 30 to 10 days (Let's Encrypt) and to seven hours in 2028 (Let's Encrypt). Let's Encrypt explains this with the tightening of the Baseline Requirements, under which validation data may be reused for at most 10 days from March 15, 2029 (CA/Browser Forum), and with dropping the CAA recheck that otherwise becomes due once validation data is more than 7 hours old (Let's Encrypt).

Unless the ACME client was specifically designed to rely on reuse, Let's Encrypt says no changes are needed. With renewal around day 43, the validation from the previous renewal has long expired anyway, so the client validates afresh every time. Affected are flows that use one validation for several certificates or servers, often without anyone being aware of it:

• Manual DNS-01: the TXT record is set by hand once, and further certificates for the same name are obtained over the following weeks.
• Several servers, one name: nodes behind a load balancer each order their own certificate, but only one of them validated.
• Two key types: RSA and ECDSA certificates are ordered separately, and the second order relies on the validation of the first.
• Separate pipeline steps: validation happens at deploy time, issuance days later in another job.

How long an authorization stays valid is in the expires field of the authorization object. Staging lets you check that every server and every key type completes its own validation; where the DNS record is still set by hand, now is the time to automate it.

After renewal: reload, distribution, chain

Let's Encrypt calls the change an opportunity to automate reload and deployment and to add alerting for renewal failures. For 2028, Let's Encrypt expects renewal around day 30 instead of day 60 and therefore double the number of renewal requests per day (Let's Encrypt). Every manual step after renewal becomes due correspondingly more often, and that is where a typical gap sits: the new certificate is on disk while the old one is still served.

Whether the renewal reaches visitors only shows from the outside. The comparison is simple: serial number and expiry of the certificate the server delivers versus the file the client wrote last. In the example output below, the new certificate is already on disk while the old one is still served, the reload is missing:

Adjusting monitoring to the new lifetime

In XICTRAQ®, the outside check is done by SSL monitoring as part of uptime monitoring. It checks the certificate actually served every six hours on paid plans, daily on the Free plan, and keeps a history per website. When the valid-until date changes, the history records a renewal, and the SSL tab shows the certificate's total lifetime. From February you can therefore see per hostname when the first 64-day certificate went live. Hostnames with their own certificate, such as app and api, are each added as a website of their own.

For alerts, the lead time is what counts. It applies to all websites of an account, defaults to 14 days and can be set between 1 and 90 days under Settings, Notifications. Once remaining validity drops below that threshold, a warning goes out; each further stage at 7, 3 and 1 day notifies again, from 3 days or fewer as a critical alert. After a successful renewal the alert resolves itself. The details are in the SSL monitoring documentation.

The 14-day default suits 64 days, and the arithmetic shows why. Renewed at two thirds, a 64-day certificate has about 21 days left at that point. If renewal fails, a little over seven days pass before the warning arrives, and 14 days remain to fix it. Anyone who raised the lead time to 30 days for 90-day certificates will, from February, get a warning for every 64-day certificate before the automation even wants to renew. It resolves after the renewal, but produces notifications without cause in every cycle.

All values in the table are calculated from the lifetime, not measured. With 45 days the buffer shrinks to one day, and a renewal that merely needs one retry the next day already triggers the warning. By 2028 at the latest it is therefore worth lowering the lead time to about 10 days.

The certificate check sees the result, not the run, and in the example only speaks up a little over a week after the missed renewal. A heartbeat monitor on the renewal job speaks up earlier: the script calls its own ping URL after each successful run, and if the call is overdue beyond the expected interval, XICTRAQ® raises an alert. With two runs a day, an interval of twelve hours with some tolerance fits; more in the article on heartbeat monitoring for cron jobs.

# /etc/cron.d/certificates
# Twice a day at an odd minute, output to a log, ping only on success
17 4,16 * * * root /usr/local/bin/renew-check.sh >>/var/log/cert-renew.log 2>&1 && curl -fsS -m 10 https://api.xictraq.com/api/heartbeat/<slug>/ping >/dev/null

An expired certificate does not necessarily hit the whole website. If it only expires on a subdomain for images, scripts or an API, the home page stays reachable but buttons stop responding. In visitor analytics this shows up as a cluster of rage and dead clicks; a browser check, by contrast, walks through a purchase across all involved hostnames, for example when redeeming a discount code at checkout.

The test plan up to February 2027

The plan should be done by February 10, 2027; the order follows the risk: first find what breaks, then test, then monitor.

• Take inventory: every hostname with a Let's Encrypt certificate, with client, profile, renewal rule and follow-up steps.
• Search for fixed days: scan cron jobs, scripts and runbooks for 83, 80 and 60 and assess every hit (Let's Encrypt).
• Change the rule: enable ARI where the client supports it, otherwise switch to two thirds of the lifetime.
• Staging test: renew one hostname against staging and check the 64-day lifetime and the next renewal date.
• Check reuse: find flows in which one validation has to cover several servers or key types.
• Automate follow-up steps: reload, distribution to other systems and alerting on failure.
• Adjust monitoring: every hostname as its own website, a suitable lead time, heartbeat on the renewal job.
• Measure again after February 10: confirm the first 64-day certificate in the history for every hostname and watch the first renewal in the new rhythm at the end of March.
• Finish by May 11: by then, Let's Encrypt expects every 90-day certificate to have run out; one in the history that was not replaced points to a renewal that no longer runs.

Check renewal before the calendar does

For a well-automated environment, the switch to 64 days is a non-event, and that is exactly what can be proven in staging now instead of assumed. The free SSL check gives a quick snapshot; continuous monitoring with history, alert stages and a heartbeat for the renewal job can be set up after registering.