BGP Hijacking Explained: How HTTPS Validation Can Be Attacked

And why Let’s Encrypt is moving toward validating domains from more locations.

Imagine someone obtaining a perfectly valid HTTPS certificate for your domain.

Your servers haven’t been compromised. Your private key hasn’t been stolen. Nobody has changed your DNS records.

Yet a trusted Certificate Authority (CA) has somehow been convinced that an attacker controls your domain.

Sounds strange?

The weakness may have nothing to do with your application, web server, or TLS configuration.

It could be hiding in the way the internet routes traffic.

This is where BGP hijacking becomes interesting. And it’s one reason Let’s Encrypt announced an important security improvement on October 15, 2026.

Let’s understand what happens, how attackers can exploit it, and what we can do about it.

First, what exactly is BGP?

The internet isn’t one giant network.

It’s thousands of independent networks connected to each other. Internet service providers, cloud providers, telecom companies, and large enterprises all operate their own networks.

These networks are called Autonomous Systems (AS).

And they need a way to tell each other how to reach different IP addresses.

That’s what Border Gateway Protocol (BGP) does.

Think of it like a navigation system for the internet.

When you want to visit a website, DNS helps your browser find the destination IP address. BGP helps the networks along the way decide how to reach that IP address.

For example, AWS might announce that a particular range of IP addresses can be reached through its network. Other networks learn about that route and propagate routing information to their neighbors.

The problem?

BGP was originally built around trust between network operators, not strong cryptographic verification of every routing announcement.

A network can announce routing information it shouldn’t. Depending on the receiving networks’ policies and security controls, that announcement may influence where traffic is delivered.

Sometimes this happens accidentally because of a routing misconfiguration.

Sometimes it is deliberate.

The latter is what we call BGP hijacking.

How does BGP hijacking work?

Suppose your application is running at api.example.com.

Your DNS records point to the correct IP address. Everything is working as expected.

Now imagine an attacker gains the ability to originate or propagate a misleading BGP route covering the IP address used by your application.

Some networks might accept the misleading announcement and start forwarding traffic through the attacker-controlled network.

The attacker doesn’t need to change your DNS records.

They are manipulating the route that traffic takes after DNS resolution.

The effect depends on the routing announcement and which networks accept it. Some traffic may be diverted, some may fail, and other traffic may still reach the legitimate destination.

A particularly important detail is that BGP routing attacks don’t always need to impact the entire internet. Affecting the network path used by a specific service may be enough.

This becomes dangerous when that service is a Certificate Authority performing domain validation.

Wait. How does this affect HTTPS certificates?

Before issuing an HTTPS certificate, a Certificate Authority needs to verify that the applicant controls the requested domain.

A common method is the ACME HTTP-01 challenge used by Let’s Encrypt.

Here’s how legitimate validation works:

You request a certificate for api.example.com.
The CA provides a unique challenge token associated with your ACME account.
Your ACME client publishes the expected response under /.well-known/acme-challenge/.
The CA makes an HTTP request to the domain and verifies the response.
If the required validation checks succeed, the CA can issue the certificate.

Simple, automated, and convenient.

But consider the assumption behind step four.

The CA assumes its network request actually reached the infrastructure serving the legitimate domain.

What if the request was redirected somewhere else?

The attack, step by step

Let’s use a hypothetical example.

An attacker wants a certificate for api.example.com, a domain they don’t own.

Step 1: The attacker initiates a certificate request.

They request a certificate from a CA using an ACME account they control.

The CA responds with a challenge that must be satisfied before the certificate can be issued.

Step 2: The attacker prepares a fake validation endpoint.

The attacker can calculate the expected challenge response for their own ACME account and make it available on infrastructure under their control.

They still don’t control the real domain.

Step 3: The attacker manipulates the routing path.

Through a malicious BGP announcement, they attempt to redirect traffic destined for the legitimate server’s IP address.

If the attack influences the network path used by the CA, the CA’s challenge request may reach the attacker’s infrastructure.

Step 4: The CA receives the expected response.

Instead of communicating with the legitimate application, the CA receives the correct challenge response from the attacker’s server.

In a vulnerable single-perspective validation system, this can be mistaken for proof of domain control.

Step 5: A legitimate CA may issue a certificate to the wrong party.

The resulting certificate is cryptographically valid and associated with the attacker’s private key.

That’s the critical distinction.

The attacker hasn’t broken TLS encryption or stolen the legitimate server’s certificate. They have exploited how domain control is verified before certificate issuance.

With the fraudulently obtained certificate, the attacker could impersonate the domain in a subsequent network interception attack.

And because the certificate is signed by a trusted CA, a browser may consider the TLS connection valid.

One important caveat: possessing a fraudulent certificate doesn’t automatically decrypt previous HTTPS sessions or redirect users. The attacker still needs a way to get victims’ traffic to an endpoint they control.

Has this happened in the real world?

Yes. This isn’t just an interesting theoretical weakness.

In August 2022, the Celer Bridge cryptocurrency service experienced a front-end hijacking incident involving BGP routing manipulation.

According to a subsequent Coinbase threat-intelligence analysis, the attacker diverted traffic associated with a Celer subdomain serving critical configuration information.

A valid TLS certificate for the targeted domain was also observed during the attack, issued through GoGetSSL.

The attacker was able to present malicious configuration data that redirected cryptocurrency interactions toward attacker-controlled contracts.

The incident affected 32 victims and resulted in approximately $235,000 in losses, according to Coinbase.

The public analysis establishes the combination of BGP traffic redirection and a valid certificate. It doesn’t conclusively document every step of the certificate’s domain-validation process, so we shouldn’t assume the precise ACME challenge method used.

But the larger lesson is clear.

Routing manipulation can become far more dangerous when it is combined with apparently legitimate HTTPS identity.

And researchers had already demonstrated this risk years before the Celer incident.

Princeton University researchers showed how BGP attacks could interfere with CA domain validation. Their work helped motivate a stronger approach to certificate issuance.

That approach is called Multi-Perspective Issuance Corroboration (MPIC).

How do we make validation harder to hijack?

Think about the weakness in our example.

A CA makes a validation request from one network location.

An attacker manages to redirect that particular request.

The CA is fooled.

But what happens if the CA checks from multiple independent locations instead?

Imagine one validation request coming from the US, another from Europe, and another from Asia.

An attacker might successfully influence one network path without being able to influence the others.

Those unaffected locations would still reach the legitimate infrastructure and fail to find the attacker’s expected challenge response.

The contradictory results become evidence that the request should not be trusted.

That’s the fundamental idea behind MPIC.

Instead of trusting one view of the internet, a CA corroborates its validation result using multiple network perspectives.

Let’s Encrypt introduced multi-perspective validation at scale in February 2020, working with Princeton researchers.

And the approach has continued to evolve.

What’s changing at Let’s Encrypt in 2026?

On October 15, 2026, Let’s Encrypt announced that it is adding two more remote validation perspectives.

Validation perspectives	Previous	Announced
Primary datacenter	1	1
Remote perspectives	4	6
Total perspectives	5	7

Let’s Encrypt’s announced expansion from five to seven network validation perspectives, with production rollout planned for November 10, 2026.

The planned rollout is:

October 27, 2026: Staging environment.
November 10, 2026: Production, subject to successful testing.

Under the announced design, the primary validation server and a required quorum of remote perspectives must corroborate the challenge response.

Importantly, all seven checks do not have to succeed. The CA/Browser Forum’s baseline quorum rules permit up to two non-corroborating remote perspectives when six or more are used.

Increasing the number and diversity of perspectives makes localized routing attacks less likely to fool the CA.

There is also an industry-wide change behind this.

The CA/Browser Forum has been gradually strengthening MPIC requirements for publicly trusted CAs. From December 15, 2026, applicable validation methods must use at least five remote network perspectives and satisfy geographic diversity and quorum requirements.

This is a meaningful improvement for the Web PKI.

Not because BGP hijacking becomes impossible, but because an attacker can no longer rely on misleading just one validation path in the same way.

What can developers and infrastructure teams do to protect themselves?

Multi-perspective validation is a major improvement, but it’s primarily a safeguard implemented by Certificate Authorities.

As application owners, we should add our own layers of protection.

1. Enable DNSSEC

DNSSEC provides cryptographic authentication for DNS responses, helping validating resolvers detect forged DNS data.

It doesn’t directly prevent BGP hijacking of the route to your web server.

However, it can significantly reduce the risk of attackers tampering with DNS-based validation, particularly when the CA validates DNSSEC correctly.

For organizations relying on DNS-based certificate issuance, this is worth prioritizing.

Remember that enabling DNSSEC requires coordination between your DNS provider and domain registrar. A broken DNSSEC configuration can make an otherwise healthy domain unreachable.

2. Restrict certificate issuance using CAA records

Certification Authority Authorization (CAA) is one of the most useful controls that many domain owners overlook.

It lets you specify which Certificate Authorities are permitted to issue certificates for your domain.

For example:

example.com. CAA 0 issue "letsencrypt.org"

This authorizes Let’s Encrypt, rather than permitting issuance by any CA.

But we can go further.

The ACME CAA extensions defined in RFC 8657 support two important restrictions:

accounturi: Restrict issuance to specified ACME accounts.
validationmethods: Restrict which validation methods an authorized CA may use.

For example, a domain using Let’s Encrypt could authorize a specific ACME account and allow only DNS-01 validation.

This makes temporary control of a web server’s routing path less useful to an attacker.

However, CAA is not automatically a complete defense against routing attacks. The protection depends on trustworthy CAA lookups, correct DNSSEC validation where applicable, and the CA honoring the restrictions.

Also, before restricting CAA, account for other legitimate issuers such as your CDN, hosting provider, or managed certificate service.

3. Monitor Certificate Transparency logs

Certificate Transparency (CT) provides public visibility into certificates issued for domain names.

You can use services such as crt.sh or certificate monitoring platforms to discover unexpected certificates.

For critical domains, automate monitoring and alerting rather than relying on periodic manual checks.

Unexpected issuance should trigger an investigation, especially if it coincides with DNS changes or routing anomalies.

CT is a detection mechanism. It doesn’t prevent a certificate from being issued, and an alert may arrive after an attacker has already used it.

Still, it can greatly improve visibility and incident response.

4. Make routing security part of your hosting requirements

If you operate your own IP prefixes or Autonomous System, consider deploying Resource Public Key Infrastructure (RPKI).

RPKI allows IP address holders to publish signed Route Origin Authorizations (ROAs), identifying which networks are authorized to originate their prefixes.

Networks implementing Route Origin Validation (ROV) can reject BGP announcements that are invalid according to those authorizations.

This helps reduce accidental misrouting and certain BGP origin hijacking attacks.

There are limits, though.

RPKI origin validation does not authenticate the complete AS path, and its effectiveness depends on other networks actually performing validation.

If your application runs entirely on AWS, Azure, Cloudflare, or another provider, you may not control BGP announcements yourself.

In that case, evaluate your providers’ routing-security practices, including RPKI coverage, route filtering, and incident response.

5. Monitor routing anomalies

A BGP hijack can happen without a single suspicious entry appearing in your application logs.

Your web server may be perfectly healthy while requests are being routed elsewhere.

Services such as Cloudflare Radar, RIPE RIS, and BGP monitoring platforms can help identify unexpected route announcements.

Cloudflare Radar also supports alerts for route hijacks and route leaks affecting selected Autonomous Systems.

This becomes especially important when you operate critical IP infrastructure or depend on network prefixes associated with high-value services.

6. Secure certificate automation and prepare for revocation

Protect your ACME account keys, restrict DNS API credentials, and give your certificate automation only the permissions it needs.

Centralize certificate issuance where practical so the team has visibility into which certificates are being requested, renewed, and deployed.

And have an incident response procedure for unexpected issuance: identify the certificate, contact the issuing CA, request revocation where appropriate, and investigate whether traffic was diverted.

A valid certificate should not be treated as proof that the original server was never impersonated.

One more thing: A WAF doesn’t solve this problem

This is worth calling out because it’s easy to confuse application-layer security with internet-routing security.

A Web Application Firewall protects against certain malicious HTTP requests reaching an application.

A routing hijack operates at a different layer.

Likewise, HTTPS encrypts communication with the endpoint authenticated by the certificate. It cannot independently determine whether a trusted CA was deceived into issuing a valid certificate for the wrong party.

HSTS won’t solve that particular problem either if the impersonating endpoint presents a genuinely trusted certificate for the domain.

A WAF, TLS, DNSSEC, RPKI, CAA, multi-perspective validation, and certificate monitoring address different parts of the risk.

We need to understand what each one does, and what it doesn’t.

Final thought

One thing I find interesting about this entire problem is that the cryptography itself doesn’t need to fail.

TLS can work exactly as designed.

The certificate signature can be valid.

The browser can perform all its normal checks.

And yet, an attacker may have exploited a weakness in the earlier process used to establish domain control.

That’s why security is rarely just about selecting strong algorithms or enabling the right configuration.

It’s also about understanding the assumptions between systems.

A secure connection is only as trustworthy as the process that established who is on the other end.

Multi-perspective validation is a good example of how the industry is improving those assumptions.

Instead of asking one network path whether a domain belongs to someone, we ask multiple independent paths to corroborate the answer.

And sometimes, improving security doesn’t mean inventing new cryptography.

It means learning not to trust a single perspective.

Sources and further reading

Sunny Sharma

Security and engineering leader. Notes from running AI, Azure and security in production.

All posts