Three TLS deadlines landed inside one month, and two of them will never page anyone. Let’s Encrypt moves every subscriber to 64-day certificate lifetimes on February 10, 2027; staging starts October 14, 2026; and on March 15, 2027, certificate authorities must process account-bound CAA parameters under RFC 8657. Here’s what breaks, and what one afternoon buys.
The short answers, up front
Three questions are showing up everywhere right now—support inboxes, forums, assistants. Short answers first; the receipts follow.
- Will my Let’s Encrypt renewal break in February 2027? No, if your ACME client follows ARI and renews on the schedule it’s told to; yes, if anything in your stack renews on a hardcoded 60-, 80-, or 83-day offset—80 and 83 never arrive inside a 64-day lifetime, and 60 arrives with almost no margin left.
- Do I need CAA records for my domain? Publishing CAA stays optional, but from March 15, 2027, CAs must process the
accounturiandvalidationmethodsparameters your records carry—and after September’s registry hijacks, Google’s recommended defense is a restrictive CAA record with an ACME account binding. - Can a valid certificate still be fraudulent? Yes: in September 2026, attackers who controlled the registries for .gh, .sl and .as obtained genuinely domain-validated certificates for Google and YouTube domains, and Google says the issuing CAs did nothing wrong.
What Let’s Encrypt announced on October 7
On October 7, 2026, Let’s Encrypt published the date everyone suspected was coming: “On February 10, 2027, all Let’s Encrypt subscribers will move to certificates with 64 day lifetimes by default.” The same post sets the tail: “we expect the last 90-day certificate to expire on May 11, 2027.” Nothing running today gets revoked—this changes issuance, not certificates already in the field.
Two quieter changes ride along. “We will also be reducing the authorization reuse period from 30 days to 10 days”—the reuse period being the window in which a passed domain validation lets your account keep issuing without re-validating. And per the same post, “In 2028, the reuse period will shrink to seven hours.” Subscribers who want shorter certificates can “select an even shorter lifetime (45 or 6 days, as previously announced),” and rate limits “will not be impacted by this change.”
None of this is Let’s Encrypt freelancing. The CA/Browser Forum’s baseline requirements shorten maximum certificate validity on a fixed schedule: 200 days from March 15, 2026, 100 days from March 15, 2027, and 47 days from March 15, 2029, with domain and IP validation reuse shrinking to 10 days by that last date. Sixty-four days is Let’s Encrypt landing comfortably under the 100-day cap.
The quiet hero is ARI—ACME Renewal Information. “ARI allows Let’s Encrypt to tell your client when to renew.” A client that asks gets the right moment: early enough to survive a failed attempt, late enough to be efficient. It needs no configuration change on February 10. A client that never asks is where the breakage hides.
The failure modes that never page anyone
Renewal timing used to be the boring part of TLS—set and forget. It’s the first thing I read now, because the dangerous scripts are the ones nobody has opened since they were written: the cron job from 2019, the wrapper with a number in it, the runbook that says “renew every 60 days.”
“Grep for common hardcoded numbers like 83, 80 or 60 in cron jobs, wrapper scripts and runbooks”—the whole of Let’s Encrypt’s migration advice on offsets.
Those numbers are renewal offsets: renew when the certificate is that old, or when that many days remain. An 80- or 83-day age offset never arrives inside a 64-day certificate—the certificate expires first. A “renew at 60 days” cycle still fires, but it leaves 4 days of margin instead of 30, and 4 days is one failed attempt plus one retry, not a plan.
The fix is the one the announcement names: “you should update them to renew at approximately ⅔ of the lifetime instead.” Two-thirds of 64 is around day 42—renewal with three weeks of runway, every time.
The second failure mode is subtler: a client that ignores ARI and computes renewal timing from assumptions baked in years ago. Many maintained ACME clients already renew relative to the certificate’s actual expiry rather than a fixed age, and those keep working. The risk is the layer around them—wrapper scripts with RENEW_AFTER=60 sitting in a config file, quietly waiting for a lifetime that no longer exists.
And you don’t have to guess. “We will switch to issuing 64 day certificates in our staging environment on October 14, 2026”—so from October 14 the rehearsal target matches production exactly. Point a copy of your renewal setup at staging and watch when the renewal actually fires. That’s a rehearsal, not a leap.
dig +short CAA example.com
echo | openssl s_client -connect example.com:443 -servername example.com 2>/dev/null | openssl x509 -noout -dates
curl -sI http://example.comRead before you write, always. The first command shows what your CAA allows today—copy the current values before anyone edits anything. The second prints the dates of the certificate actually deployed. The third shows the first hop of an http:// request, which matters more than you’d think in the Chrome 154 section below.
Why a valid certificate stopped proving anything
The same week Let’s Encrypt posted its schedule, Google published its account of September’s registry hijacks. Attackers compromised three country-code registries—Ghana’s .gh on September 22, Sierra Leone’s .sl on September 25, American Samoa’s .as on September 27—and modified authoritative DNS records. Then they requested certificates for Google and YouTube domains. Domain validation passed, because the attackers genuinely controlled the DNS.
Google’s own sentence is the one to internalize: “we have no reason to believe the Certification Authorities (CAs) that issued the impacted certificates did anything wrong.” The CAs followed the rules. The DNS was lying. That is the entire trust model of domain-validated certificates, stated flatly.
The blast radius: iTnews cross-referenced issuance against Chrome’s blocklist and found 32 certificates issued to the attackers between September 22 and 27. 12 of those covered Google or YouTube—11 from Let’s Encrypt, one from ZeroSSL. The rest reached further; Google says CT log data surfaced “additional organizations, including several leading global brands and widely used online services, believed to have been impacted.”
Chrome “immediately blocked unauthorized HTTPS certificates via CRLSets,” and the issuing CAs pushed revocations in waves on September 26 and October 1. One nuance for anyone not on Chrome: CRLSets are a Chrome mechanism. The immediate block protected Chrome users; everyone else waited on ordinary revocation.
Google’s recommendation to domain owners is two lines: “Publish restrictive CAA records (with ACME account bindings),” and monitor CT logs, which “provides a near real-time alert whenever a certificate is issued for your domains.”
That second line is the one people skip. On a domain you actively run, you’d eventually notice a rogue certificate—an outage, a report, a customer’s screenshot. On a parked domain you never look at, a fraudulent certificate is invisible by definition: nobody visits, nobody sees the padlock. CT monitoring is the only alarm that fires for a name that should never issue anything—and this September proved the registries above those names can be the weak link.
The SaaS subdomain trap
Two sentences of CAA mechanics carry a whole class of outages. A CAA record on your apex applies to that domain and “any subdomains you create under it.” And a CA issuing for book.example.com walks up the tree—checking book, then the apex—“stopping at the first CAA record it finds.”
example.com. IN CAA 0 issue "letsencrypt.org"
book.example.com. IN CAA 0 issue "vendor-ca.example"The apex line is what most people publish; the second value is whatever your vendor documents as its CAA issuer domain. The subdomain line is the one that saves a SaaS hostname—it overrides the apex record for that name alone. Without it, here’s the trap: your apex allows Let’s Encrypt only. Your booking platform—a vendor—issues its own certificate for book.example.com through another CA. The vendor’s CA walks up, finds your apex record, doesn’t see itself, and refuses. Nothing of yours is misconfigured. The vendor’s renewal fails overnight, and Tuesday morning your bookings page greets customers with a certificate error.
The prevention is an inventory, not a clever record. List every hostname that carries a certificate—apex, www, store, bookings, mail, the SaaS vanity names—next to the CA that issues each. Then make the CAA set match: every issuing CA named on the apex record, or a per-hostname record wherever a vendor issues its own.
March 15, 2027 sharpens this. RFC 8657’s accounturi parameter binds issuance to one specific CA account: “The value of this parameter, if specified, MUST be a URI identifying a specific CA account,” and from that date CAs “MUST process the accounturi and validationmethods parameters as specified in RFC 8657.” Bind your apex to your account—which is exactly what Google recommends—and that binding inherits down to every subdomain, including the ones your vendors issue for. A vendor’s CA can’t present your account. Per-hostname CAA records stop being optional hygiene that day; on vendor hostnames, they’re the difference between a working renewal and a Tuesday-morning outage.
Chrome 154 makes sloppy TLS visitor-visible
Certificate work is invisible when it works. Chrome is about to make the sloppy version visitor-visible. In Chrome 147, released April 2026, Google enabled “Always Use Secure Connections” for the billion-plus users of Enhanced Safe Browsing first; with Chrome 154, rolling out this month, the mode ships on by default for everyone.
In this mode, Chrome attempts every connection over HTTPS and “will ask for the user’s permission before the first access to any public site without HTTPS.” Private destinations—local IPs, single-label hostnames, intranet shortlinks—are out of scope. The public web is not.
The warning is broader than “your site has no HTTPS.” The adoption guide is explicit: “If any redirect step in the chain does not support HTTPS, users will see a warning even if the final destination supports HTTPS.” That http:// link in someone’s newsletter, your old campaign domain, a redirector on another company’s server—each is now a warning interposed between a visitor and your HTTPS page.
The click-through doesn’t stick, either: “Users’ decisions to proceed are remembered for the duration of the browsing session.” Tomorrow is a new session, a new warning, in front of every visitor, until the chain is clean. Mixed content rides the same rail—an HTTPS page still pulling scripts or images over plain HTTP is exactly the half-upgraded state this mode exists to end.
HSTS—“a mechanism that allows websites to declare themselves accessible only via HTTPS”—takes your own hostname out of the warning path, because Chrome won’t offer an HTTP fallback for a host that declared itself HTTPS-only. What it doesn’t do is cover the other hops. HSTS saves the host that sets the header; it saves nobody’s redirector, nobody’s ad click-tracker, nobody’s http:// bookmark target. Your chain is only as clean as its weakest hop, and in Chrome 154 every hop is on display.
Google’s guidance to users is blunt: they “very strongly recommend enabling the ‘Always Use Secure Connections’ setting today.” The operator’s version of that sentence is: load your site with the mode on, and look at what your visitors will see.
The certificate hygiene checklist we run for maintenance clients
Here’s the checklist we run for maintenance clients before February. Nine points, one honest afternoon for a small stack. SaaS subdomains, more than one CA and a decade of cron make it a day or two—and most of that day is reading, not typing.
- Take a read-only look first:
dig +short CAA example.com, and copy the current values before anyone edits anything. - Search cron jobs, wrapper scripts and runbooks for hardcoded 60, 80 and 83—Let’s Encrypt’s own list—and move every hit to renewal at roughly two-thirds of the lifetime: day 42 of 64.
- Confirm every ACME client in the stack is ARI-aware; anything that can’t ask when to renew gets explicit calendar math instead.
- Rehearse against staging, which issues 64-day certificates from October 14, 2026—your rehearsal then matches production timing exactly.
- Inventory every hostname that carries a certificate—apex, www, store, bookings, mail, SaaS vanity names—next to the CA that issues each.
- Make the CAA set match that inventory: every issuing CA on the apex record, or per-hostname records wherever a vendor issues its own.
- Before March 15, 2027, place RFC 8657 account bindings deliberately:
accounturion the names you issue for, vendor hostnames carrying their own records so their renewals don’t inherit yours. - Turn on CT log monitoring for every domain you hold, parked ccTLDs included—it’s the only alarm that fires for a name nobody visits.
- Walk the redirect chain with
curl -sIand make every hop answer on HTTPS; remember that HSTS covers only the hostname that sets it.
What we automate vs. what needs human eyes
The machines get the boring bulk of it: expiry checks against the deployed certificate, the staging rehearsal on a schedule, CT alert delivery, renewal logs landing somewhere a human actually looks. The humans keep three jobs: reading grep hits in context (a 60 inside an if-age-over-60 check is not the same as one inside a sleep call), matching what a vendor’s documentation says against your CAA inventory, and judging what a Chrome 154 warning costs per visitor on a booking flow. That’s judgment, not tooling.
Honest scope: a single domain on a modern client, no SaaS subdomains, is a 20-minute check. Vendor-issued subdomains and two or three CAs make it a day or two of careful reading. It’s one slice of the maintenance work we do, and if you want a second pair of eyes on your renewal setup before February 10, tell us—that’s the kind of week where an afternoon beats an outage.