Here’s a fact that should bother you more than it does: for most of the history of the web PKI, an attacker who could bend an internet route for about thirty seconds could get a real, browser-trusted TLS certificate for a domain they didn’t own.
Not a self-signed cert. Not something that trips a warning. A genuine certificate from a genuine certificate authority, indistinguishable from the real one, that every browser on earth would show a padlock for. And the technique didn’t require breaking any crypto. It required lying to the CA about where a route goes.
Domain validation is just a network request that trusts the answer
When you ask a CA for a certificate, it has to confirm you actually control the name. This is domain control validation, and in practice it’s one of a small handful of checks: put a specific token at http://example.com/.well-known/acme-challenge/… and let the CA fetch it (HTTP-01), or publish a TXT record with a token and let the CA look it up (DNS-01). The CA also reads your CAA record to see whether you’ve authorized it to issue at all.
Every one of those is the CA making a network request from its own location and believing whatever comes back. That’s the soft spot. The CA isn’t verifying some deep truth about ownership — it’s verifying that whoever answered from the CA’s vantage point could produce the token. If you can make the CA’s request land on your server instead of the real one, you answer the challenge, and the CA issues. It has no way to tell the difference.
Enter BGP, the protocol that runs on trust
The internet decides where packets go using BGP, and BGP has no built-in notion of whether an announcement is legitimate. A network can announce “traffic for this address block should come to me,” and by default its neighbors believe it. This is how the famous accidental outages happen — a misconfigured router in one country swallows traffic for a service on another continent. It’s also a weapon.
If you can announce a more specific route for the real server’s IP — even briefly, even to just the part of the internet the CA sits in — the CA’s validation request follows your hijacked route to your machine. You serve the token. The CA sees a passing check and mints the cert. The real owner never notices, because the hijack only needs to fool the CA, only for the seconds the validation takes.
This wasn’t theoretical. Researchers at Princeton spent years documenting exactly this class of attack against domain validation, including ethically conducted real-world BGP hijacks. The uncomfortable takeaway from their work: a single-vantage-point CA is a single point of failure, and the attack surface is the entire global routing table.
The fix is embarrassingly simple in hindsight
If the problem is that the CA looks from one place, look from several.
That’s the whole idea behind multi-vantage-point validation. Instead of validating a domain from one network location, the CA runs the same check from multiple, network-diverse vantage points at once and requires them to agree. A local BGP hijack might fool the route as seen from Virginia, but not the route as seen from Frankfurt and Singapore and São Paulo simultaneously. To beat it, an attacker now has to hijack the route as observed from every perspective at the same time — which is dramatically harder, loud, and far more likely to be someone else’s problem before it’s yours.
Let’s Encrypt shipped this in production in February 2020, built in collaboration with those same Princeton researchers, and it covered issuance for more than half a billion certificates in its first year. Because the vantage points are cloud-hosted and queried in parallel, the latency cost is essentially nothing — the extra checks finish about as fast as the original one. And the security payoff was measurable, not hand-waved: in the researchers’ testbed, five of six simulated hijack attacks succeeded against a single-vantage-point CA; under Let’s Encrypt’s multi-vantage-point deployment, only one of the six got through.
One of six is not zero. Hold that thought.
In 2025 it stopped being optional
For five years this was a thing the good CAs did and the rest didn’t. That changed. The CA/Browser Forum — the body where browser makers and CAs hammer out the rules everyone trusted to issue must follow — adopted ballot SC-067, which requires domain validation and CAA checks to be performed from multiple network perspectives. The industry gave it a suitably bureaucratic name, Multi-Perspective Issuance Corroboration, MPIC.
The rollout was deliberately gradual so CAs could tune their implementations without breaking legitimate issuance. It moved from a recommendation to a requirement on March 15, 2025, starting with a couple of perspectives, and the quorum rules tightened through the year, with September 15, 2025 as the milestone where corroboration became genuinely enforced. The model isn’t “all perspectives must agree” — that would fail too many legitimate requests where one vantage point has a transient routing blip. It’s a quorum: enough perspectives have to corroborate, with a small, scaled allowance for dissent. Agreement from the crowd, not unanimity.
What matters is that it’s no longer a competitive nicety. If a publicly trusted CA issues you a cert now, it corroborated your domain from multiple places to do it. The single-vantage-point era is over by rule, not just by good practice.
What it doesn’t fix, because nothing is free
I’d be doing the same thing I criticize others for if I sold MPIC as a solved problem. It isn’t.
It raises the cost of the attack; it doesn’t eliminate it. An adversary who can pull off a global route hijack — one that reroutes the path as seen from every vantage point at once — can still fool a quorum. That’s much harder and much rarer, but “harder” is the honest verb, not “impossible.” That leftover one-in-six is where the remaining risk lives.
MPIC also only defends the network path to your infrastructure. It does nothing about the other ways domain validation gets subverted: a hijacked registrar account, a dangling DNS record pointing at infrastructure someone else can claim, a compromised DNS provider. If the attacker controls your actual DNS or your registrar login, they don’t need to hijack a route — they are the authoritative answer, from every perspective. And the real long-term fix for BGP itself, RPKI-based route origin validation, is a separate and still-incomplete effort. MPIC is a workaround that assumes routing can be lied to, because it can.
The pattern is the point
Strip away the acronym and MPIC is the same move the web already made once, with Certificate Transparency: stop trusting a single observation, and make issuance corroborate. CT said no certificate should exist in secret. MPIC says no validation should be believed from one viewpoint. Both are admissions that any single source — one log, one vantage point, one CA looking from one place — is a thing an attacker can get between you and.
That’s not a PKI insight. It’s a general one, and most of security keeps relearning it the hard way. The moment your assurance depends on one observation, someone will find a way to sit in front of it. The defense is almost never a cleverer single check. It’s more than one set of eyes, and the discipline to require that they agree.
For twenty years, the certificate that vouched for your site’s identity could be forged by lying to one machine about a route. The fix wasn’t better crypto. It was refusing to trust a single point of view.