On 15 October 2026 Let's Encrypt announced that it is adding two more remote perspectives to domain validation. From the announcement: "During domain validation, this means that we will make seven total validation requests, one from the primary datacenter and six from remote perspectives (previously four)." And the rule that decides whether you get a certificate: "For validation to succeed, the primary server and a quorum of remote perspectives must receive the correct challenge response."
The dates: "Let's Encrypt will begin performing domain validation with the new regions in staging on Tuesday, October 27th, 2026. Assuming all goes well, we will do the production rollout on Tuesday, November 10th, 2026." Behind it sits a CA/Browser Forum requirement, which the announcement quotes: "Effective 2026-12-15, the CA MUST implement Multi-Perspective Issuance Corroboration using at least five (5) remote Network Perspectives… and the remote Network Perspectives that corroborate the Primary Network Perspective fall within the service regions of at least two (2) distinct Regional Internet Registries. If the requirements are not satisfied, then the CA MUST NOT proceed with issuance of the Certificate."
Let's Encrypt's own expectation, which this post is not going to write past: "We expect little to no impact to users." For almost everyone that is the whole story. This post is for the exception, because the exception finds out at the worst possible moment.
Why validation comes from more than one place
Domain validation is Let's Encrypt asking the internet "does this site really control this name?" by fetching a token from /.well-known/acme-challenge/ (or checking a DNS record) and seeing the expected answer. If that question were asked from one place only, an attacker who could hijack the route between that one place and your server — a BGP hijack — could answer it for you and obtain a certificate for your domain. Asking from several places on the internet at once, in different regions, makes that attack much harder: the attacker would have to hijack the view from a quorum of perspectives simultaneously. The announcement says it plainly: increasing the number and coverage of perspectives "improves visibility and protection against BGP attacks." Going from four remote perspectives to six, spread across at least two RIR regions, is that protection getting stronger.
The one failure mode
Let's Encrypt already validates from remote perspectives, so a site that renews fine today already passes with four of them. What changes in November is the quorum arithmetic: more perspectives, from more regions, have to see the right answer. The site that fails is the one that answers the challenge correctly for some of the internet and not the rest — and a site like that usually does not know it, because from its own network, and from the places it has tested, everything works.
The ways a site ends up in that position are ordinary ones:
- Geo-blocking. A firewall, CDN rule or WAF that drops traffic from countries you do not sell to. It also drops a validation request that happens to originate there.
- Source-IP allow-lists. Only your office and your monitoring vendor may reach the box. Let's Encrypt's perspectives are neither.
- Rate limiting that counts by path. Seven near-simultaneous fetches of the same URL from seven addresses can look like a scan to a rule that was tuned for one.
- Split-horizon DNS. The name resolves to one address inside your network and another outside, or to nothing at all from some resolvers. The perspectives use the outside view.
- Challenge paths that hit the app. If
/.well-known/acme-challenge/is proxied through to your application and the application answers with a login page, a redirect to HTTPS, or a 403, the token is never served.
None of these are new, and a site that passed four remote perspectives last month will usually pass six. The honest statement is narrower: a site that was borderline — passing from most regions, failing from one — now has more chances to be caught by the quorum, and from at least two RIR regions. That is the design working as intended, and it is also the thing to check before 10 November rather than after.
What to check, and when
- Fetch your challenge path from outside your own region. Not from your laptop, not from your office — from somewhere you do not control, in a different part of the world. A plain request to
http://yourdomain/.well-known/acme-challenge/anythingshould reach your web server and come back as a 404 or a token, over plain HTTP, without a redirect to a login or a 403. If it times out or is refused from one place and not another, that is the finding. - Stop filtering that path by source address or country. Whatever blocks you keep for the rest of the site, exempt
/.well-known/acme-challenge/from geo rules, IP allow-lists and per-path rate limits. The content there is a random token with no value to anyone else. - Use the staging window. Let's Encrypt is validating from the new regions in staging from 27 October. If you can issue a staging certificate for a test name, do it in that window: it exercises the new perspectives against your real network without touching production.
- If you cannot open port 80 to the world, use DNS-01. A DNS challenge is answered by your DNS provider, not your server, so the perspectives never need to reach your firewall at all. That is the right answer for internal-only hosts with public names.
- Know your renewal date. Validation only runs at issuance and renewal. A site that renews on 12 November meets the new perspectives on 12 November; one that renewed on 9 November meets them at its next renewal. Either way, a failure shows up in your ACME client's log, not on the site — until the certificate expires.
How this looks on DeployBase
For sites hosted with us, the pieces above are ours to keep right, so here is what the configuration actually says, read today rather than remembered. Port 80 on the edge is answered by nginx, and for every hosted domain the path /.well-known/acme-challenge/ is passed straight to Traefik's built-in ACME client, which issues certificates from Let's Encrypt's production endpoint with the HTTP-01 challenge. The config comment on that block says it must not redirect, and it does not: the token is served before any tenant web server or application sees the request, so an app's login page or HTTPS redirect cannot get in the way. Wildcard certificates use the DNS-01 challenge instead. There is no country rule in the firewall and no source-IP allow-list on port 80. The edge rate limit is twenty requests a second per client with a burst of forty, and the intrusion-prevention jail only bans an address after ten rate-limit hits inside sixty seconds; seven single requests from seven different addresses do not come near either. We fetched the challenge path on a hosted domain from outside the server while writing this: it reached the edge and answered 404 for an unknown token, which is the right answer. That is not a promise that nothing can ever go wrong with issuance; it is the current configuration, stated so that it can be checked against the behaviour you see.
The announcement ends with "Happy issuance!" — and for nearly everyone it will be. The point of writing this up is the small set of sites for which it will not, and the fact that they can find out this week, from the outside, instead of on renewal day.