Let's Encrypt Will Validate Your Domain From Seven Places on November 10

Certificate renewals are the one piece of my infrastructure I stopped thinking about years ago. The timer fires, the challenge lands, the cert rotates, and the only time I look at it is after something else has already broken. Let’s Encrypt just made that habit a little less safe to keep.

On October 15, the Let’s Encrypt API announcements category got a short post saying they are adding two more remote perspectives for domain validation. In practice, starting November 10, every domain validation gets performed seven times: once from their primary datacenter and six times from remote network perspectives. Today it is five total, one primary plus four remote, which has been the setup since March 2024. Staging gets the change first, on Tuesday, October 27. Their own framing is the reassuring one: “We expect little to no impact to users.”

That is probably true for a normal VPS with port 443 open to the world. It is not true for anyone who has ever typed a country into a firewall rule. And the part of this change that will decide your fate is not the number seven, it is the quorum table sitting behind it.

📰 What Actually Changes

The mechanics are boring on purpose. Your ACME client does not change, your challenge type does not change, and the challenge value does not change. What changes is how many independent networks have to see that value before Let’s Encrypt will sign anything.

The requirement comes from the CA/Browser Forum Baseline Requirements, section 3.2.2.9, Multi-Perspective Issuance Corroboration. The text is blunt about why it exists: corroborating the primary determination from remote perspectives “can improve protection against equally-specific prefix Border Gateway Protocol (BGP) attacks or hijacks.” If an attacker can hijack the route to your domain, the CA’s single vantage point sees the attacker’s server answering the challenge. Ask the same question from six other networks and the hijack has to be much wider than one BGP announcement to survive.

The phased floor in the Baseline Requirements is worth reading in full, because it explains the timing. Two remote perspectives from March 15, 2025, with the quorum table becoming binding six months later. Three from March 15, 2026, and that is also where the two-RIR requirement starts. Four from June 15, 2026. Five from December 15, 2026, with the same two-RIR rule and the same hard stop: no quorum, no certificate.

Let’s Encrypt is landing six remote perspectives on November 10, five weeks ahead of the final deadline. This is not a security team being paranoid for fun. It is a compliance date, and every other publicly trusted CA is on the same clock.

🧮 Six Is a More Interesting Number Than Seven

Here is the table from section 3.2.2.9 that nobody quotes. If a CA uses two to five distinct remote perspectives, exactly one non-corroboration is allowed. If it uses six or more, two are allowed.

Read that against Let’s Encrypt’s current and future state:

• Today: one primary plus four remote, one dissent allowed, so three remote perspectives must agree. An attacker has to own the primary path and three remote paths to push a certificate through.
• After November 10: one primary plus six remote, two dissents allowed, so four remote perspectives must agree. The attacker now needs the primary path and four remote paths.

So the hardening buys exactly one extra hijacked network path, while the tolerance for a broken or lying vantage point doubles. That is the design decision I would have made too: a false negative during validation is an outage, and a false positive is a rare, expensive incident. Let’s Encrypt has not explained why they picked six over the required five. My read is that taking the six or more row is how you satisfy a five perspective floor while keeping a failure budget for regions you do not control. At exactly five, you are one flaky path away from a blocked issuance.

The rest of the section is where the real engineering lives, and it is stricter than most people assume. Two perspectives only count as distinct if they are at least 500 km apart in a straight line. A perspective may use a resolver that is not co-located with it, but that resolver must sit in the same RIR service region as the perspective, and any pair of resolvers used in one attempt must be at least 500 km apart. Results must not be reused between perspectives, and the BR forbids sharing a DNS cache, because an adversary who controls traffic from one vantage point could poison it for the others.

CAA checks go through the same corroboration, with one mercy: a CA may reuse corroborating CAA evidence for up to 398 days, and remote perspectives can skip re-fetching CAA records for the same domain in later requests from the same applicant. Domain control validation gets no such discount.

🧱 The Setups That Break

Let’s Encrypt has maintained a geoblocking FAQ since the first rollout, and it is unusually direct: do not geoblock validation traffic, and do not build firewall rules around the countries the perspectives currently live in, because those locations change. Their answer for servers that genuinely cannot face the world is DNS-01, where control is proven through a TXT record and the web server never has to be reachable.

Sectigo publishes the failure list for the same requirement, and it reads like a checklist of things people actually do:

• Geo-restricted access to HTTP endpoints.
• Static firewall rules that only allow a known list of CA validation IPs.
• Blocked or filtered User-Agent headers.
• DNS responses that differ depending on where the query comes from.
• Short-lived DCV DNS records or HTTP files removed too early.

Split-horizon DNS is the sneaky one on that list. If your internal view answers the challenge and your public view does not, the primary lookup can succeed while remote perspectives see nothing. And if you are issuing for a certificate with several SANs, every name gets validated independently, so the number of requests multiplies per certificate.

The honest scope statement is this: multi-perspective validation has been mandatory for every public CA since September 2025 and the floor keeps rising. If your renewal pipeline survived 2024 and 2025 unchanged, your DNS and HTTP answers are already consistent from several continents. November 10 adds two more.

⏱️ This Lands in the Middle of the Lifetime Squeeze

Let’s Encrypt’s own roadmap, published in December 2025, cuts certificate lifetimes in stages. The opt-in tlsserver profile moved to 45-day certificates on May 13, 2026. The default classic profile becomes 64-day certificates with a 10-day authorization reuse period on February 10, 2027, then 45-day certificates with a 7-hour reuse period on February 16, 2028.

That last number changes the failure model. A 30-day reuse window used to hide a single bad validation: you could fail a challenge, retry later, and still issue from cached authorization. At 7 hours there is no hiding. Every request revalidates from scratch, from six remote perspectives, on a domain that renews every 45 days. More renewal events, less reuse to absorb a failure, more networks that each have to agree. Any one of those is survivable. All three at once is how you discover your firewall rules during an outage instead of during a test.

🛠️ What I Would Do Before November 10

Use the staging window. Let’s Encrypt switches staging to the new regions on October 27, which gives you two weeks to break things safely. Point one non-critical certificate at staging and watch a full issuance, not just a dry run.

Then test the thing that actually matters: whether /.well-known/acme-challenge/ is reachable from outside your country. Any public HTTP checker will do, or two cheap VPSes in different regions if you want to be precise. If the answer differs by location, you already know how this ends.

Audit for location-dependent answers, not just blocked ports. Split-horizon DNS, CDN rules that serve a different origin per region, WAF rules keyed on User-Agent, and rate limits that treat seven rapid challenge requests as an attack all fail this test while looking healthy from your laptop. Check your CAA records in the same pass: missing or inconsistent CAA answers fail issuance even when the challenge itself is served correctly.

Alert on renewal failure, not certificate expiry. A 90-day certificate that fails to renew at day 60 gives you a 30-day silent window, and most monitoring only fires when the expiry date is close.

And if the server genuinely should not be on the public internet, move to DNS-01 now. It is more setup, the credentials are scarier, and it is still the right answer for anything behind a country-level allowlist.

🧠 Final Thoughts

The visible change is seven requests instead of five. The change that matters is that domain control is now a distributed systems problem, and your certificate depends on six networks in different jurisdictions agreeing about what your DNS and your web server said.

I think this is a good trade. BGP is still not secure, RPKI filtering is only recommended for validation infrastructure rather than required, and the cheapest realistic defense against a hijack-based misissuance is to make the attacker own more than one path. Six perspectives plus a two-dissent quorum does that, while keeping room for the fact that the internet is genuinely inconsistent at the edges.

Where I push back is the “little to no impact” line. It is accurate as an average and useless as advice, because impact is not distributed evenly. If your setup answers the same everywhere, you will never notice. If it does not, November 10 is the day you find out, and the failure will look like a renewal error at 3am rather than the firewall rule you wrote three years ago.

Test it during the staging window while a failure still costs you nothing.

Thanks for reading.