The run-up to 10 February 2027, and why renewals will not hit rate limits

As of October 2026 the default certificate lifetime is still 90 days. On 10 February 2027 it stops being. Let's Encrypt's 7 October 2026 announcement says: "On February 10, 2027, all Let's Encrypt subscribers will move to certificates with 64 day lifetimes by default unless they select an even shorter lifetime (45 or 6 days, as previously announced)."

That is four months out, and it is the reason to care this year rather than next. Certificate lifetimes sit on a published schedule that ends at 45-day defaults on 16 February 2028, and most certificate automation in production was written against 90.

The loud fear, that doubling renewal traffic will collide with rate limits, is the wrong one. Let's Encrypt is explicit that renewals are exempt. The failure that actually lands is quieter: a cron entry firing on a hardcoded interval, an alert threshold sized for a 90-day window, a reload hook that quietly stopped working. All of it is fixable in an afternoon, if you know which of those you own.

The dates that matter

Date	What changes
2025-12-02	Let's Encrypt publishes the 90 to 45 day plan
2026-01-15	6-day (160-hour) and IP address certificates generally available, opt-in
2026-10-14	Staging starts issuing 64-day certificates
2027-02-10	Default drops to 64 days; authorization reuse falls from 30 days to 10
2027-05-11	Last outstanding 90-day certificate expected to expire
2028-02-16	Default drops to 45 days; authorization reuse falls to 7 hours

February 2027 starts the 64-day era. It does not end it. The 64-day era is what runs for the following year, until 45 days takes over.

The schedule is not one CA's invention. The December 2025 master post grounds it in "the CA/Browser Forum Baseline Requirements" and adds that "All publicly-trusted Certificate Authorities like Let's Encrypt will be making similar changes." The October post also fixes an end date for the old default: "we expect the last 90-day certificate to expire on May 11, 2027". That leaves three months of stragglers after the switch, not a cut-off.

One operational detail is easy to miss: staging already switched. "We will switch to issuing 64 day certificates in our staging environment on October 14, 2026 to enable testing." If you are not exercising your renewal path against staging this month, February is when you find out. Nothing gets revoked on the way, at least: "We will not revoke valid certificates as a part of this process."

Renew at two-thirds of the lifetime, not on a hardcoded day

The wording has barely moved between the two announcements, which is exactly why it gets skimmed. December 2025: "For example, renewing at a hardcoded interval of 60 days will no longer be sufficient. Acceptable behavior includes renewing certificates at approximately two thirds of the way through the current certificate's lifetime."

October 2026 restates it as an instruction: "If your renewals are hard-coded to a date from expiration you should update them to renew at approximately 2/3 of the lifetime instead."

Two-thirds of 64 days lands near day 43. Two-thirds of 45 days lands near day 30, which is where a lot of teams already renew by coincidence.

The two hardcoded strategies fail differently, and only one of them looks like an outage:

• Renew 60 days before expiry. Fine at 90 days, self-defeating at 64. The warning window is now longer than the certificate. It fires too early, then fires again.
• Renew every 60 days. Technically still inside a 64-day certificate, with four days of margin and no room for a retry loop. At 45 days it is a guaranteed outage.

Grep for both shapes. The October post names what to search for: "Grep for common hardcoded numbers like 83, 80 or 60 in cron jobs, wrapper scripts and runbooks if you're not sure."

Clients that already do the arithmetic correctly are not your problem, but confirm that rather than assume it. Caddy's renewal_window_ratio global option defaults to 0.3333 of the remaining lifetime, and the documentation flags the limit of that approach: "this is a suggestion, since ACME issuers may implement the ARI extension which has the issuer dictate a window in which the ACME client (Caddy in this case) should attempt renewal."

Certbot checks ARI too. Its changelog entry for 4.1.0 records that "certbot renew will automatically check ARI when using an ACME server that supports it, and may renew early based on the ARI information. For Let's Encrypt certificates this will typically cause renewal at around 2/3rds of the certificate's lifetime, even if the renew_before_expiry field of a lineage renewal config is set a later date."

The rate-limit myth

This is the piece to unlearn before it costs you a weekend. From the February 2026 post on shorter lifetimes and rate limits: "The good news for subscribers is that you don't need any changes to your rate limits ... Our rate limits affect issuance for new domain names (or groups of domain names), but renewals are exempt."

October repeats it in a single line: "Rate limits will not be impacted by this change."

The rate limit table shows why. New Orders are capped at 300 per account per three hours. New Certificates are capped at 50 per registered domain per seven days, and that domain cap is global across every account, not per account. Neither limit counts renewals. The worked example is the part to keep: "if you are managing a set of 15,000 certificates that you continually renew, and create 250 new certificates (with new domain names) each day, you will be well within our limits both before and after the transition."

So what does bite? The authorization reuse window, which drops from 30 days to 10 in February 2027 and to seven hours in 2028. A domain validation that was reusable for a month stops being reusable for a month. If you automate DNS validation and expect a challenge to stay warm, that assumption expires first.

The outage mode is the one nobody pages on: renewal stops silently and stays invisible for a full certificate lifetime. The December post is blunt about both halves of the remedy: "Manually renewing certificates is not recommended, as it will need to be done more frequently with shorter certificate lifetimes", and "we recommend that you make sure your systems have sufficient monitoring in place to alert appropriately if certificates aren't renewed when expected."

Scale the thresholds to the lifetime rather than to today's certificate. If renewal belongs at two-thirds, alert at one-third remaining (about 21 days on a 64-day certificate), page at one-sixth (about 11 days), and alert separately on "no renewal attempted inside the expected window". A certificate sitting unexpired looks perfectly healthy right up until it does not.

ARI is RFC 9773, and it is a resource, not a header

RFC 9773 is titled "ACME Renewal Information (ARI) Extension", Category: Standards Track, June 2025. Its status block reads that it "is an Internet Standards Track document" which "has been approved for publication by the IESG". Let's Encrypt announced the publication on 16 September 2025: "we're happy to announce that IETF has published our latest addition to the ACME protocol, ACME Renewal Information (ARI), as RFC 9773."

The RFC sets out four steps:

1. A server supporting ARI adds a renewalInfo URL to its ACME directory object.
2. The client makes an unauthenticated GET to a path beneath it, /renewal-info/{certID}, where the identifier is the base64url-encoded Authority Key Identifier plus serial number.
3. The response carries suggestedWindow with start and end timestamps, optionally an explanationURL, and a Retry-After header while no window is ready.
4. On renewal the client passes replaces in its newOrder request, telling the CA which certificate this order supersedes.

One correction is worth stating plainly, because a lot of secondary writing has it backwards. There is no Renewal-Info HTTP response header in RFC 9773. ARI standardises an ACME resource. The header form people remember is the earlier draft design, from when draft-ietf-acme-ari shipped a header rather than a resource. The string does not appear in the RFC text, and we are not going to guess about whether a given CA still serves that shape for backwards compatibility.

Shopify's migration is the closest published account of a large certificate fleet moving off static thresholds. The system "relied on a static renewal threshold: 30 days before the end of the 90-day lifetime", and the write-up names "Brittleness to lifetime changes" among the weaknesses. The replaces field is the part most operators never wire up: it "can grant a higher priority or bypass rate limits for renewals occurring during the window". That is a scheduling priority, which is a different mechanism from the renewal exemption above. The two are easy to conflate and they answer different questions.

Generation Y is a migration, not a break

The Generation Y hierarchy, announced 24 November 2025, adds two roots (ISRG Root YR on RSA 4096 and ISRG Root YE on ECDSA P-384) and six intermediates, YE1 through YE3 and YR1 through YR3.

Two details change how you read a chain. The intermediates drop an EKU: "these intermediates do not contain the 'TLS Web Client Authentication' Extended Key Usage. This means that these intermediates cannot issue end-entity certificates containing that EKU." That constrains client-certificate issuance from these intermediates, not ordinary server certificates. And "each issuance will choose which intermediate to use at random, to discourage intermediate key pinning", so anything that pins one intermediate or assumes a single chain shape per issuer will need revisiting. Our background on chain assembly is in what an SSL certificate chain actually is.

Nothing breaks overnight, and that is deliberate: "we have cross-signed the new roots from the old ones." Existing clients validate through the current X1/X2 path until they ship the new trust stores. If you maintain a trust store by hand, how those lists fail in practice is worth the detour.

Operator checklist before February

1. Grep for hardcoded lifetimes. 83, 80, 60, and any literal 90 multiplied into a delay. Cron entries, wrapper scripts, runbooks, and IaC templates.
2. Find out whether your ACME client consults ARI, and on which version. If it does not, treat two-thirds as a rule you implement, not one you inherit.
3. Replace date arithmetic with a fraction of the certificate's own lifetime, computed at renewal time rather than assumed at configuration time.
4. Rescale expiry alerting to the new lifetime, and add an alert for the absence of a renewal attempt.
5. Verify the post-renewal reload path. More frequent renewals means more reloads; a hook that fails once now fails twice as often.
6. Exercise the whole thing against staging, which has been issuing 64-day certificates since 14 October 2026.
7. Audit DNS validation caching against the 10-day reuse window, and plan for 7 hours in 2028.
8. Check anything that pins a chain or intermediate against the random-intermediate selection described above.

What we do not know yet

Two gaps, both real, neither closable by inference:

• Have the Generation Y roots actually entered the trust stores? The November 2025 post says only that the roots were "submitted for inclusion in the Apple, Chrome, Microsoft, Mozilla, and other root programs", and closed by promising an update once the hierarchy was officially included. We found no follow-up announcement, so we are not claiming they are in your browser yet.
• Which CA/Browser Forum ballot sets the 45-day ceiling? Let's Encrypt attributes it to the Baseline Requirements generally and names no ballot number. Anyone citing a specific ballot is going past what the primary source supports.

Related Tools & Further Reading

• SSL Checker — read the real notAfter on your hosts now, so the 2027 baseline is a number you have rather than one you assume.
• What is an SSL certificate chain? — how the intermediates above stack, and what pinning an intermediate costs you.
• What is an SSL certificate? — the validity fields that all of the above turns on.
• Reading a certificate error: string, cause, fix — what to do on the morning a renewal does not land.