Let's Encrypt moves to six remote validation perspectives ahead of a December deadline
Each certificate validation will now make seven requests: one from the primary datacenter and six from remote vantage points.
Let's Encrypt is adding two remote perspectives, raising the total from four to six, to meet CA/Browser Forum rules that take effect December 15, 2026 and call for at least five. The point is to make BGP hijacks of domain validation harder.
Staging starts October 27 and production rollout is planned for November 10.
What changes
Let's Encrypt announced it is adding two remote perspectives for domain validation, taking the total from four to six. Each validation will make seven requests, one from the primary datacenter and six from remote perspectives. For success, the primary server and a quorum of remote perspectives must receive the correct challenge response.
Why now
The CA/Browser Forum Baseline Requirements (section 3.2.2.9, Multi-Perspective Issuance Corroboration) take effect December 15, 2026 and call for at least five remote perspectives. More vantage points make it harder for an attacker who hijacks routes with BGP to fool validation from one network location.
Dates and impact
- October 27, 2026: validation with the new regions begins in staging.
- November 10, 2026: production rollout, if staging goes well.
Let's Encrypt expects "little to no impact to users." If your firewall or geo-blocking allowlists validation traffic by source, check for the new regions during staging.
An August hijack beat multi-perspective checks, and the thread disputes why
A cloudpunk.blog write-up describes a 33-hour hijack of Hetzner-hosted address space in late August that produced a valid certificate for virtualizor.com despite multi-perspective validation:
"if the network as a whole thinks the destination is someplace else then all those paths will lead to the same (false) location." — a commenter citing the cloudpunk.blog write-up of the Hetzner hijack
Another commenter contested its claim that the route was RPKI-invalid:
"The route hijack was RPKI valid because they spoofed Hetzner's AS into the AS_PATH and Hetzner used a max length of /24 on the ROA" — a commenter who cited bgp.tools ROA history for the prefix
More vantage points raise the bar for path attacks but do not cover a hijack of the destination itself. Per the thread, the owner-side controls are a ROA max length that matches your announced prefixes, and CAA records.
Get breakdowns like this every day
The top Hacker News stories, unpacked — by email, Telegram, or RSS.
A honeypot caught Plex servers being hacked to mine Monero
Attackers send crafted requests to the player timeline endpoint, and the server fetches and runs their code.