MPIC: Why Domain Validation Now Fails From Places You Don't Serve

What MPIC actually is

MPIC is a second opinion, taken several times, from far away. When a CA validates that you control a domain, one machine on the CA's network — the Primary Network Perspective — performs the check. MPIC requires that determination to be corroborated by additional machines on unrelated networks before a certificate can be signed. The same applies to the CAA lookup that decides whether that CA is permitted to issue for your domain at all.

The Baseline Requirements are specific about what counts as a different place. Two perspectives are distinct only when the straight-line distance between them is at least 500 km. The DNS resolvers matter too: a resolver need not sit next to the perspective using it, but it must be in the same Regional Internet Registry service region, and any two resolvers used in one corroboration attempt must themselves be 500 km apart. Results may not be cached or shared between perspectives either, which is the point — a shared DNS cache would let an attacker who poisoned one perspective poison all of them.

Everything here happens on the CA's side. You cannot configure MPIC, opt into it, or ask for it to be relaxed, and no ACME client setting influences it. Your only involvement is involuntary: your infrastructure either gives every perspective the same answer or it does not.

The attack it was built to stop

MPIC exists because domain validation used to be defeatable by anyone who could bend internet routing for a few minutes. In an equally-specific prefix BGP attack, an adversary announces a route for a victim's address range that competes with the legitimate one. Routing being what it is, some parts of the internet believe the forged announcement and some do not. The attacker does not need to fool the whole world — historically, fooling the single network the CA validated from was enough to obtain a genuine, publicly trusted certificate for a domain someone else owned.

Checking from several unrelated vantage points raises that bar sharply, because a partial hijack that convinces one region tends not to convince the others. The Baseline Requirements say as much in the section's opening line: the process is there to improve protection against equally-specific prefix BGP attacks or hijacks. It is worth being precise about the ambition. MPIC makes this class of attack much harder to pull off unnoticed; it does not make it impossible, and the rule is written as corroboration, not proof.

That framing explains the design choices that follow. The 500 km rule, the ban on shared caches, the requirement that perspectives span multiple registry regions: each closes a way for one localized piece of network control to speak for the whole internet.

How many perspectives, and since when

As of August 2026, a CA must corroborate from at least four remote perspectives, and from at least five once December 15, 2026 arrives. The floor has risen four times: two remote perspectives from March 15, 2025, still two but with the quorum made binding from September 15, 2025, three from March 15, 2026, four from June 15, 2026, and five from December 15, 2026. These are minimums, and a CA may run more.

Two of those dates changed the character of the rule, not just its arithmetic. On September 15, 2025 the quorum became mandatory: during the first six months a CA was permitted to proceed with issuance even when too many perspectives failed to corroborate, and after that date it must not. Anyone who assessed their exposure during the soft-launch window measured a rule that was not yet enforced.

The second is easy to overlook. Since March 15, 2026 the corroborating perspectives must fall within the service regions of at least two distinct Regional Internet Registries. There are five registries covering the world between them, so the requirement guarantees the checks arrive from genuinely different parts of the planet, not from several data centers in one well-connected corner of it. If your infrastructure treats one continent differently from another, that clause turned a probability into a certainty.

One allowed disagreement, however many checks

A CA running between two and five remote perspectives may proceed when exactly one of them fails to corroborate. Six or more perspectives allow two. That is the entire Quorum Requirements table — two rows, no scaling, no proportion. The allowance depends on which band the CA's perspective count falls into, not on how many checks it ran.

Put the table next to the timeline and something falls out that the rule never states directly. The mandated minimum has climbed from two to five, and every one of those values sits inside the first band. So the tolerance has been one non-corroboration throughout, while the number of independent opportunities to produce one has gone from two to five. A domain with a single regionally inconsistent quirk was at worst a coin-flip against a two-perspective check in early 2025. Against five perspectives on two continents, the same quirk is far more likely to be caught — and one more quirk alongside it now stops issuance outright.

There is a counterintuitive consequence for CAs, too. Adding a sixth perspective costs a CA more checks but buys a second allowed failure, which makes six a materially more forgiving configuration than five. Since the requirement is a floor rather than a target, it is reasonable to expect CAs to settle on six once December arrives. That is a prediction and not a rule. Confirm it with your CA before you plan around it.

Why issuance fails when your server is fine

Validation fails under MPIC when your infrastructure gives different answers to different askers. Your server can be correctly configured, your DNS record can be exactly right, and your own checks from the office can all pass, while a perspective in another region receives a refusal, a timeout, or a different record entirely. Corroboration compares answers; it has no way to distinguish a deliberate regional policy from an attack in progress.

Geo-blocking is the most common cause, and the most reasonable one to have arrived at innocently. Plenty of organizations restrict HTTP access to the countries they operate in, and that worked fine when validation came from one predictable network. Firewall rules built around a CA's known validation IP addresses have the same shape: correct under single-perspective validation, actively harmful now that the checks come from infrastructure whose addresses you were never given. Split-horizon and latency-based DNS produce the same failure one layer down, returning a different record set depending on where the query originated.

Two smaller causes are worth naming because they look like nothing. Rate limiting can drop the second, third and fourth near-simultaneous request for the same challenge path, since several perspectives ask at once, not one after another. And User-Agent filtering — a web application firewall configured to serve only recognizable browsers — refuses validation clients that do not present a familiar header. Both pass every test you would run by hand.

ACME deployments feel this more than most, because HTTP-01 depends on one path being reachable from wherever the question comes from. If you are running Certbot or another ACME client in production, a renewal that has worked for two years can stop working without any change on your side, purely because the CA added a perspective in a region your edge refuses.

What to check before your next issuance

The check that matters is whether your validation path answers identically from several continents. Everything below is a way of asking that question, and all of it can be done before you place an order instead of after one stalls.

• Request the challenge path from outside your region. Fetch /.well-known/acme-challenge/test from hosts in North America, Europe and Asia-Pacific. A 403, a timeout, or a redirect to a country-specific site from any of them is your answer. Expect a 404 from a correctly configured server with no challenge in flight — that is a pass, not a failure.
• Resolve your DNS from several regions. Query your TXT, A and CAA records against resolvers on different continents and compare. Any difference in the records used for validation is a non-corroboration waiting to happen, and geo-aware DNS is easy to forget you enabled.
• Retire IP allowlists around validation. If your firewall or WAF permits only a fixed set of CA addresses to reach the challenge path, that list cannot be kept current — the perspectives are not published as a stable range, and the set grows every time the floor rises.
• Lift country blocking and User-Agent filtering on the validation path only. You do not have to open the whole site. Excluding /.well-known/ from geo rules and bot filtering keeps the rest of your policy intact.
• Check your CAA records resolve consistently. CAA is more forgiving — responses need not be byte-identical and an acceptable lookup failure can still corroborate — but a CAA record that appears in one region and not another is still a problem. Our guide to configuring CAA records covers the syntax and the common mistakes.
• Retry before you escalate. A CA may retry immediately, with the same method or a different one, and there is no cap on attempts. Genuinely transient causes such as slow DNS propagation in one region often clear on a second attempt, so a single failure is not yet a configuration problem.

One planning note. Domain validation evidence may be reused for 200 days for certificates issued on or after March 15, 2026, dropping to 100 days in March 2027 and 10 days in March 2029. Every reuse period that expires is another full corroboration attempt, so a configuration that fails MPIC will fail more often each year instead of holding at its current nuisance level.

What MPIC does not touch

MPIC governs issuance and nothing else. A certificate already installed keeps working until its own expiry date, whatever your infrastructure would tell a perspective in São Paulo today. There is no revocation trigger here, no browser-side check, and nothing a visitor could ever observe. The rule sits entirely between you and your CA, in the window before a certificate exists.

It is also confined to domain and IP validation and to CAA processing. The organization checks behind an OV or EV certificate — legal existence, registered address, signing authority — are validated through registries and phone calls, and no number of network perspectives has any bearing on them. Those run on a separate 398-day clock with its own failure modes.

What that adds up to is a problem with an unusually forgiving shape. It is invisible until you need a certificate, at which point it is urgent — but it is also entirely testable in advance, cheaply, by anyone with shell access in two regions. The organizations that get caught are the ones that find out during a renewal.