Seven requests where there used to be five
On Tuesday, November 10, every HTTP-01 challenge you answer for Let's Encrypt gets fetched seven times. Once from the primary datacenter, six times from remote perspectives. Until now there were four of those.
Let's Encrypt announced it on October 15 and expects "little to no impact to users." For most of you, fine. But if you geo-block at the edge, or put an aggressive WAF in front of /.well-known/acme-challenge/, you're flipping a coin you didn't know about. The two new perspectives are somewhere. Let's Encrypt won't say where. If somewhere turns out to be a region you block, your next renewal fails, and the error message points at your own server.
Staging has run six remote perspectives since October 27. That gives you a few days to break a test certificate before a production renewal breaks for you. (HN discussion.)
Why Let's Encrypt is doing this now
The Baseline Requirements force it. Section 3.2.2.9 of the CA/Browser Forum Baseline Requirements phases in Multi-Perspective Issuance Corroboration, and the last phase lands on December 15, 2026. From that day every publicly trusted CA must use at least five remote network perspectives, and the ones that corroborate the primary have to sit in at least two distinct Regional Internet Registry regions.
Let's Encrypt is at four. Five would have done. They went to six, and that number matters more than the headline does, for a reason buried in a table.
We covered the general mechanics of MPIC, and why it breaks setups, in our post on the four-network rule. This one is about November 10 and how to test for it.
The quorum math got looser and stricter at once
The BRs have a Quorum Requirements table with exactly two rows. With two to five remote perspectives, the CA may tolerate one that doesn't corroborate. With six or more, it may tolerate two.
Boulder, the software Let's Encrypt runs, implements that literally. From va/va.go:
func maxAllowedFailures(perspectiveCount int) int {
if perspectiveCount < 2 {
return 0
}
if perspectiveCount < 6 {
return 1
}
return 2
}
So today, with four remote perspectives, three have to see your token. From November 10 it's four out of six. Two can fail.
Read that both ways. One flaky perspective used to eat your whole margin. Now you can lose two and still get a certificate, which is good news if your failures were random: a timeout here, a dropped packet there.
If your failures are systematic, it's bad news. Say you block an entire region at the edge and one of the current four perspectives lives there. You pass at 3/4 and never notice. Now both new perspectives land in that same region. You're blocking three of six, and 3/6 fails. Your config didn't change. The CA moved.
There's a second rule stacked on top. Boulder also counts the registries of the perspectives that passed and wants at least two of them (requiredRIRs = 2, same file). Let only ARIN space through your firewall and you can collect four passes and still fail, because they all sit in one registry. That rule was already live. More perspectives just give you more ways to find out.
Other CAs will land on a different number
Every public CA has to reach five remote perspectives by December 15. A CA that stops at exactly five stays in the first row of the table. One failure allowed, four of five must pass. That's stricter than what Let's Encrypt is about to run. If you also buy certificates from DigiCert, Sectigo or Google Trust Services, expect their quorum to tighten in the next six weeks too. Their own notices have the dates. Don't guess them from ours.
Where this actually bites
Same places as always. Less room.
Country blocks at the CDN or WAF are the classic. Someone blocked a list of countries in 2022 to cut bot traffic, and validation requests come from cloud IP ranges in places you'll never sell to. Exempt the challenge path from geo rules entirely. Allowlisting won't work: Let's Encrypt doesn't publish its validation IPs and says they "may change at any time."
Bot protection that challenges cloud ASNs does the same damage more quietly. A JavaScript interstitial on /.well-known/acme-challenge/ answers with a 403, or with a 200 and the wrong body. Both count as a non-corroboration.
DNS-01 doesn't get you out of it. Each perspective uses its own resolver, in its own RIR region, at least 500 km from the others, with no shared cache. That's straight from the BRs. Seven lookups touch more of your provider's anycast nodes than five did. If one node lags, the extra headroom saves you. If a whole region lags, it won't.
And the perspectives corroborate your CAA records as well as the challenge. A broken DNSSEC chain that only some resolvers trip over shows up right here. DNSSEC is already a certificate dependency; November 10 adds two more resolvers that can notice.
Test it on staging, with a fresh account
"Just run a dry run" has a hole in it. Let's Encrypt caches authorizations per account for up to 30 days. If your staging account validated the name last week, the next staging order can skip validation entirely. You get a green result, and not one of the six perspectives ever touched your server.
So use a throwaway account. With certbot, point every directory at a scratch location:
SCRATCH=$(mktemp -d)
certbot certonly --staging \
--config-dir "$SCRATCH/config" \
--work-dir "$SCRATCH/work" \
--logs-dir "$SCRATCH/logs" \
--register-unsafely-without-email --agree-tos \
--webroot -w /var/www/html \
-d www.example.com
A new config dir means a new staging account. No cached authorizations, so every perspective has to fetch the token.
With acme.sh, a separate --home does the same:
acme.sh --home /tmp/acme-mpic-test --issue \
--server letsencrypt_test \
-d www.example.com -w /var/www/html
On Kubernetes, create a staging ClusterIssuer with its own account key secret, so cert-manager registers a fresh account:
apiVersion: cert-manager.io/v1
kind: ClusterIssuer
metadata:
name: letsencrypt-staging-mpic-test
spec:
acme:
server: https://acme-staging-v02.api.letsencrypt.org/directory
privateKeySecretRef:
name: letsencrypt-staging-mpic-test-account
solvers:
- http01:
ingress:
ingressClassName: nginx
Point a test Certificate at it and watch the Challenge resources. One that goes invalid with a secondary-validation error is your answer. If you've never walked the Order and Challenge chain, our cert-manager debugging guide does it step by step.
One caveat. Nothing guarantees staging's six perspectives sit where production's six will. It's the best preview you get. Treat it as that.
Read the error the CA gives you
When remote perspectives fail, Boulder puts a fixed prefix on the problem detail. A blocked HTTP-01 fetch looks like this:
During secondary validation: 203.0.113.10: Invalid response from
http://www.example.com/.well-known/acme-challenge/<token>: 403
"During secondary validation" tells you the primary perspective succeeded. Your server is up and the token was in place. Somewhere between a remote perspective and your origin, something said no.
And that IP address belongs to you. It's the address the perspective connected to. People lose whole afternoons chasing it as if it were the CA's.
Then find the requests in your logs. The validation User-Agent contains "Let's Encrypt validation server":
grep "Let's Encrypt validation server" /var/log/nginx/access.log \
| awk '{print $1, $9}' | sort | uniq -c
After November 10, a clean validation should show up to seven distinct source addresses per challenge. See fewer, or a 403 against some of them, and you know which ones your edge is eating. Team Cymru's whois service tells you the ASN and country of a source:
whois -h whois.cymru.com " -v 198.51.100.25"
Don't turn that output into an allowlist. It'll be wrong the next time Let's Encrypt moves a perspective, and they've just shown you they will.
November 10 is only the plan
The announcement says production flips on the 10th "assuming all goes well." The last time Let's Encrypt added perspectives, in 2024, staging was announced for March 6, actually switched on March 12, and production followed on March 27. That's no scandal. It does mean "nothing broke since the 10th" might only mean the change hadn't shipped yet.
The forum thread gets an update when production switches. Subscribe to it. If a renewal fails after that date with "During secondary validation" in the error and you changed nothing, you know where to look.
If your renewals run with no slack, a failed attempt on November 11 turns into an outage a few weeks later. Different problem, same week to fix it: check how your ACME client handles a failed renewal.
Frequently asked questions
Does this affect DNS-01 validation, or only HTTP-01? It affects every validation method Let's Encrypt uses. For DNS-01, each remote perspective queries your TXT record through its own resolver in its own region, so slow or inconsistent propagation across your DNS provider's nodes can still produce non-corroborations, and the CAA check is corroborated from the perspectives as well.
Can I allowlist Let's Encrypt's validation IP addresses? No. Let's Encrypt does not publish a list of validation IPs and says they can change at any time, and the two new perspectives show that they do. Exempt the challenge path from geo-blocking and bot rules so the source address stops mattering.
Why can Let's Encrypt now tolerate two failures when it used to tolerate one? The Baseline Requirements quorum table allows one non-corroboration for two to five remote perspectives and two for six or more. At six, Let's Encrypt moves into the second row, so four of six must agree. A CA that stops at five remote perspectives still allows only one failure.
Will my existing Let's Encrypt certificates stop working on November 10? No. The change only affects how new validations are performed, and certificates you already hold keep working until they expire. The risk sits at your next renewal, if that renewal needs a fresh validation and your edge blocks enough of the new perspectives.
How do I know a staging test really validated against all six perspectives? Use a fresh ACME account so no cached authorization gets reused, then check your web server access log for requests to the challenge path carrying the Let's Encrypt validation User-Agent. A full validation shows several distinct source addresses for a single token.
