On this page · 11 sections
- What changes on 10 February 2027, and what is already live
- Why 64 days now, when the industry cap is 100
- The three Let's Encrypt profiles compared
- What breaks: eight failure patterns to find before February
- ARI: the renewal method Let's Encrypt recommends
- Rate limits: what changes (almost nothing)
- Worked example: a 500-certificate estate
- India, EU and US notes
- Implementation checklist
- How eCorpIT can help
- References
Summary. On 10 February 2027 Let's Encrypt switches its default classic ACME profile from 90-day to 64-day certificates and cuts authorisation reuse from 30 days to 10. Any certificate issued or renewed from that date lasts 64 days unless you opt into a shorter profile. Existing certificates are not revoked, and the last 90-day certificate should expire on 11 May 2027. Staging has issued 64-day certificates since 14 October 2026, so you can test now. On 16 February 2028 classic falls to 45 days with seven-hour reuse. The opt-in tlsserver profile already issues 45-day certificates and shortlived issues 160-hour ones. Behind this sits CA/Browser Forum ballot SC-081v3, which caps public TLS certificates at 200 days now, 100 days from 15 March 2027 and 47 days from 15 March 2029. What breaks: jobs hard-coded to renew at 60 days (four days of slack on a 64-day certificate, outright failure at 45), fixed renewal margins close to the new lifetime, 30-day expiry alerts, manual installs on appliances and designs that lean on 30-day reuse. The fix Let's Encrypt recommends is ACME Renewal Information (ARI, RFC 9773), whose renewals are exempt from all rate limits. The limits themselves do not change.
About this article. For DevOps, SRE and security teams that run Let's Encrypt certificates. On 1 November 2026 we checked dates, profile values, limits and commands against Let's Encrypt's documentation, blog and staff forum announcements, the CA/Browser Forum Baseline Requirements (version 2.3.1, dated 4 October 2026), and the Certbot and cert-manager documentation. Schedules can move, so re-check before you change production. No vendor paid for inclusion. Researched with AI assistance and reviewed by our editorial team.
What changes on 10 February 2027, and what is already live
Let's Encrypt published the plan on 2 December 2025 and confirmed the February date on 7 October 2026. The change applies to new certificates only, so you will see the shorter lifetime at your first renewal after 10 February, not on the day itself.
The timeline below combines Let's Encrypt's announcements on expiry emails, OCSP, six-day certificates, profile changes and staging, with the Baseline Requirements dates.
| Date | Change | Who is affected |
|---|---|---|
| 4 June 2025 | Expiration reminder emails ended | Anyone who relied on Let's Encrypt to warn them |
| 6 August 2025 | OCSP service turned off; revocation via CRLs only | Clients and appliances that expected OCSP |
| 15 January 2026 | 6-day and IP address certificates generally available | Opt-in via shortlived |
| 13 May 2026 | tlsserver profile switched to 45-day certificates | Early adopters who selected it |
| 8 July 2026 | tlsclient profile withdrawn | Anyone using Let's Encrypt for TLS client authentication |
| 14 October 2026 | Staging issues 64-day certificates | Test and CI pipelines |
| 10 February 2027 | classic default: 64-day certificates, 10-day authorisation reuse | Everyone who does not select a profile |
| 15 March 2027 | Industry cap of 100 days for all public CAs | Commercial CA customers too |
| 11 May 2027 | Last 90-day Let's Encrypt certificate expected to expire | Fleets that renewed just before 10 February |
| 16 February 2028 | classic: 45-day certificates, 7-hour authorisation reuse | Everyone on the default |
| 15 March 2029 | Industry cap of 47 days; domain validation reuse 10 days | All public CAs |
Since the expiry emails stopped in June 2025, Let's Encrypt will not warn you that a certificate is about to lapse, so your own monitoring has to. It also says the 64-day switch leaves its ACME endpoints and issuance chains unchanged, so trust stores do not change because of it.
Why 64 days now, when the industry cap is 100
Let's Encrypt is ahead of the rules, not forced by them yet. Ballot SC-081v3, adopted on 11 April 2025 with Apple, Google, Microsoft and Mozilla all voting yes and 25 of 30 certificate issuers in favour, sets a falling ceiling. Maximum validity is 200 days today, 100 days for certificates issued from 15 March 2027 and 47 days from 15 March 2029. The domain validation reuse limit runs 200 days, 100 days, then 10 days in 2029.
A 64-day certificate sits well under the 100-day cap every public CA must meet from March 2027. Our guide to the 100-day TLS certificate cap covers that change for teams buying from commercial CAs.
Let's Encrypt gives two reasons for moving early. Shorter lifetimes reduce the risk of key compromise and mis-issuance. And the reuse cuts prepare subscribers for the 2029 limit while removing the need for CAA rechecking, where Let's Encrypt must repeat part of validation once the data is more than seven hours old.
The three Let's Encrypt profiles compared
A profile is a named bundle of validation rules and certificate contents. Your ACME client either asks for one or gets classic by default. The table uses the values on the profiles page, last updated 4 October 2026, and the dated changes announced for classic.
| Property | classic until 9 Feb 2027 | classic from 10 Feb 2027 | classic from 16 Feb 2028 | tlsserver | shortlived |
|---|---|---|---|---|---|
| Validity | 90 days | 64 days | 45 days | 45 days | 160 hours |
| Authorisation reuse | 30 days | 10 days | 7 hours | 7 hours | 7 hours |
| Pending authorisation lifetime | 7 days | No change announced | No change announced | 1 hour | 1 hour |
| Order lifetime | 7 days | No change announced | No change announced | 8 hours | 8 hours |
| Max names per certificate | 100 | No change announced | No change announced | 25 | 25 |
| Common Name included | Yes | No change announced | No change announced | No | No |
| Identifier types | DNS | No change announced | No change announced | DNS | DNS and IP |
Selecting a profile. Profile selection follows an IETF draft, and not every client supports it. The production directory listed classic, shortlived and tlsserver on 1 November 2026. Certbot added --preferred-profile and --required-profile in 4.0.0 (7 April 2025) and has stored the choice in the renewal configuration since 4.1.0, so renewals keep the profile you picked. Our ACME client comparison covers the other clients.
Should you opt in early? tlsserver is a cheap way to rehearse 2028 on a few non-critical hosts. Check three things first. The 25-name limit breaks certificates that bundle many SANs. The missing Common Name can confuse older software that still reads the CN instead of the SAN list. And the one-hour pending authorisation lifetime is tight for DNS-01 if your DNS provider takes close to an hour to propagate, which Let's Encrypt says can happen.
IP address certificates require shortlived. Certbot 5.3 added --ip-address, and webroot support needs 5.4 or later.
What breaks: eight failure patterns to find before February
Let's Encrypt's advice is short: search cron jobs, wrapper scripts and runbooks for hard-coded numbers such as 83, 80 or 60. The table expands that into the patterns that cause real outages.
| Pattern | Why it fails with 64-day certificates | Fix |
|---|---|---|
| Cron renews every 60 days or on the 1st of every other month | Leaves about 4 days before expiry; one failed run means an outage. At 45 days it fails outright | Run the client daily and let it decide (ARI, or about two-thirds of lifetime) |
| renew_before_expiry or renewBefore set to 60 days or more | At 60 days a 64-day certificate falls due after 4 days; at 64 days or more it is always due. Without ARI, the limit of 5 per exact set of names per 7 days then applies | Use the client default, or a percentage such as cert-manager's renewBeforePercentage |
| Expiry alert fires at 30 days left | Certbot renews at one-third of lifetime left (about 21 days), so the alert fires every cycle; at 45 days it fires from day 15 | Alert on renewal-job failure and on less than a quarter of lifetime left |
| Manual install on load balancers, firewalls, NAS boxes or IIS | Renewals per certificate rise from about 6 to 8.6 a year, and to about 12 in 2028 | Deploy hooks or vendor APIs; terminate TLS where ACME runs |
| Validate once, issue for weeks | Authorisation reuse drops from 30 days to 10, then 7 hours | Validate per order; delegate _acme-challenge with a CNAME |
| DNS-01 with slow propagation on tlsserver or shortlived | Pending authorisations expire after 1 hour | Faster DNS API, or a dedicated validation zone |
| Leaf certificate pinning in mobile or IoT apps | Pins break at every rotation, now more often | Stop pinning leaf certificates |
| Apps that load the certificate once at start-up | Renewed files sit on disk unused until a restart | Reload hooks, or a restart controller on Kubernetes |
The second row hides well. Certbot has renewed with one-third of lifetime left since 4.0.0, but a renew_before_expiry value overrides that when the server gives no ARI response. Set it to 70 days to be safe and a 64-day certificate is due the moment it is issued. On a client without ARI, those renewals count against the limit of 5 per exact set of names per 7 days. cert-manager renews at two-thirds of the issued duration by default, warns that a renewBefore close to the duration can cause a renewal loop, and recommends renewBeforePercentage, which cannot be set alongside renewBefore.
# Find the hard-coded intervals Let's Encrypt names (83, 80, 60), plus legacy 90s
sudo grep -RnsE '\b(60|80|83|90)\b' /etc/cron* /etc/systemd/system /etc/letsencrypt/renewal 2>/dev/null
# Certbot: ARI needs 4.1.0 or later. --dry-run uses staging and skips the ARI check
certbot --version
sudo certbot renew --dry-run
# See what a live endpoint is serving
echo | openssl s_client -connect www.example.com:443 -servername www.example.com 2>/dev/null \
| openssl x509 -noout -dates -issuer
# cert-manager: let the issued lifetime drive renewal (remove renewBefore first)
spec:
renewBeforePercentage: 33 # renew when a third of the lifetime is left
ARI: the renewal method Let's Encrypt recommends
ACME Renewal Information lets the CA tell your client when to renew. The client asks the server's renewalInfo endpoint for a suggested window and renews inside it. The IETF published ARI as RFC 9773 in June 2025, and Let's Encrypt announced it that September. For Let's Encrypt certificates, Certbot's change log says ARI usually triggers renewal at about two-thirds of the lifetime, which matches what Let's Encrypt asks non-ARI clients to do themselves.
ARI does three useful things for the 64-day switch:
- It adapts automatically. When
classicmoves to 64 days and then 45 days, the suggested window moves with it.
- It removes rate-limit risk. ARI renewals are exempt from all rate limits when the new order names the certificate it replaces, shares at least one identifier with it, and that certificate has not already been replaced through ARI.
- It handles mass revocation. CAs must sometimes revoke on a 24-hour or 5-day timeline, too fast for manual work, and Let's Encrypt had to revoke about two million certificates in January 2022. ARI lets the CA pull your renewal forward before the revocation lands.
Client support varies. Certbot gained ARI in 4.1.0 on 10 June 2025, and the current release is 5.9.0 from 28 October 2026. For other clients, read the documentation, because setup differs from client to client.
Large platforms already depend on it. In a March 2026 case study on the Let's Encrypt blog, a Shopify engineer describes replacing a static threshold of 30 days before expiry, which could not cope with lifetime changes, with ARI polling across millions of merchant domains.
Watch DNS-PERSIST-01, but do not plan on it yet. This new challenge type, approved by the CA/Browser Forum as ballot SC-088v3 in October 2025, lets you publish one standing TXT record that authorises a specific ACME account, so renewals stop touching DNS. Let's Encrypt targeted production for Q2 2026, then a developer there said on 25 June 2026 that deployment would wait for an open issue in the IETF draft. That issue closed on 23 September 2026, and we found no production date on 1 November 2026. Google Trust Services went live on 28 September 2026 using draft 01, and warns that early adopters may need to update records once the standard is final.
Rate limits: what changes (almost nothing)
Let's Encrypt addressed this directly on 24 February 2026. Moving from renewal around day 60 to around day 30 will roughly double daily renewal requests, but renewals are exempt from the issuance limits, so no override changes are needed. Its example: an operator with 15,000 certificates in continuous renewal who creates 250 new ones a day stays within limits before and after the change. The values below come from the rate limits page, last updated 5 August 2026.
| Limit | Value | Applies to renewals? |
|---|---|---|
| New orders per account | 300 per 3 hours (refills 1 every 36 seconds) | No |
| New certificates per registered domain | 50 per 7 days | No |
| New certificates per exact set of identifiers | 5 per 7 days | Yes for non-ARI renewals; ARI renewals exempt |
| Authorisation failures per identifier per account | 5 per hour | Yes for non-ARI renewals |
| Consecutive authorisation failures per identifier | 1,152, then the identifier is paused | Non-ARI renewals; ARI renewals exempt |
| Requests to the renewal-info endpoint | 1,000 per second per IP | ARI polling only |
The real risk is a misconfigured client renewing on every run or failing validation repeatedly, which is exactly what these limits stop.
Worked example: a 500-certificate estate
Take a mid-sized company with 500 Let's Encrypt certificates, 460 of them on automated servers and 40 installed by hand on appliances. Assume each manual install takes 30 minutes including change control. The estate and the 30 minutes are our assumptions.
Renewals per certificate per year are 365 divided by the renewal interval: day 60 for 90-day certificates, about day 43 (two-thirds of 64) from February 2027, and day 30 for 45-day certificates in 2028.
| Metric | 90-day (today) | 64-day (from 10 Feb 2027) | 45-day (from 16 Feb 2028) |
|---|---|---|---|
| Renewal interval | 60 days | about 42.7 days | 30 days |
| Renewals per certificate per year | 365 ÷ 60 = 6.08 | 365 ÷ 42.67 = 8.55 | 365 ÷ 30 = 12.17 |
| Total issuances for 500 certificates | about 3,040 | about 4,280 | about 6,080 |
| Manual installs (40 certificates) | 243 | 342 | 487 |
| Manual hours at 30 minutes each | about 122 | about 171 | about 243 |
The manual 40 go from roughly 15 working days a year to 21, then 30.
The calendar is the second check. A 64-day certificate issued on 10 February 2027 expires on 15 April 2027. An ARI or two-thirds client renews it around 25 March, leaving about three weeks to catch a failure. A cron job that renews every 60 days would act around 11 April, four days before expiry.
India, EU and US notes
India: the eMudhra incident is the rehearsal. On 17 October 2026 Google's Chrome Root Program received a report that private keys for eight eMudhra subordinate CA certificates had been generated with weak entropy. Chrome blocked them within hours. Its 20 October post scheduled removal of the emSign ECC Root CA - G3 from the Chrome Root Store for 27 October 2026, and told site operators with certificates chaining to that root to install one from another hierarchy immediately. That left about a week between public notice and removal. eMudhra says the affected G3 certificates belong to one client ecosystem in the United States, and that it is winding down public TLS. A team with ACME automation and a tested second CA can treat that kind of order as a configuration change. Shorter lifetimes make the same discipline routine.
Certificate Transparency makes hostnames public. Chrome enforces Certificate Transparency for publicly trusted certificates by default, so assume every name in a public certificate is visible to anyone. Keep internal project names out of public SANs and use a private CA for internal hosts.
EU and US. There is no regional exemption. The Baseline Requirements apply to publicly trusted certificates for servers reachable through the internet, wherever the site is hosted, and enterprise private PKI for internal use sits outside them. Windows Server 2016 IIS hosts are a common home for manual certificates, so fold automation into that migration (see our Windows Server 2016 end-of-support playbook). Our Chrome HTTP warning audit covers the wider HTTPS checks.
Implementation checklist
- Inventory every Let's Encrypt certificate using a Certificate Transparency search (crt.sh or Censys, as the rate limits page suggests) and match each to an owner and a renewal method.
- Record the client and version on every host. Upgrade Certbot to 4.1.0 or later for ARI; current is 5.9.0.
- Run the grep above for 60, 80, 83 and 90 in cron, systemd timers, renewal configs and runbooks.
- Remove absolute renewal margins of 60 days or more; prefer client defaults or percentages.
- Switch schedules to daily runs and let the client decide whether to renew.
- Point a test host at staging, which has issued 64-day certificates since 14 October 2026, and confirm renewal plus reload. Certbot takes
--test-certor--dry-run; only--test-certkeeps a certificate you can inspect.
- Rewrite expiry alerts to fire on renewal-job failure and on less than a quarter of lifetime left, not a fixed 30 days.
- Automate the manual estate: deploy hooks for load balancers and CDNs, or move TLS termination to a point where ACME runs.
- Check reload behaviour for Java, Node and other processes that cache certificates in memory.
- Review authorisation reuse dependencies, especially multi-node setups where one node validates and others order later.
- Pick a second CA that supports ACME and test a switch, so an incident like eMudhra's becomes a configuration change.
- Brief the team by mid-January 2027, then repeat this checklist for 45-day certificates before February 2028.
How eCorpIT can help
eCorpIT is a Gurugram-based technology organisation, founded in 2021, assessed at CMMI Level 5 and MSME certified, with senior-led engineering teams working across AWS, Microsoft and Google platforms. Our cloud computing services team can audit a certificate estate, move manual renewals to ACME with ARI and wire renewal failures into your monitoring. Talk to us at /contact-us/.
Last updated: 1 November 2026.
