The quorum went up in June and nobody told your firewall
Sometime in June, the number of places your certificate authority checks you from went from three to four. No ACME client changelog mentioned it. Nothing in your own deploy changed. But if your web server answers differently depending on where the request comes from, your next renewal is now riding on four separate network vantage points agreeing, and only one of them is allowed to disagree.
This is Multi-Perspective Issuance Corroboration. MPIC. It has been tightening quietly for over a year, and it is the reason a renewal that worked every ninety days for a decade can fail with an error that has nothing to do with your ACME client and everything to do with a firewall rule someone added in 2022.
What MPIC actually does
A CA used to validate domain control once, from one place. Send the HTTP-01 request, read the token back, issue. The weakness there is BGP. An attacker who can hijack the route to your IP from a single vantage point satisfies that one check and walks away with a real certificate for your domain. Researchers showed this working against production CAs in 2018 and 2019, and the industry eventually moved.
MPIC is the response. On top of its own check, the one the CA runs from what it calls the Primary Network Perspective, it re-runs your domain control validation and your CAA lookup from a set of remote perspectives scattered around the internet. Those results have to line up. If too many of the remote perspectives can't reach you, or see something different from what your primary check saw, the CA does not issue. A route hijack local to one region stops being enough, because now the attacker would have to hijack the path as every perspective sees it, all at once.
The rule comes from CA/Browser Forum ballot SC-067v3, which passed on July 22, 2024 and became mandatory for every publicly trusted CA on March 15, 2025. Since then the bar has kept climbing.
The schedule, and where the dates get fuzzy
The number of perspectives that have to corroborate goes up in steps. Here is the shape of it, using DigiCert's published implementation as the reference:
- March 2025. Validate from multiple network locations, no fixed quorum yet.
- September 2025. At least two remote perspectives must corroborate, one allowed to fail.
- February 2026. At least three remote perspectives, across at least two different Regional Internet Registry (RIR) regions.
- June 2026. At least four remote perspectives, still across two or more RIR regions.
- December 2026. At least five remote perspectives.
One non-corroboration is tolerated at each step. That single bit of slack is the only reason one flaky vantage point doesn't take you down on its own.
Be careful with the exact dates. The CA/Browser Forum sets the schedule in the Baseline Requirements, individual CAs have published slightly different day-of-month cutovers for each phase, and the list above is DigiCert's. Let's Encrypt has run five perspectives since 2024 and also tolerates a single failure. If you need the precise day a specific CA tightened, read that CA's own notice rather than any summary, this one included. What nobody disputes is the direction. More perspectives, more geographic spread, every few months through the end of 2026.
Why this breaks setups that worked last year
Here is what makes MPIC different from every other certificate change of the last two years. It does not care about your certificate, your key, or your ACME client. It cares whether your server looks the same to the whole planet. Plenty of infrastructure is built on purpose so that it doesn't.
Split-horizon DNS is the classic case. Your authoritative nameserver hands one answer to internal resolvers and another to the outside world, or a different answer depending on where the query comes from. For DNS-01 that means the TXT record a remote perspective reads may not be the one your ACME client just published. For any challenge type it means the A record four perspectives resolve could point four different ways.
Then there is geo-fencing. Teams block traffic from regions they don't sell into. A blanket firewall drop on a range of APAC prefixes. A WAF rule that throws a challenge at anything coming from a data-center ASN. A cloud security group scoped to a handful of countries. Every one of those is now a bet on issuance, because the CA's remote perspectives sit in exactly the places you're dropping, and they usually arrive from cloud provider IP ranges that your bot mitigation already treats as hostile.
HTTP-01 is where it bites hardest
HTTP-01 needs your token readable over port 80 from the perspectives the CA uses. Not most of them. Enough to make quorum, with one failure of headroom. If your CDN or WAF answers a request from a cloud ASN in Singapore with a 403 or an interstitial challenge page, that perspective fails to corroborate, and with the bar at four you have very little room left.
The Let's Encrypt error for this is worth committing to memory, because it sends people chasing the wrong thing every time:
During secondary validation: Remote PerformValidation RPC failed
That is not your ACME client breaking. That is a remote perspective failing to see what your local one sees. Let's Encrypt is blunt about the fix in their own multi-perspective validation and geoblocking FAQ: don't geoblock the requests used to validate your domain. Their minimum ask for HTTP-01 is worldwide access on port 80 to the /.well-known/acme-challenge/ path. Port 443 can stay as locked down as you want. It is port 80, and that one path, that have to be reachable from everywhere.
DNS-01 is not automatically safe
The reflex fix is to switch to DNS-01 so the web server can stay firewalled. It works, and Let's Encrypt recommends exactly that for geo-restricted origins, because DNS-01 only needs your DNS answerable worldwide rather than your HTTP endpoint. It moves the problem though. It doesn't delete it.
If your DNS is itself region-aware, through GeoDNS, split-horizon, or a provider that serves different records by location, then the remote perspectives can fail the TXT lookup just as easily as they failed the HTTP fetch. Anycast helps, because every perspective hits a nearby node carrying the same zone. That only holds if all your nodes actually have the fresh _acme-challenge record before validation runs. Propagation lag across an anycast fleet is its own MPIC failure mode, and it is a mean one, because it comes and goes.
This is the same reachability trap that shows up when your certificate works fine except from one region. The difference is that now it fails issuance, not just a monitoring probe.
How to tell if MPIC is what's failing you
First, confirm the failure is geographic and not local. A curl from your laptop will happily succeed while a perspective in another RIR region fails, so testing from one spot proves nothing.
Check the challenge path over plain HTTP, and check both IP families, because perspectives use both and a broken AAAA record fails silently:
# is the challenge path reachable at all, over port 80
curl -sv http://example.com/.well-known/acme-challenge/test 2>&1 | grep -E "< HTTP|Connected"
# IPv4 vs IPv6 - a dead AAAA record fails from perspectives that prefer v6
curl -4 -sI http://example.com/.well-known/acme-challenge/test
curl -6 -sI http://example.com/.well-known/acme-challenge/test
For DNS-01, query the record from resolvers on different continents and compare what comes back:
dig +short TXT _acme-challenge.example.com @1.1.1.1
dig +short TXT _acme-challenge.example.com @8.8.8.8
dig +short TXT _acme-challenge.example.com @9.9.9.9
Different answers, or a record present at one resolver and missing at another, is your smoking gun. MPIC corroborates the CAA lookup too, so check that from more than one place as well:
dig CAA example.com +short
A CAA record that resolves for you but not for a remote perspective kills issuance before the challenge even starts. If you're hazy on which lookups happen when, the difference between DNS and HTTP validation is worth a re-read, because MPIC sits on top of both of them.
What to actually change
Open port 80 to the world for the ACME challenge path, and stop treating cloud provider ranges as automatically hostile on that path. If your bot mitigation challenges data-center ASNs, carve out /.well-known/acme-challenge/ as an exception, or serve that endpoint from somewhere your WAF isn't sitting in front of.
If the origin genuinely has to stay geo-restricted, move to DNS-01 and make sure the TXT records reach every node before your client tells the CA to go. Put a real propagation check in the renewal, not a hopeful sleep 30.
And watch the renewal itself, not the certificate's expiry date thirty days downstream. MPIC failures are intermittent by nature. One perspective flakes, the renewal fails, the old certificate keeps counting down, and nobody notices until the morning it actually expires. Alert on the failed attempt.
Frequently asked questions
Does MPIC apply to every CA or just Let's Encrypt? Every publicly trusted CA. It's a CA/Browser Forum Baseline Requirement from ballot SC-067v3, mandatory since March 15, 2025, so DigiCert, Google Trust Services, Sectigo and the rest all run it. Let's Encrypt is just the CA whose error messages you've probably already seen.
How many perspectives have to agree right now? As of mid-2026 the bar is four remote perspectives across at least two RIR regions, with one allowed to fail, rising to five in December 2026. The exact cutover dates differ slightly between CAs, so check your own CA's published schedule rather than trusting a summary.
Can I just whitelist the CA's validation IP addresses? No, and that's the whole point. The perspectives are spread across the internet on purpose and they change over time, and Let's Encrypt doesn't publish a stable list to allowlist. The supported answer is to make the challenge path reachable everywhere, or to use DNS-01 so only your DNS has to answer worldwide.
Will switching to DNS-01 make this go away? It removes the HTTP reachability problem, which is the common one. It won't help if your DNS answers differently by region, or if your anycast nodes don't all carry the challenge record in time. GeoDNS and split-horizon zones can fail MPIC on the DNS side just as readily.
Why did a renewal that worked for years suddenly fail? Almost always because the quorum went up, not because you changed anything. Each phase of the schedule adds perspectives and geographic spread, so a setup that scraped past three checks can come up short at four. The GeoDNS or firewall rule that's biting you now may have been sitting there untouched for years.
