eMudhra Intermediate CA Compromise

Private keys for eight eMudhra intermediate Certificate Authority (CA) certificates have been compromised, making it trivial for attackers to forge certificates that would be trusted by unpatched roots of trust. Six of the impacted certificates were for Transport Layer Security (TLS) and trusted by the Apple, Chrome, Microsoft and Mozilla root programs. The other two certificates were for codesigning and trusted by Microsoft. Browsers were able to block the affected intermediate CAs using their background revocation blocklists, but most other software relying on web public key infrastructure (PKI) lacks any mechanism to filter intermediate CAs. In order to defend against rogue certificates from the compromised intermediate CAs many projects have chosen to remove the emSign ECC Root CA - G3 from their roots of trust. That removal is causing collateral damage for all legitimate certificates previously issued by CAs chained to that root.

Forged certificates can potentially be used to impersonate sites and services as part of a man in the middle (MITM) attack. The underlying problem is that there are hundreds of CAs in a typical root CA bundle, and thousands of intermediate CAs that inherit trust. Any one of those CAs can create a legitimate looking certificate for any domain. The chain of trust is only broken if the trust anchors are updated to reflect the compromise. This leaves any unpatched system vulnerable.

There’s no evidence that eMudhra was breached. The private keys appear to have been generated by an insecure mechanism. Rather than being large random numbers the keys are all zero, except for the final byte, which was 4, 56, 66, 115, 155, 156, 230 or 237. Those private keys can be trivially enumerated, and their public keys inferred. When matching public keys were seen in use for live CAs the inadequate entropy private keys became a compromise. ‘Wayne’ is credited with the discovery in root store incident reports, having provided a proof.zip bundle along with the statement ‘we have a problem here’. Dennis Jackson has subsequently created an eMudhra Intermediate CA Compromise summary site using the domain emudhra.we-have-a-problem.com (which uses a LetsEncrypt certificate).

The browsers responded first by using their revocation blocklists, which provide a rapid and precisely targeted mechanism (explained by How Do Browsers Handle Revoked SSL/TLS Certificates?). Many other projects depend on browser roots of trust (usually from Mozilla due to permissive licensing). The CA certificates extracted from Mozilla cacerts file that’s curated by the curl project is widely used by other open source projects, including Linux distributions and the TLS implementations of many programming languages. The ca-certificates packages in Arch, Debian, Gentoo, Fedora and Ubuntu have all been updated; along with Electron, Go, pip, Python certifi, rustls-webpki, Rust webpki-roots and uv. Those updates will take some time to propagate to all of the places they need to reach, and systems that aren’t actively patched (including everything past end of life) will remain vulnerable.

Some languages and frameworks no longer bundle roots of trust, leaving it to developers to depend on system roots or to determine their own. For example Dart (from version 3.13 released in August 2026), which is used within the popular Flutter cross platform framework, no longer has an embedded cacerts file. Where system roots are used this potentially allows faster updates without any application changes. Developers choosing their own roots also allows for finely honed trust limited to CAs that are known to be part of a given system. There will however now be many applications with a cacerts file buried within them that continues to trust the compromised CAs.

Certificates are also used for authentication, often as part of mutual TLS (mTLS). This opens up another possible avenue for attack with forged certificates if applications trust the web PKI roots. SSLMate founder Andrew Ayer observed:

The people who should be really scared right now are those using WebPKI CAs for mTLS / TLS client authentication. Attackers can just mint a certificate and authenticate to the mTLS endpoint, which probably does not know about the intermediate revocation. No need to pull off a BGP hijack or other network attack.

(Yes, Chrome is banning clientAuth EKU in the WebPKI, but they extended the deadline and I know of 6 examples of services changing their mTLS verifiers to accept serverAuth EKU in lieu of clientAuth, so mTLS in the WebPKI is still alive and kicking despite it being a bad idea.)

Another protection mechanism that’s bypassed by certificate forgery is the use of DNS Certificate Authority Authorization (CAA) records. Those should prevent a legitimate CA from issuing certificates to a domain that has CAA records present, but doesn’t list that CA. But no forger is going to run such a check. It’s conceivable that more widespread use of CAA records could defend against forgery, but uptake (even by many popular sites) has been low, and so the system remains mostly nascent.

Certificate Transparency also could have helped if more widely used outside of browsers. Moxie Marlinspike proposed ‘Convergence’ at Black Hat in 2011, where a distributed system of certificate observation would be used to determine validity rather than (or initially in addition to) CAs and trusted roots. Convergence didn’t get sufficient traction, but Certificate Transparency (RFC6962) and Certificate Transparency Version 2.0 (RFC9162) have attempted to define standards that would achieve similar outcomes by building distributed ledgers of certificate issue. A client can check that a certificate has been correctly issued, and reject forged certificates that wouldn’t appear in logs.

This compromise foreshadows a doomsday scenario outlined by Spice Labs Founder David Pollak in a podcast interview with Viktor Peterson ‘Post-Quantum Cryptography: Rethinking Trust Before the Clock Runs Out’. Pollak asked what might happen if the private keys for the popular CA roots were compromised. That remains a serious concern as we head towards ‘Q day’ as CAs are still anchored to RSA and Elliptic-curve cryptography (ECC) keys using classical algorithms. It does shed some light on why SSL/TLS Certificate Lifespans to Shrink to 47 Days by 2029 as it will be easier to refresh certificates to use new anchors.

Certificate transparency and post quantum concerns come together in ‘A Post-Quantum Future for Let's Encrypt’ where they propose the use of Merkle Tree Certificates (MTCs) as an alternative to signing with post quantum algorithms such as ML-DSA-44. Not only would such a mechanism be lighter on the wire when doing session initiation handshakes, but it should also make key compromise more containable.