Let’s Encrypt moves to 64-day certificates on February 10, 2027
From February 2027 Let’s Encrypt issues 64-day certificates, then 45 days in 2028. What changes for automated renewals and ARI, and what to check now.
Let’s Encrypt, the free certificate authority (CA) run by the nonprofit Internet Security Research Group (ISRG), will cut the default lifetime of its TLS certificates from 90 to 64 days starting February 10, 2027. It is the first step towards the 45 days planned for 2028. The news was reported by Ars Technica, SecurityWeek and Help Net Security, based on guidance published by the CA.
This is not a vulnerability and there are no CVEs: it is an operational change affecting anyone who uses Let’s Encrypt certificates on websites, reverse proxies, VPN portals, mail servers or appliances. If your renewals are truly automated you will not need to do anything; if you rely on fixed intervals or manual procedures, you risk expired certificates and unreachable services.
What changes and when
The dates given by the sources:
- October 14, 2026: the Let’s Encrypt staging environment starts issuing 64-day certificates, so you can test your setup before the production switch;
- February 10, 2027: all new or renewed certificates have a 64-day validity;
- May 11, 2027: according to SecurityWeek and Help Net Security, the date on which the last 90-day certificate will expire;
- 2028: default lifetime of 45 days.
According to Help Net Security, Let’s Encrypt will not revoke valid certificates during the transition, and subscribers already using the optional 45-day or 6-day certificates are not affected. SecurityWeek adds that, according to the CA, the change does not affect ACME endpoints, issuance chains or rate limits.
Why shorten the lifetime
The reasoning is the same that led Let’s Encrypt to choose 90 days in 2016, when certificates often lasted one to three years: a short-lived certificate limits the damage if the private key is stolen or the certificate is issued in error. Help Net Security quotes ISRG as saying the reduction lowers the risk of key compromise and mis-issuance; SecurityWeek notes that the move is in line with the CA/Browser Forum Baseline Requirements and makes revocation more effective, and that according to Let’s Encrypt all publicly trusted CAs will make similar changes.
Technical details: ARI and fixed-interval renewals
The key element is ACME Renewal Information (ARI), the ACME protocol extension through which the CA tells the client when to renew. If renewals are automated and the client supports ARI, Let’s Encrypt says nothing needs to change; your ACME client’s documentation will tell you whether ARI is implemented.
The problem lies with hardcoded values: cron jobs, wrapper scripts and runbooks that renew after a fixed number of days. Let’s Encrypt recommends searching for values such as 83, 80 or 60, typical of 90-day certificates, and renewing at about two thirds of the lifetime. With 64 days, by our calculation, that means renewing around day 42–43, roughly three weeks before expiry. A renewal set at 80 or 83 days after issuance, for example, would come after the certificate has already expired.
Authorization reuse: from 30 days to 7 hours
Let’s Encrypt is also shortening the period during which an already completed domain control validation can be reused: from 30 to 10 days (SecurityWeek places this step in 2027) and then to 7 hours in 2028. According to the CA, the change is needed to comply with the reduction in maximum validation reuse periods planned for 2029 and to remove “CAA rechecking”, where part of the validation is repeated if the data is more than 7 hours old. Only ACME clients specifically designed to rely on validation reuse will need changes.
Impact for European and Italian companies
Let’s Encrypt is widely used in Europe too, often in installations set up years ago and never revisited: a hand-configured web server, an appliance with a custom renewal script, an internal service exposed to suppliers. An expired certificate is not an attack, but for users the effect is the same: an unreachable service and errors in clients and in integrations between applications.
For NIS2 entities, service continuity and asset management are part of the risk management obligations: an inventory of certificates, with who renews them and how, belongs to that work. In healthcare, where patient portals and integrations between systems depend on TLS connections, a missed renewal can interrupt essential services. The trend also goes beyond Let’s Encrypt: lifetimes will get shorter for all public CAs, so renewal automation should be treated as a requirement, not an option.
What to do now
- Take an inventory of the Let’s Encrypt certificates in use and of the systems that renew them, including neglected appliances and servers.
- Check whether your ACME client supports ARI; if it does not, update it or review your renewal scripts.
- Search for fixed values (83, 80, 60) in cron jobs, scripts and runbooks and move them to about two thirds of the certificate lifetime.
- Automate certificate reload in the service and its deployment wherever it is needed, not just issuance.
- Set up alerts for failed renewals and expiring certificates.
- From October 14, test your setup against the staging environment, before February 10, 2027.
- Review custom ACME clients that rely on authorization reuse.
How ARXDOME helps
ARX Expose shows your company’s attack surface starting from the declared domains, including the names and certificates exposed on the Internet, with a daily check: a starting point for an inventory of public certificates. On the internal network, ARX Watch also identifies device certificates, with active scanning on approved sites.
Last updated:
