Let's Encrypt moves to 64 days in February 2027: settings to check in automatic renewal

Sites that renew Let’s Encrypt certificates automatically tend to be treated as "it swaps itself every 90 days, so we can leave it alone." However, if that automatic renewal runs on a hard-coded rule such as "renew once 60 days have passed since issuance," from February 2027 it becomes a setting that does not start renewing until 4 to 5 days before expiry. If a single renewal fails, you would have to notice and fix it within those few days.

In its October 7 blog post, Let’s Encrypt announced that from February 10, 2027 the default certificate validity period will be 64 days. It said that clients that leave renewal to ACME Renewal Info (ARI) need no changes, while those that hard-code renewal as "N days before expiry" should be changed to renew at about two-thirds of the validity period.

This article is for maintainers who use Let’s Encrypt on their own sites or on sites built for clients. It explains what changes and when, how your ACME client decides when to renew, and what to check and fix. The industry-wide background of shorter validity periods and measures for sites renewed by hand are covered in our article on shorter SSL certificate validity periods.

What changes on February 10, 2027

This is the schedule given in the October 7 blog post and in "Decreasing Certificate Lifetimes to 45 Days" from December 2, 2025.

The 64-day validity applies to certificates issued or renewed on or after February 10, 2027. Your existing 90-day certificates will not be revoked; they will be replaced by 64-day certificates at the next renewal. The blog post says rate limits are not affected, and the ACME endpoints and certificate chains do not change.

Clients that have already chosen the tlsserver profile (45 days) or shortlived (about 6 days) are already running on shorter certificates. The profile documentation as of October 2026 still describes classic as "90 days, 30 days," and it is this default profile that switches on February 10, 2027.

The risk is renewal counted in "days since issuance"

Let’s Encrypt's integration guide recommends checking ARI and, as a fallback, "renewing when one-third of the validity period remains." For a 90-day certificate, that is 30 days before expiry, or day 60 after issuance. This "60 days" figure sometimes remains as-is in cron settings and operating procedures.

The October 7 blog post recommends that, if you are unsure, you search cron jobs, wrapper scripts and runbooks for numbers such as 83, 80 and 60. To check on a server, you can search like this, for example.

# cron と自作スクリプトから、証明書の更新に関わりそうな日数の決め打ちを探す
grep -rnE '(^|[^0-9])(60|80|83|89)([^0-9]|$)' /etc/cron* /var/spool/cron* /usr/local/bin 2>/dev/null \
  | grep -iE 'cert|acme|renew|days'

If you find a number, check whether it means "days since issuance" or "days remaining until expiry." A hard-coded count from issuance becomes risky with 64-day certificates, while a hard-coded count of remaining days is generally safe. For example, "renew with 30 days remaining" means renewal on day 34 after issuance for a 64-day certificate and on day 15 even for a 45-day certificate, both before expiry.

The day counts in the diagram were obtained by running the actual code for certbot and acme.sh in the next section, and calculated for lego from the descriptions in its help and migration guide (when there is no ARI guidance).

How your client decides when to renew

Here is how the major ACME clients decide when to renew. We checked each against the changelog and source in its project repository (October 21, 2026).

certbot: 30 days before expiry if you are on an old version

In 4.0.0 (April 2025), certbot changed its default renewal timing from "30 days before expiry" to "one-third remaining (half if the validity period is under 10 days)," and in 4.1.0 it added ARI support. According to the changelog, with ARI, Let’s Encrypt certificates are normally renewed at about two-thirds of the validity period.

The old versions' "30 days before expiry" counts remaining days, so it does not lead to expiry even with 64-day certificates. What to watch for is when renew_before_expiry is written in the renewal configuration file. When there is no ARI response, this value takes precedence over the default, so if a value that is too short (for example, 3 days) remains, renewal will not happen until just before expiry. certbot installed from an OS package may be older than the latest version on PyPI (5.8.0 as of October 21), so check the version with certbot --version.

lego: v4's --days means "days remaining," v5 uses one-third remaining

In lego v4, renew --days means "renew when the certificate has this many days remaining," and the default is 30. With a 64-day certificate, renewal starts on day 34 after issuance. Since v4.20.2, lego checks ARI unless it is disabled. --dynamic, added in v4.25.0, is an option to renew at "one-third remaining (half for short certificates)," and the v4 help stated that it would become the default in lego v5. Even if you write a large value such as --days 60 in cron, it counts remaining days, so it does not lead to expiry, but with 64-day certificates renewal starts immediately every time.

In lego v5, released on May 11, 2026, the renew command was merged into run, --days was renamed to --renew-days, and --dynamic was removed. According to the migration guide, v5 renews at "one-third remaining" if no day count is specified. With a 64-day certificate, that is day 42.7 after issuance, the same as certbot's default. Renewal timing depends on whether you are still using renew --days on v4 or have upgraded to v5, so check lego --version together with the cron arguments.

acme.sh: "60 days after issuance" in 3.1.2 and earlier

acme.sh treats --days as "how many days after issuance to renew." Up to 3.1.2, the default was 60, and it renewed on day 59 after issuance. In 3.1.3, the default became 30, and ARI is also supported. Since 3.1.4, it also caps the renewal time at 1 day before expiry so that a hard-coded day count does not go past expiry.

Two cases need attention. One is servers that are still on 3.1.2 or earlier and have not been updated. The other is when, even on a newer version, --days 60 remains explicitly set in the domain configuration. A comment in the source says that even in newer versions, if the time indicated by ARI is earlier, it follows ARI, but if you use a setting that does not use ARI (NO_ARI=1), a 64-day certificate will not be renewed until 5 days before expiry. Check whether Le_RenewalDays is present in acme.sh --version and in each domain's .conf.

Caddy: no action needed if left at the defaults

certmagic, which Caddy uses, supports ARI (RFC 9773), and even without ARI it renews with one-third remaining. Unless you have made RenewalWindowRatio smaller yourself, no changes are needed.

If your hosting provider or CDN issues certificates automatically, in most cases users cannot change the renewal timing. In that case, check the provider's announcements or contact its support to confirm support for 64-day certificates (the editorial team's suggestion).

We calculated renewal dates with the actual code

On October 21, 2026, in the editorial team's test environment (Linux, OpenSSL 3.0.13), we created self-signed certificates with validity periods of 90, 64 and 45 days and ran certbot's and acme.sh's functions that decide renewal timing as-is.

For certbot, we installed 5.8.0 from PyPI in an isolated virtual environment and passed the certificates to the internal function (_default_renewal_time) that returns the default when there is no ARI. For acme.sh, we extracted the function that calculates renewal timing from the 3.1.6 source, ran it, and compared it with the 3.1.2 formula (issuance time + days − 1 day). The acme.sh issuance date is set to February 10, 2027.

certbot 5.8.0（ARI なしの既定）
  90日: 発行から60.0日目に更新（残り30.0日）
  64日: 発行から42.7日目に更新（残り21.3日）
  45日: 発行から30.0日目に更新（残り15.0日）

acme.sh
  3.1.6 既定(30)  64日: 29日目（残り35日）  45日: 29日目（残り16日）
  3.1.6 --days 60 64日: 59日目（残り5日）   45日: 44日目（残り1日）
  3.1.2 既定(60)  64日: 59日目（残り5日）   45日: 59日目（期限の14日後）

If you reach the 45-day certificates of 2028 with 3.1.2's defaults, the scheduled renewal date falls after expiry. At the 64-day stage in 2027 it still falls before expiry, but the margin is 5 days.

This verification was calculation only; we did not actually issue certificates from Let’s Encrypt. We also did not try issuance in staging or ARI responses, so we have not confirmed the actual renewal dates when ARI is available.

Monitoring thresholds and authorization reuse

An "alert at 30 days remaining" will fire every time

If you monitor the days remaining on certificates, revisit the threshold too. With 90-day certificates, the renewal date of clients that renew with one-third remaining (30 days remaining) almost coincided with an "alert at 30 days remaining." With 64-day certificates, certbot's default renewal is at 21.3 days remaining, so even when everything works normally, the alert stays on for about 9 days before every renewal.

An alert that never stops makes it easy to miss a real renewal failure. The editorial team suggests either setting the threshold below one-third of the validity period (for example, 10 days remaining, which works for both 64 and 45 days), or detecting that "the certificate has not been replaced with a new one even after the scheduled renewal date" instead of watching days remaining. Let’s Encrypt also recommends having monitoring that notifies you when a renewal does not happen. Basic ways to check certificates are covered in our basic guide to SSL server certificates.

Authorization reuse drops from 30 days to 10 days

On February 10, 2027, the period during which the result of domain ownership validation can be reused (the authorization reuse period) also goes from 30 days to 10 days. The blog post says no changes are needed unless your client is specifically built to rely on reuse.

Operations likely to be affected are those that validate ownership by manually editing DNS TXT records and then reuse that result to issue certificates for another server at a later date. In such operations, validation has to be redone once 10 days have passed. In 2028 the reuse period becomes 7 hours, so review your operations with the aim of eliminating manual validation (the editorial team's suggestion).

Check in staging first

The blog post recommends testing in the staging environment before the switch happens in production. Staging has been issuing 64-day certificates since October 14. Staging certificates are not trusted by browsers, so test with a hostname for verification or in a separate working directory.

certbot's renew --dry-run uses staging, but according to the changelog, --dry-run does not check ARI. It also only confirms that the renewal procedure works; it does not tell you when your production certificate will be renewed. Check the renewal date from your client's version and settings in the table above.

Scope of verification

On October 21, 2026, we reviewed two blog drafts (October 7, 2026 and December 2, 2025) and the rate limit, profile, staging and integration guide documents in the letsencrypt/website repository (GitHub), the changelogs and source of certbot and lego (including the v5 migration guide for lego), the acme.sh tags from 3.0.7 to 3.1.6 and the development source, and the certmagic source (document research). We also used self-signed certificates to run the functions in certbot 5.8.0 and acme.sh 3.1.6 that decide renewal timing (hands-on testing). We have not confirmed issuance from Let’s Encrypt production or staging, ARI responses, --dry-run, the versions of each client in OS packages, or support by hosting providers and CDNs. On October 21, before publication, we also checked the two blog posts on letsencrypt.org and the community announcement (October 14) that staging had begun issuing 64-day certificates.

For an inventory of certificate renewal settings on your own servers or servers you manage for clients, or a review of monitoring, please contact us through development, AI and automation consultations.

References

• 64-Day Certificate Lifetimes Coming Feb 2027（Let’s Encrypt）
• Decreasing Certificate Lifetimes to 45 Days（Let’s Encrypt）
• 64-day certificates on the classic profile in staging（Let’s Encrypt Community）
• Shorter Certificate Lifetimes and Rate Limits（letsencrypt/website）
• Profiles（letsencrypt/website）
• Integration Guide（letsencrypt/website）
• Rate Limits（letsencrypt/website）
• certbot CHANGELOG（certbot/certbot）
• lego CHANGELOG（go-acme/lego）
• lego v5 CLI migration guide (go-acme/lego)
• lego v4 cmd_renew.go (go-acme/lego)
• acme.sh 3.1.6 source (acmesh-official/acme.sh)
• certmagic（caddyserver/certmagic）