Multi-Perspective Issuance Corroboration Explained: How CAs Outvote BGP Hijacks

An attacker who can redirect internet traffic meant for your server can pass the check and get a real certificate for your domain. While the hijack lasts, visitors it captures see the attacker's copy of your site with a valid padlock. Multi-perspective issuance corroboration is the rule that makes this attack much harder.

Picture a common setup. A small online store runs on one cloud server in Mumbai at shop.example.com. An ACME client on that server, the small program that orders and renews certificates, renews its Let's Encrypt certificate automatically. The setup is made up, but both problems below follow directly from published rules.

To issue a certificate, the CA gives the client a random token. The client puts the token in a file on the web server. The CA then fetches that file over the internet, and if the token is there, it accepts that the store controls the domain.

Now suppose a network elsewhere falsely announces that it can deliver traffic for the store's IP addresses. If the CA's network believes that announcement, the CA's request lands on the attacker's server. The attacker placed the certificate order, so the attacker has the token, serves the file and gets the certificate.

This has happened. On 3 February 2022 attackers hijacked the routes to developers.kakao.com, which the Korean crypto exchange KLAYswap loaded a script from. Princeton researchers report that the attackers got a certificate for that name from ZeroSSL, served malicious code and stole about 2 million US dollars.

The store also has a quieter problem. Its owner blocked all non-Indian IP addresses at the firewall to cut bot traffic. Once CAs check from several continents, that block can stop renewals. Both problems come from the same rule.

• Certificate authority (CA): a company that browsers trust to issue HTTPS certificates, such as Let's Encrypt.
• Domain validation: the CA's test that you control a domain name before it issues a certificate for it.
• ACME: the protocol that clients such as Certbot use to order certificates automatically. Its HTTP-01 challenge puts a token file on your web server; DNS-01 puts a TXT record in your DNS.
• BGP (Border Gateway Protocol): how networks tell each other which blocks of IP addresses, called prefixes, they can deliver traffic to.
• BGP hijack: a network announces a prefix it does not own, so some traffic for those addresses flows to it instead.
• Network perspective: one place on the internet from which the CA sends its checks. The primary perspective is the CA's main checker; remote perspectives are the extra ones.
• CAA record: a DNS record where you list which CAs may issue certificates for your domain.
• Regional Internet Registry (RIR): one of five bodies that hand out IP addresses for a world region. India falls under APNIC, which serves 56 economies in Asia and the Pacific.

Multi-perspective issuance corroboration is a rule for CAs: repeat each domain check from several distant networks, and issue only if enough of them see what the main check saw. Corroboration simply means confirming with independent evidence.

The rule lives in section 3.2.2.9 of the Baseline Requirements. These are the CA/Browser Forum's rules for publicly trusted TLS certificates, and browser root programs such as Mozilla's require CAs to follow them. Ballot SC-067 added the section in 2024.

MPIC covers two checks. The domain control check confirms the token. The CAA check confirms that your CAA record allows this CA. Both need a quorum, which is the minimum number of remote perspectives that must agree with the primary.

Think of a bank confirming your home address by sending couriers from several cities with the same sealed question. A crook who bribes one city's sorting office can intercept that courier. Couriers from far-away cities still reach your real door. The bank is the CA, the address is your domain and each courier is a perspective. The sorting office is routing on one part of the internet, and the crook is the hijacker.

Where the picture breaks: some hijacks are global. A more specific route announcement can pull traffic from almost every network at once, which is like bribing the whole postal system. MPIC does not help there, and a later section shows why.

The CA checks from its primary perspective, repeats the check from each remote perspective, counts the agreeing ones and issues only if the count meets the quorum. Here is one renewal for the store using HTTP-01.

1. 1

   Order

   The ACME client asks the CA for a certificate for shop.example.com. The CA replies with a random token.

2. 2

   Publish

   The client writes the token, joined to a fingerprint of its account key, to a file under /.well-known/acme-challenge/ on port 80.

3. 3

   Primary check

   The CA's primary perspective fetches the file and looks up the CAA record. In Let's Encrypt's software, remote checks start only after this passes.

4. 4

   Remote checks

   Each remote perspective fetches the same file and does its own DNS lookups. The rules forbid sharing results or a DNS cache, so one poisoned lookup cannot spread.

5. 5

   Count

   The CA counts remote perspectives that saw the same token and found permission in CAA. The agreeing ones must sit in at least two RIR regions.

6. 6

   Decide

   If the quorum holds, the CA issues. If not, it must refuse. It may retry at once, but it cannot reuse votes from the failed attempt.

To agree, a remote perspective must observe the same token as the primary. For CAA, it must read the record as permission to issue, even if its answer is not byte-for-byte identical to the primary's. The same rule covers DNS-01 and TLS-ALPN-01, a check done inside a TLS connection on port 443.

On 15 December 2026 the last phase starts: every publicly trusted CA needs at least five remote perspectives. The agreeing ones must span two RIR regions, and if the quorum fails, the CA must not issue. Earlier phases tightened the rule one step at a time.

How many perspectives may fail?

The quorum table allows one failed remote perspective when a CA uses two to five, and two when it uses six or more. Perspectives only count as separate when they are at least 500 km apart.

What Let's Encrypt is changing

Let's Encrypt's announcement of 15 October 2026 says each validation will make seven requests: one from its primary data centre and six from remote perspectives. The primary and a quorum of the remotes must see the correct response.

The post says it expects little to no impact on users. It does not say where the new perspectives are or which networks host them. Six is one more than the minimum, and the quorum table lets six perspectives tolerate two failures where five tolerate one.

Beginners can stop here. You know what MPIC is, why it exists and what changes on 15 December 2026. The rest is for engineers: which hijacks lose the vote and which win, how to keep renewals working, and what the real code does.

MPIC defeats a hijack that reaches only part of the internet. Perspectives outside that part still reach the real server, which has no token file because the store never placed this order. They disagree, and the quorum fails.

Two kinds of hijack behave differently

In an equally-specific hijack, the attacker announces exactly the same prefix as the victim. Each network picks one of the two routes, so only part of the internet goes to the attacker. This is the attack MPIC is built for.

In a sub-prefix hijack, the attacker announces a smaller block inside the victim's prefix. Routers prefer the most specific match, so nearly all traffic goes to the attacker. The 2018 Princeton paper that demonstrated these attacks says multiple vantage points are effective against attacks without a global effect. Sub-prefix hijacks have one.

One detail limits sub-prefix hijacks. The same paper notes that most networks drop announcements for blocks smaller than a /24, a block of 256 addresses. So a server in a /24 prefix is largely out of reach of sub-prefix hijacks, though an equally-specific hijack of that /24 is still possible.

RPKI route origin validation helps against sub-prefix hijacks when the address owner's records forbid smaller announcements, and SevyDevy's RPKI guide explains how. The Baseline Requirements recommend, but do not require, that perspectives use networks that drop RPKI-invalid routes.

The model below applies the quorum table and the two-registry rule to six remote perspectives. It is a teaching model, not any CA's code, and the region of each perspective is made up because Let's Encrypt does not publish them. It runs on any Python 3.

# A model of the quorum rule in Baseline Requirements section 3.2.2.9.
# It is not any CA's real code, and the regions below are made up.

def allowed_failures(remote_count):
    # Quorum table: 2-5 remote perspectives may have 1 failure, 6 or more may have 2.
    return 1 if remote_count <= 5 else 2

def corroborated(primary_ok, remotes):
    # remotes is a list of (region, passed) pairs, one per remote perspective.
    if not primary_ok:
        return False
    passed_regions = [region for region, ok in remotes if ok]
    failures = len(remotes) - len(passed_regions)
    enough = failures <= allowed_failures(len(remotes))
    two_registries = len(set(passed_regions)) >= 2
    return enough and two_registries

regions = ["ARIN", "ARIN", "RIPE", "RIPE", "APNIC", "APNIC"]

def run(label, primary_ok, passing):
    remotes = [(r, i in passing) for i, r in enumerate(regions)]
    print(f"{label}: {corroborated(primary_ok, remotes)}")

run("All six reach the server", True, {0, 1, 2, 3, 4, 5})
run("Firewall drops two perspectives", True, {0, 1, 2, 3})
run("Firewall drops three perspectives", True, {0, 1, 2})
run("Only APNIC perspectives get through", True, {4, 5})
run("Hijack fools primary and three remotes", True, {0, 2, 4})
run("Hijack fools primary and four remotes", True, {0, 1, 2, 3})

# Output when run:
# All six reach the server: True
# Firewall drops two perspectives: True
# Firewall drops three perspectives: False
# Only APNIC perspectives get through: False
# Hijack fools primary and three remotes: False
# Hijack fools primary and four remotes: True

So MPIC raises the price of an attack rather than making it impossible. To win against six remotes, a hijack must fool the primary and four remotes in two regions at the same moment.

What MPIC does not stop

• Global hijacks such as sub-prefix announcements, which fool every perspective at once. The Princeton researchers who helped design the approach warn that some BGP attacks can still fool all of a CA's vantage points.
• A takeover of your DNS provider or registrar account. The attacker then changes the real records, so every perspective honestly sees the attacker's answer.

It can, if your server or DNS answers some perspectives differently from others. To count, a remote perspective must see the same token as the primary, and after 10 November Let's Encrypt plans to check from seven places per validation.

Back to the store. Its firewall accepts port 80 only from Indian IP addresses, so perspectives outside India get no answer. Even if some perspectives sat in India, India is one RIR region and the agreeing ones must span two. So the renewal fails at any CA that follows the current rules.

Allowlisting the CA's addresses is not a way out. Let's Encrypt does not publish the IP addresses it validates from and says they change without notice. Its integration guide asks you to allow inbound port 80 for HTTP-01, and port 53 to your authoritative DNS servers.

How to check your setup before 10 November

Run these four checks. The first two run on the store's server. Run the curl line from machines on other continents, such as small cloud servers, because a test from inside your own network proves nothing about geo-blocking.

# 1. Which CAs may issue for your domain? Empty output means no CAA record at that name,
#    so also check the parent: CAs climb the name tree until they find one.
dig +short CAA shop.example.com
# 0 issue "letsencrypt.org"
dig +short CAA example.com

# 2. On the server: put a test file in the challenge folder (use your own web root).
sudo mkdir -p /var/www/html/.well-known/acme-challenge
echo mpic-test | sudo tee /var/www/html/.well-known/acme-challenge/mpic-test

# 3. From machines on other continents: can they fetch it over plain HTTP?
curl -s -o /dev/null -w "%{http_code}\n" http://shop.example.com/.well-known/acme-challenge/mpic-test
# 200

# 4. After 27 October 2026: rehearse a renewal against Let's Encrypt staging.
sudo certbot renew --dry-run
# Certbot 5.8.0 ends a good run with: Congratulations, all simulated renewals succeeded:

Expect your CA, such as letsencrypt.org, in the CAA answer for the name or its nearest parent that has one. If no level has a CAA record, CAA does not restrict issuance. Expect 200 from every outside machine. The dry run uses the staging server, which gets six remote perspectives on 27 October, and does not save a certificate.

Boulder, Let's Encrypt's open-source CA software, applies the quorum table almost line for line. We read its validation code at the version of 21 October 2026. These are undocumented details as of that date, not promises, so pin the version if you rely on them.

• The primary check runs first. Remote checks start only if it passes, which avoids wasted work.
• All remote perspectives are asked at once, in random order.
• Success needs the remote count minus the allowed failures, and passes from at least two RIRs. Each remote perspective is configured with one of the five RIR names.
• When a slow-perspective timeout is configured, slow perspectives get a shorter deadline once the outcome is certain.
• It refuses to validate with fewer than four remote perspectives, matching the June 2026 phase. The code comment beside that check already lists the five-perspective phase.
• It logs the result as a fraction such as 4/6. The Baseline Requirements ask CAs to record quorum results in that form.

Open MPIC for other CAs

Open MPIC, launched in 2024, is an open-source MPIC service with an API that any CA can run in its own cloud accounts. Its Python core sets the default quorum to the number of perspectives minus one, up to five, and minus two above five.

It also groups perspectives by RIR and, when more than two are used, requires passes from at least two RIRs. So both open-source implementations we read apply the same table and the same two-registry rule.

How much does this buy? A 2023 Princeton study measured resilience: the share of networks on the internet that could not get a certificate for a domain through an equally-specific hijack. Let's Encrypt's setup at the time scored a median of 88%, against 76% for a single vantage point.

The same study found that two more vantage points in different cloud providers could lift resilience above 97%. Let's Encrypt's 2026 announcement does not cite the study or name its new providers.

Frame MPIC as a trust problem in a distributed check: one observer can be lied to, so ask several independent observers and require a quorum. Then walk through these steps.

1. 1

   State the threat

   A BGP hijack lets an attacker answer the CA's domain check, because the attacker placed the order and holds the token.

2. 2

   Add independent observers

   Repeat the check from remote perspectives at least 500 km apart, each with its own DNS lookups and no shared cache.

3. 3

   Set the quorum

   Allow one failure for two to five perspectives and two for six or more, with agreement across two RIR regions.

4. 4

   Name the trade-off

   More perspectives catch more hijacks, but each one adds a chance that a flaky customer setup fails validation.

5. 5

   Name the limit

   Global sub-prefix hijacks and DNS account takeovers fool every perspective, so RPKI and registrar security still matter.