On October 7, Let’s Encrypt reiterated the schedule for shortening the standard validity period of its TLS certificates from the current 90 days to 64 days, with the change taking effect on February 10, 2027. The company plans to cut it further to 45 days in 2028. It also announced that its staging environment will switch to 64-day certificates on October 14, 2026. Even if you have automatic renewal configured, continuing to use a traditional fixed setting that renews 60 days after issuance would leave only 4 days before expiration on a 64-day certificate. What you need to check is not just when certificates are renewed. You also need to verify the mechanism by which a newly obtained certificate actually reaches the endpoints your users connect to.
Shortening to 64 days in February 2027, on a different schedule from the industry-wide cap
The 64-day change applies to standard certificates issued without specifying a special profile. It will apply to certificates newly issued or renewed on or after February 10, 2027, and certificates already issued will not suddenly be invalidated all at once. The last 90-day certificates to be issued are expected to expire by May 11 of the same year. If you already use the 45-day or roughly 6-day short-lived certificate profiles, those settings will continue to apply.
The policy of shortening certificate lifetimes, along with the production migration schedule, was announced in December 2025. The October 7 announcement is not a new policy change but a reminder that the transition is approaching, urging operators to prepare.
Organizing the plan announced in December 2025 together with this latest notice, the main upcoming dates are as follows.
| Date | Let’s Encrypt change |
|---|---|
| October 14, 2026 | Staging environment for testing moves to 64-day certificates |
| February 10, 2027 | Standard certificates shortened to 64 days. Reuse period for domain validation results also shortened to 10 days |
| February 16, 2028 | Standard certificates shortened to 45 days. Reuse period for domain validation results shortened to 7 hours |
Let’s Encrypt is taking an approach of shortening certificate validity earlier than the industry-wide rules require.
Under the CA/Browser Forum requirements, the maximum validity of publicly trusted TLS server certificates is being reduced in stages: 200 days from March 15, 2026, 100 days from March 15, 2027, and 47 days from March 15, 2029.
This is the upper limit that applies to TLS server certificates issued by certificate authorities that are publicly trusted by browsers and others.
Accordingly, not every certificate authority will move to 64-day certificates in 2027. Likewise, the 47 days set by the CA/Browser Forum and the 45 days planned by Let’s Encrypt are different things: an industry-wide ceiling versus the validity period adopted by an individual certificate authority.
When planning certificate renewals, you need to confirm what schedule your certificate authority will actually follow.
Renewing a fixed 60 days after issuance leaves just 4 days before expiration
If you renew a traditional 90-day certificate 60 days after issuance, you have 30 days of margin before expiration. But applying the same setting to a 64-day certificate sharply reduces the time available to respond if renewal fails.
With a fixed setting that renews 60 days after issuance, only 4 days remain before a 64-day certificate expires. By contrast, renewing once two-thirds of the validity period has elapsed leaves a margin of about 21.3 days.
Let’s Encrypt presents renewing when roughly two-thirds of a certificate’s validity period has elapsed as a guideline.
If the validity period is L days, this approach renews 2L/3 days after issuance, leaving L/3 days before expiration. With a fixed approach that renews 60 days after issuance, the remaining time is L−60 days.
| Certificate validity | Renewal timing at two-thirds elapsed | Days remaining before expiration | If renewed 60 days after issuance |
|---|---|---|---|
| 90 days | 60 days after issuance | 30 days | 30 days remain |
| 64 days | About 42.7 days after issuance | About 21.3 days | 4 days remain |
| 45 days | 30 days after issuance | 15 days | Expires 15 days earlier |
Figures are rough estimates calculated from the published validity periods, using the time of issuance as the starting point. Decimals are rounded to one place. Early revocation and deployment delays are not taken into account, and the figures do not guarantee actual renewal timing or service availability.
Even with a 64-day certificate, renewing 60 days after issuance will not necessarily fail. The problem is that the time available to respond if it does fail becomes extremely short.
For example, if domain ownership validation fails or the renewal process stops for some reason, a recovery window that used to be 30 days shrinks to just 4. If you keep responding with the same assumptions as before, recovery may not be in time, and the certificate could expire.
Looking ahead to the move to 45 days in 2028, simply changing the fixed value of 60 days to another number is not a fundamental solution.
It is preferable to move to a mechanism that automatically determines renewal timing according to each certificate’s validity period.
With ARI, you can renew at the timing the certificate authority recommends
What Let’s Encrypt recommends is a mechanism called ACME Renewal Information (ARI).
ACME is a protocol for automating tasks such as obtaining and renewing certificates, and ARI is an extension to it. RFC 9773 defines a mechanism in which the certificate authority returns the start and end times of a window in which it recommends renewing a certificate, and the client decides the actual renewal time based on that information. Compared with mechanically calculating renewal timing from a certificate’s validity period, ARI has the advantage of reflecting conditions on the certificate authority’s side.
For example, it can spread renewal requests so they do not concentrate in particular time windows, and it can also prompt earlier renewal than usual if a certificate needs to be revoked. However, simply storing the recommended renewal window once it has been obtained is not enough. The client needs to keep checking whether the window indicated by the certificate authority has changed, and to retry at appropriate intervals if renewal fails.
Shopify is one company that has adopted ARI. Nick Silverman, an infrastructure engineer at the company, explained the difference between the traditional renewal approach and the approach after adopting ARI in a March 2026 guest post.
Previously, Shopify took 30 days before a 90-day certificate’s expiration as the baseline and added a random delay of 0 to 72 hours to determine renewal time. This approach did spread out the company’s own renewal processing over time, but it reportedly had limits in handling the load across the certificate authority as a whole and in cases where certificates urgently needed to be revoked. After adopting ARI, the company switched to periodically retrieving the renewal window recommended by the certificate authority and deciding renewal timing based on that information.
This case shows the importance of not only automating certificate renewal but also deciding renewal timing in coordination with the certificate authority. However, the improvements described are Shopify’s own operational report, not independent measurements such as a specific percentage reduction in failure rates. Also, the increase in renewals that comes with shorter certificate lifetimes is a separate matter from hitting a certificate authority’s issuance limits.
Let’s Encrypt expects daily renewal requests to double with the move from 90 to 45 days, but says that there is no need to raise rate limits for ordinary certificate renewals.
The current rate limits documentation states that renewals meeting ARI’s conditions are exempt from all rate limits.
On the other hand, under the traditional non-ARI method, in which a request is treated as a renewal based on factors such as an identical set of domain names, some limits continue to apply.
To receive the ARI exemption, the new certificate issuance request must specify the certificate being replaced and meet certain conditions, such as sharing at least one domain name with it and the original certificate not having already been replaced using ARI.
When preparing for shorter certificate lifetimes, check not only whether your ACME client supports ARI but also whether ARI is actually used in the renewal process itself.
The reuse period for domain validation results is also being shortened, separately from certificate validity
In 2028, the period for which domain validation results can be reused will also be shortened to 7 hours.
This is separate from the validity period of the TLS certificate itself.
Before issuing a certificate, a certificate authority verifies that the applicant controls the domain in question. Within a certain period, the result of this verification can be reused for subsequent certificate issuance.
In Let’s Encrypt’s standard profile, the reuse period, currently 30 days, will be shortened to 10 days in 2027 and to 7 hours in 2028.
In other words, what is being shortened to 7 hours in 2028 is the reuse period for domain validation results; it does not mean you must renew a 45-day certificate every 7 hours.
Shorter reuse periods make it harder to keep reusing, over a long period, domain control that was verified in the past.
If domain validation is also automated, no additional manual work is usually needed. However, custom ACME clients and similar tools built on the assumption that earlier validation results can be reused for a long time will need to have their behavior reviewed.
Let’s Encrypt cites the proper performance of checks related to CAA records as one purpose of shortening the reuse period to 7 hours.
CAA records are a DNS mechanism that specifies which certificate authorities are permitted to issue certificates for a particular domain. Shortening the reuse period for domain validation results reduces the time during which issuance depends on old validation results, so that the checks required at issuance are based on more current state.
Meanwhile, the main purpose of shortening the certificate validity period itself is to reduce the risk that mis-issued certificates, or certificates that can be abused through private key leaks, remain in use for a long time.
In its explanation of certificate lifetimes, Let’s Encrypt cites limiting this kind of harm and moving toward mature automation as reasons for the shorter lifetimes.
With shorter validity periods, the time until a problematic certificate naturally expires is also shortened.
However, if an attacker keeps holding a leaked private key, or if the ability to improperly issue certificates has not been eliminated, merely shortening the validity period does not solve the problem.
Protecting and replacing private keys, and revoking certificates as necessary, will remain important.
Let’s Encrypt ended its OCSP service, which answers queries about certificate revocation status, in August 2025, but it continues to provide revocation information through certificate revocation lists (CRLs).
Just because certificates are 64 or 45 days does not mean revocation handling itself becomes unnecessary.
Beyond obtaining certificates, check deployment to servers and external monitoring
For Certbot, a widely used certificate auto-renewal tool, how often the renewal process is launched differs from how often certificates are actually renewed.
According to the official Certbot guide, from version 4.0.0 onward a certificate is normally treated as due for renewal when less than one-third of its total validity period remains.
As a result, even if you run the renewal check every day, a new certificate is not issued each time.
Older versions, on the other hand, used a fixed rule that renewed a certificate once fewer than 30 days remained before expiration. You also need to check which version of Certbot you currently have installed and whether you have changed the renewal conditions in custom scripts.
There is another point to watch after a certificate is issued.
Even when certbot renew exits successfully, that does not necessarily mean a new certificate was issued. It is treated as a successful exit not only when a certificate that needed renewal was renewed, but also when there was nothing to renew and nothing was changed.
To run deployment processing only when a new certificate has been issued, or to instruct a web server to reload its configuration, you can use deploy-hook.
Also, even if a certificate is obtained successfully, that does not mean the actual service is using the new certificate.
For example, even if the certificate file itself has been updated, if a load balancer or web server is still holding the old certificate in memory, an expired certificate may be presented when users connect.
For that reason, certificate issuance and reflection on the server must each be verified.
Ultimately, it is important to make a TLS connection from outside and verify that the expiration date of the certificate actually presented has been updated.
Monitoring only issuance logs cannot detect cases where deployment fails after the certificate has been obtained.
The staging environment switchover scheduled for October 14, 2026 will be an opportunity to test in advance whether obtaining 64-day certificates and the renewal decision logic work correctly.
However, certificates issued in the staging environment are test-only certificates that ordinary browsers do not trust.
In addition, Certbot’s dry-run normally does not execute deploy-hook. A successful renewal test therefore does not mean you have confirmed deployment to the actual server or the reloading of its configuration.
The process of applying a new certificate to its deployment destination needs to be verified separately.
In this announcement, Let’s Encrypt also recommends putting in place a mechanism for receiving notifications when certificate renewal fails.
The expiration notice emails it previously provided were announced to be ending in 2025. Operations that rely on notification emails from the certificate authority to prevent expiration also need to be reviewed.
Before the move to 64 days in February 2027, you should put in place the whole chain: automatic renewal that uses ARI or otherwise follows each certificate’s validity period, detection of renewal failures, reflection on servers, and monitoring of the expiration date of the certificate actually presented.
What matters is an operation that can confirm not only that a certificate was obtained successfully, but also that the new certificate is actually being used on the servers users connect to.
If automation and monitoring are built out to that extent, the same mechanisms can make it easier to handle the further shortening to 45 days planned for 2028.