Writing
How a compromised CA key enables HTTPS interception
The eMudhra CA-key compromise shows how a valid certificate can put an attacker inside an HTTPS session, and which client checks stop the attack.
Imagine an ordinary download through curl. DNS returns the correct address. The certificate check passes. The connection is encrypted, the script receives a response, and execution continues. Yet someone else may have changed the response.
A compromised certificate authority can make this possible. The client establishes an encrypted channel with an attacker because it accepts the attacker as the real site. The eMudhra incident exposes that failure of trust and the checks that can interrupt it.
Before the public disclosure
The failure began well before the October 2026 disclosure. eMudhra dates the affected keys to a key-generation ceremony in April 2025. In its preliminary technical account, the company said a key-export test created additional, weak key pairs. Similar key labels led operators to use the weak keys for certificate requests, which eMudhra and Sectigo then signed.
An earlier incident had exposed a mismatch. A June 2025 report documented invalid signatures on certificate revocation lists (CRLs) produced in May for six TLS intermediates. That report treated the problem as incorrect key configuration. In October, eMudhra connected the incidents: it said the initial CRLs used the original keys, then were re-signed with the weak keys that matched the certificates. Fixing the signature mismatch had not established that those keys were safe.
On 17 October 2026, the researcher Wayne reported the recoverable keys to the CA and root-program operators. He demonstrated control by signing the message “We have a problem here - Wayne”; the disclosure includes the signed attestations. Mozilla independently recovered the keys that evening. Its preliminary analysis found P-384 private values below 256, making recovery trivial.
Browser defenses moved before the public announcement. Google reports receiving the report at 18:05 UTC on 17 October and deploying key-based CRLSet blocks at 19:45 UTC. Mozilla completed its OneCRL rollout by 22:59 UTC that day for Firefox users with standard configurations. eMudhra revoked the affected intermediates on 18 October. Downstream trust-store operators were notified on 19 October; public disclosure followed on 20 October.
This chronology reflects the public record as of 21 October 2026. Key recovery was independently verified; eMudhra’s operational explanation was still preliminary. The exposure began with the flawed keys in 2025, but the disclosure does not establish whether anyone exploited them to intercept traffic before the report.
What happened at eMudhra
The affected set comprised eight intermediate certificates: six for TLS and two for code signing. This article follows the HTTPS risk from the TLS intermediates. Their certificates chained to roots that clients trusted, while their private keys were recoverable from public information. Someone who recovered a key could sign a new certificate on behalf of an accepted authority.
Two objects matter here. A certificate is a public document that binds a name or an owner to a public key. A private key is the secret used to produce a signature. Generating it requires sufficiently unpredictable randomness. These keys lacked that property. Publishing a certificate is normal; allowing someone to recover its signer’s secret defeats the basis for trusting the signature.
Impersonation with a fraudulently issued, trusted certificate is an established attack. The new incident supplied a critical ingredient: a signing key whose output some clients would still accept. Follow one possible HTTPS download to see what the compromised key makes possible.
Where the client gets its trust
A script starts curl and downloads a file over HTTPS. DNS first supplies the site’s IP address. The client connects and begins a TLS handshake. The address got the packets to their destination; the server still has to prove its identity.
The server presents a leaf certificate for the requested domain. It contains the server’s public key and a SAN field listing the names for which the certificate is valid. A certificate authority, or CA, attests to that binding by signing the certificate.
Usually, this forms a chain. An intermediate CA signs the leaf; a higher authority signs the intermediate’s certificate. The chain ends at a root the client already trusts. That trust is configured locally in its trust store. Sending an arbitrary root over the network does not make it trusted.
The client checks signatures, validity dates, the requested name and the acceptable trust path. The server also proves possession of the leaf’s private key. In normal operation, these checks bind the channel to the expected site. With the intermediate CA’s private key, however, an attacker can create a new leaf for the target name and give it a cryptographically valid signature. The relevant authentication mechanics are specified in RFC 8446.
The intermediate signing key is compromised. A client that still accepts this trust path can accept a new leaf signed by the attacker, unless another check rejects it.
The attacker now holds two useful secrets: the compromised CA key used to sign the leaf, and the private key of the leaf they created themselves. They can satisfy both chain validation and proof of possession, provided the client still accepts that trust path and no other check rejects it.
They do not need the real site’s private key. The site may even obtain its legitimate certificates from a completely different CA. A client that accepts any permitted chain to one of its trusted roots does not require today’s issuer to match yesterday’s issuer. A failure at one CA can therefore affect connections to other organizations’ sites.
The attacker still needs the connection
Return to the download. DNS worked correctly: curl received the genuine IP and sent packets there. Possessing a CA key does not grant access to those packets. The attacker needs a network position that lets them intercept a new connection or redirect the client to themselves.
That position is called on-path. Traffic might pass through network equipment the attacker controls. They can intercept TCP connection establishment and respond as the destination address. The IP remains correct, while the client’s actual peer becomes the intermediary.
The attacker can also change the path. ARP spoofing inside a LAN can make a device send frames to the attacker’s MAC address instead of the gateway. A forged DNS answer can point the client at the attacker’s IP. The mechanisms differ; in each case, the attacker gets to receive the client’s next TLS handshake.
Before the attacker had an accepted identity, this position alone did not enable silent HTTPS impersonation. It allowed metadata observation or packet blocking, or an attempt with a certificate the client would reject. The compromised CA key supplies the missing accepted identity.
More detail: ARP, DNS and the SYN race
ARP spoofing changes frame delivery within the LAN; DNS can remain correct. DNS manipulation changes the address the client chooses. A transparent on-path intermediary can leave both DNS and the destination IP unchanged and interfere with the connection passing through it.
In a SYN race, the intermediary sees the client’s initial SYN and sends a SYN-ACK before the real server does, or suppresses the real response. That establishes a TCP position. TLS authentication still comes next.
How an encrypted download becomes an interception
The client starts a handshake with what it believes is the site. The attacker presents the prepared leaf for the requested name, together with the chain through the compromised intermediate. The name matches. The signature verifies. The chain leads to a root in the client’s store. If revocation, CT or pinning does not stop the validation, the client accepts the certificate.
The parties then obtain session keys. In TLS 1.3 with ECDHE, each participant combines an ephemeral secret with the peer’s public key share. For this client, the peer is the attacker. The attacker knows the keys because they are a participant in the session.
Now curl sends its HTTP request through the encrypted channel. At the attacker’s endpoint, the request is decrypted: the path, headers, any Authorization token and the request body become available. The intermediary can establish a separate TLS connection to the real site, forward the request, and return the original or a modified response. This is MITM, or Man-in-the-Middle.
Green arrows show encryption on the wire. The attacker reads plaintext at their TLS endpoints without breaking ECDHE or AEAD.
Encryption works on both network segments. The failure happened when the client chose whom to trust. The original client and the real server now have two separate TLS sessions, both terminating at the intermediary.
Forward secrecy, or PFS, does not stop this attack. It protects past ECDHE sessions against later theft of a long-term key, assuming ephemeral secrets were correctly erased. Here, the attacker participates in a new session from the start. Similarly, AEAD rejects forged encrypted records from someone without the session key. A participant who knows the key can create valid records.
Message by message: the TLS 1.3 handshake
ClientHello and ServerHello carry the exchange parameters. After ServerHello, the parties derive handshake keys; subsequent messages, including the certificate and proof of possession, are encrypted. The client must still authenticate the server before entrusting it with application data.
Normal TLS
The client authenticates the server. A passive observer sees metadata, but cannot read application data. This diagram covers a certificate-authenticated ECDHE handshake, not resumption or 0-RTT.
MITM accepted
The client accepts the attacker’s chain, and applicable pinning, CT and revocation checks do not stop it. The attacker is the client’s TLS endpoint.
MITM rejected
The client cannot establish an accepted trust path. It aborts the handshake before sending application data. Curl exit 60 identifies a certificate-verification failure.
Recording old traffic and actively impersonating a peer are different attacks. With legacy RSA key exchange, a later theft of the server’s private key can expose recorded sessions. ECDHE protects that history. It cannot correct the client’s decision to accept an attacker in a new handshake. An RSA signature on a certificate is also distinct from RSA key exchange.
Why a browser and a script can behave differently
The attack has a condition: the client must accept the chain. Signature verification is only part of that decision. Clients can impose additional rules, including public certificate logging and revocation.
Certificate Transparency, or CT, makes certificate issuance observable through public logs. An SCT is the log operator’s signed promise to include a certificate within a defined period. A CT-enforcing client requires qualifying evidence under its policy. An attacker who issues a leaf privately and obtains no qualifying SCTs cannot satisfy that policy with a valid CA signature alone.
For eMudhra, this was a significant barrier. Google reported that some affected CAs had no logged TLS certificates before the blocking action, limiting the opportunity to attack clients that enforce CT. But CT is not a universal prohibition on CA abuse. A monitor sees what enters the log; the individual client enforces the policy. See the incident response and CT specification.
Revocation addresses another problem: a previously acceptable certificate or key must no longer be accepted. Chrome distributed blocks through CRLSet, and Firefox through OneCRL. Trust-store updates also addressed downstream consumers. Clients need to receive those updates and use them when making trust decisions. Mozilla’s account of the response describes the browser and NSS paths separately.
This explains how a browser and a background script on the same machine can differ. They may use different TLS libraries and trust stores, and different mechanisms for receiving blocks. A container may carry an old CA bundle. A Python application may use a separate certifi package. The browser’s protection does not verify those clients.
Nor can every curl binary be declared vulnerable or protected in advance. Its backend, build and configuration matter. Identify what the actual client process checks before it downloads a file or sends a secret. The curl documentation describes native trust and backend-specific behavior, including Schannel.
CT logs and certificate-revocation mechanisms
An SCT promises inclusion; it is not itself proof that the certificate has already been incorporated into the tree. Monitoring unexpected issuance and rejecting certificates without qualifying SCTs are separate actions.
An SCT and a proof of inclusion are different objects. A monitor cannot see an unlogged leaf; client-side CT enforcement supplies a separate barrier.
| Mechanism | Where the client gets the status | What matters |
|---|---|---|
| CRL | A signed list from the CA | Freshness and the policy when the list is unavailable |
| OCSP | A response from the CA’s responder | Network availability and soft-fail or hard-fail policy |
| Stapling | The server attaches an OCSP response | Signature, freshness and the policy for a missing response |
| CRLite, OneCRL, CRLSet | Updated local client data | Freshness, coverage and enforcement |
With soft-fail, the absence of a status response does not stop the connection. Local mechanisms depend on current data and their scope of coverage. CRLite, OneCRL and CRLSet serve different purposes; they are not interchangeable names for one list. Mozilla explains the local-check approach in its CRLite introduction.
What changes when trust is removed
Keep the same curl, route and attacker. If the client no longer accepts the affected chain, the attack stops at certificate verification. A mathematically valid signature made with the recovered CA key no longer grants permission to represent the site.
That is the point of updating trust. Signature verification and the decision to trust the signer are separate checks. The signature can still verify after the signer has lost control of the key.
Compare the same request before and after distrust
| Part of the request | Client still trusts the chain | Client rejects the affected trust |
|---|---|---|
| DNS and destination | Genuine address | Same genuine address |
| Attacker’s position | On-path | On-path |
| Leaf signature | Cryptographically valid | Still cryptographically valid |
| Trust decision | Accept if other checks pass | Reject the affected chain |
| HTTP application data | Can be sent to the attacker | Stopped before transmission |
Start with the consumers: the browser and system tools, applications, containers and CI jobs. For each, identify the trust source and apply the fixes published for that platform. Then verify the behavior of the client itself. The eMudhra disclosure maintains the list of patched components and provides test chains.
The infrastructure audit behind this article used two checks: the compromised test chain had to fail, while ordinary HTTPS had to keep working. A curl exit code of 60 in that controlled test showed a certificate-verification failure. The result belonged to the tested binary and its environment. Another process on the same host could use another store.
Pinning provides a narrower trust model by fixing an expected application key or certificate. Another key then cannot pass solely because it has a chain to an accepted CA. Pinning costs operational flexibility: key rotation needs a plan, and clients with an old pin can lose access.
Why your DNS resolver or tunnel is not enough
DNS returned the genuine IP at the start of this story. Moving to your own resolver would not have changed that attack path: the intermediary already sat on the route to the correct address. A protected DNS path prevents answer manipulation on that segment. TLS must still authenticate the peer.
A tunnel changes the network part of the scenario. An outside observer between the client and the tunnel exit cannot simply interfere with an inner TLS session if the tunnel is correctly protected and authenticated. After the exit, however, packets travel through another network. An interception position can exist there too.
A TCP relay forwards bytes without terminating inner TLS. The original client verifies the destination certificate. Connections created by a process on the VPS use that process’s trust settings instead.
If the VPS only forwards TCP bytes, the inner TLS session remains between the original client and the site. The original client verifies the certificate, so its updated trust applies against a MITM on the exit path as well. If a process on the VPS creates the connection, that process’s checks matter instead.
Reality’s own authentication and SSH host-key verification do not accept an outsider merely because it presents a public-CA certificate. That property of the outer channel does not relieve applications inside it of verifying their HTTPS peers. Any tunnel can also be blocked; availability remains a separate problem. The Reality upstream documentation distinguishes its authenticated connection from a real donor-site certificate.
What this means for downloads and agents
Suppose the script receives a modified response. The damage depends on what it does next. A token sent through the connection may already be exposed. A substituted installation script becomes executable code if it is run without an independent check. A successful HTTPS download does not reveal either failure.
An accepted TLS connection also does not always imply installation of a forged package. APT verifies signed repository metadata and the package-hash chain derived from it. Possessing a CA key is insufficient to forge a signature under an independent archive key. The network interception can succeed while a later layer stops the package substitution. Debian’s apt-secure documentation explains that boundary.
If the supplier, build system or artifact-signing key is compromised, the problem becomes a supply-chain attack. A poisoned artifact can arrive over legitimate TLS with an expected signature. The transport and the provenance of executable code need distinct checks.
For an AI agent, that separation has an immediate consequence. It may download a dependency, execute a command and use secrets from its environment without a person inspecting each response. Automation shortens the path from accepted content to action. The checks performed by the tool it invokes, the artifacts it may execute and its access to secrets all affect the outcome.
The incident is contained when the process making the request stops trusting the compromised identity.
Incident sources
- eMudhra’s statement, 20 October 2026: the CA’s account of the key-generation ceremony and the investigation’s scope.
- Mozilla Bug 2083449: the initial report, independent key recovery, the CA’s preliminary explanation and the response timeline.
- The earlier invalid-CRL incident, Bug 1970728: the 2025 signature failures and the remediation recorded at the time.
- Google’s Chrome and Android response: key-based blocking, CT coverage and root-store changes.
- Mozilla’s Firefox response: OneCRL distribution, browser updates and downstream trust-store protection.
- The public disclosure and test site: proof of key control, affected chains and remediation information for client software.
Glossary
Certificate
A public document containing a public key, names or an owner, a validity period and the issuer’s signature. It does not contain the private key.
Private key
A secret that allows cryptographic operations on behalf of the key-pair owner; here, creating signatures.
Certificate authority
A CA signs certificates to attest to a binding between a name or owner and a public key. An intermediate CA has its own certificate from a higher authority.
Leaf certificate
The end-entity certificate for a site or service. In this attack, the attacker creates their own leaf for the real site’s name.
SAN
Subject Alternative Name: the certificate field listing the names for which it is valid. A certificate for a lookalike domain does not pass the real domain’s name check.
Root certificate
A trust anchor accepted by the client’s local policy. Receiving a root from a server does not make it trusted.
Trust store
The client’s trusted certificates and associated policy. Programs on one host may use different stores.
On-path
A position on the traffic path that permits observation and, with active control, interference with delivery.
MITM
Man-in-the-Middle: an intermediary impersonates the intended peer. In this scenario, it terminates the client’s TLS session and creates another to the site.
Certificate Transparency
A system of public certificate logs. Client-side CT policy enforcement and log monitoring are distinct mechanisms.
SCT
Signed Certificate Timestamp: a log’s signed promise to include a certificate within a defined period.
Revocation
Withdrawal of trust in a certificate before it expires. It protects a client only when the client receives and applies the relevant information.
Forward secrecy
PFS: later theft of a long-term key does not expose past ECDHE sessions when ephemeral secrets were correctly erased.
AEAD
Authenticated encryption with associated data. It rejects undetected record modification by someone who does not know the session key.
Pinning
Fixing an expected key or certificate in an application. It narrows accepted identities and requires a rotation strategy.