Let’s Encrypt will issue certificates valid for 64 days from February 2027. If renewal is fully automated and tested, little changes. Manual or fragile renewal setups need fixing before then.
Key takeaways
- Ars Technica reports that Let’s Encrypt will cut the lifetime of its free SSL/TLS certificates to 64 days from February 2027.
- A shorter certificate lifetime means renewals happen more often, so any manual step in the process becomes a regular chore and a regular risk.
- Sites that renew through a correctly configured ACME client, such as Certbot or a web server with built-in ACME support, should keep working without intervention.
- Hard-coded renewal schedules, certificates copied between machines by hand and monitoring that only alerts close to expiry are the most likely points of failure.
- The change follows a wider industry move towards shorter certificate lifetimes, and further reductions from other certificate authorities and browser rules are possible.
What is changing with Let’s Encrypt certificates?
Let’s Encrypt is a non-profit certificate authority that issues free domain-validated certificates. These certificates let websites and other services use HTTPS and other TLS-encrypted connections. Every certificate has a fixed validity period. Once it ends, browsers and other clients reject the certificate and show a security warning, or the connection fails.
Ars Technica reports that from February 2027 the certificates Let’s Encrypt issues will be valid for 64 days. Certificates issued before the change will keep their original expiry dates. The change affects new issuances and renewals. Precise details of the rollout, such as the exact day it takes effect or whether different certificate profiles will be treated differently during the transition, are not covered in the material available here. Administrators should check Let’s Encrypt’s own announcements for the definitive timetable.
Why is this in the news now?
The announcement gives operators several months’ notice before the shorter lifetime takes effect. That gap is deliberate. Certificate authorities usually announce changes to issuance policy well ahead of time so that software maintainers, hosting providers and system administrators can audit their renewal processes.
The story is getting attention because Let’s Encrypt issues a very large share of the certificates used on the public web. Any change to its defaults affects hobbyist blogs, small businesses, large hosting platforms and embedded devices alike. Changes from a smaller commercial authority would not reach nearly as many sites.
What background does a newcomer need?
A TLS certificate binds a domain name to a cryptographic public key. A trusted certificate authority signs it after checking that the requester controls the domain. Browsers trust the certificate because they trust the authority that signed it.
Let’s Encrypt has always issued relatively short-lived certificates compared with traditional paid certificates. It did this to push the industry towards automation. Certificates are requested and renewed through the ACME protocol (Automatic Certificate Management Environment), which is now an open standard. An ACME client running on or near the server proves control of the domain, receives the certificate, installs it and repeats the process before the certificate expires.
Common ACME clients include Certbot, acme.sh and lego. Many web servers and reverse proxies, including Caddy and Traefik, have built-in ACME support, and so do many control panels and hosting platforms. In a well-configured setup the administrator never touches a certificate after the first installation.
Short lifetimes matter for security for two main reasons. If a private key is stolen, or a certificate is issued in error, a short lifetime limits how long it can be misused. Certificate revocation is also widely regarded as unreliable in practice, because many clients do not check revocation status consistently. Expiry is the one control that every client enforces.
Who is affected, and how?
The effect depends almost entirely on how renewal currently works.
Fully automated sites. If an ACME client renews certificates on its own and reloads the web server afterwards, the change should go unnoticed. The client will simply renew more often.
Partially automated setups. Some organisations obtain the certificate automatically but then distribute it by hand. They might copy it to a load balancer, a mail server, a network appliance or a content delivery network. Each of these manual steps will now need doing more often, and every repetition is another chance to forget one.
Hard-coded schedules. Some cron jobs or scripts renew on a fixed calendar interval instead of asking the ACME client whether renewal is due. These may have been tuned to the old lifetime. With a shorter lifetime, a fixed interval could let a certificate expire before the next scheduled run.
Devices and appliances. Routers, NAS boxes, printers, IoT equipment and older appliances sometimes have limited or awkward certificate import mechanisms. These are often the hardest systems to adapt.
Hosting customers. People using managed hosting, website builders or platforms that handle certificates for them generally rely on their provider. They should not need to act, but they may want to confirm that the provider is prepared.
Where do informed people disagree?
Most security practitioners support shorter lifetimes in principle. The disagreement is mainly about pace and cost.
Supporters argue that short lifetimes force automation. Automated systems handle expiry more reliably than people, and they make it easier to respond quickly to incidents such as mass revocations or changes in cryptographic algorithms. In their view, any setup that cannot cope with frequent renewal is already fragile and should be fixed regardless.
Critics point to the operational burden on organisations with large, varied or legacy estates. In such environments some systems cannot run an ACME client, and every manual step multiplies with each shortening. Some also worry that more frequent renewals concentrate risk on the certificate authority’s availability. If an authority has an outage at the wrong moment, sites with little remaining validity have less margin.
Another debate concerns monitoring. Shorter lifetimes reduce the window for noticing a failed renewal, so some argue that external expiry monitoring becomes essential and should no longer be optional.
What should you do before February 2027?
The following checklist covers the most common weak points.
- List every certificate. Record where each Let’s Encrypt certificate is issued, where it is installed and which process renews it. Do not forget mail servers, VPN endpoints, internal dashboards and APIs.
- Confirm that renewal is automatic. For each certificate, check that an ACME client renews it without human input. With Certbot,
certbot renew --dry-runtests the renewal path against the staging environment without issuing a real certificate. - Stop hard-coding intervals. Let the ACME client decide when renewal is due. Run it often, for example daily, and let it skip certificates that are not yet close to expiry. Avoid scripts that assume a specific lifetime.
- Automate deployment as well as issuance. Use deploy hooks to reload services and push certificates to every system that needs them. If a device cannot accept automated installation, consider putting a reverse proxy in front of it that can.
- Keep clients up to date. Newer ACME clients support features such as ACME Renewal Information (ARI), which lets the certificate authority suggest when a certificate should be renewed. Updating your client is low effort and makes renewal more robust.
- Monitor expiry independently. Use an external check that alerts you when a certificate’s remaining validity falls below a threshold you choose. Set the threshold so that you have time to act after an alert.
- Test on staging. Let’s Encrypt runs a staging environment for testing without hitting production rate limits. Use it whenever you change renewal configuration.
What should you watch next?
Watch Let’s Encrypt’s official announcements and community forum for the precise rollout details and any changes to related policies. Watch the release notes of your ACME client for updates tied to the change. Watch the CA/Browser Forum, the industry body that sets baseline rules for publicly trusted certificates, because its decisions shape lifetimes across all certificate authorities and not only Let’s Encrypt. Whether lifetimes will be cut further after this step is not settled in the material available here.
Frequently asked questions
When do Let’s Encrypt certificates become 64 days long?
Ars Technica reports that the 64-day lifetime applies from February 2027. Certificates issued before the change keep their original validity period and expire as originally scheduled. The exact day and any transition arrangements should be confirmed through Let’s Encrypt’s official announcements, because those details are not included in the reporting summarised here.
Do I need to do anything if I use Certbot?
Probably very little, provided Certbot runs on a regular schedule and renews certificates successfully today. Run a renewal dry run to confirm the process works, check that your web server reloads after renewal, and make sure Certbot is reasonably up to date. Pay closer attention if you copy certificates to other machines by hand.
Will my website break when the change happens?
Not immediately. Existing certificates keep their current expiry dates. Problems only arise later if a certificate issued under the new rules is not renewed in time. Sites that renew through a working automated process should not notice anything. Manual renewal processes are the main risk.
Why are certificate lifetimes getting shorter?
Shorter lifetimes limit how long a compromised or wrongly issued certificate can be misused, and they reduce reliance on revocation checks, which clients apply inconsistently. They also encourage automation, which makes it easier for the industry to respond quickly to security incidents or to changes in cryptographic requirements.
Does this affect paid certificates from other authorities?
This specific change applies to Let’s Encrypt certificates. Other certificate authorities set their own lifetimes within limits defined by industry rules and browser policies. The wider industry has been moving towards shorter lifetimes, so organisations using paid certificates should also expect, and prepare for, more frequent renewals in future.
How can I check when my certificate expires?
Open the site in a browser and view the certificate details, which show the validity dates. From a command line, tools such as OpenSSL can connect to a server and print the expiry date. For ongoing protection, set up an external monitoring service that alerts you before expiry.
Sources and further reading
- Ars Technica, technology news reporting on the Let’s Encrypt lifetime change
- Let’s Encrypt, official documentation, announcements and community forum on issuance policy
- IETF, the standards body that publishes the ACME protocol specification
- CA/Browser Forum, the industry body whose baseline requirements govern publicly trusted certificates
Surfaced from the rss:arstechnica signal “shorter TLS certificate lifetimes”. AI-assisted draft, editorially reviewed.
