eMudhra CA Compromise: Eight Intermediate Certificate Keys Expose a Critical Weakness in Internet Trust

Update by eMudhra

eMudhra has confirmed that eight Global TLS intermediate CA certificates created in April 2025 contained cryptographically weak keys due to a flaw in its key generation ceremony. The company revoked all eight certificates on 19 October 2026 and says the weakness originated in a key wrap/unwrap procedure, not a compromise of its FIPS-certified Hardware Security Modules (HSMs). According to eMudhra, none of the eight intermediates issued end-entity certificates, and there is no evidence of exploitation or data breaches. However, browser root programs have distrusted the associated eMudhra ECC root CA as a precaution, affecting one customer ecosystem in the United States. eMudhra is replacing the affected certificates, reviewing its key generation procedures, and introducing additional CA redundancy for enterprise TLS customers. Its digital signature, eSign, and other enterprise services remain unaffected.

Update: Official statement from CERT-I about thr eMudra incident

Update: Official statement from eMudhra

The story so far: In April 2025, eMudhra reportedly issued eight intermediate CA certificates cross-signed by Sectigo after a flaw in its HSM key-wrapping test script generated a second set of P-384 key pairs with dangerously predictable private keys. Each weak private key was an integer below 256, and the wrong key labels led operators to select these keys when creating certificates intended for production use. The result was extraordinary: one intermediate CA’s private key was simply 4, while the other seven were 56, 66, 115, 155, 156, 230, and 237.

The problem surfaced roughly three weeks later, in May 2025, when signatures on Certificate Revocation Lists (CRLs) began failing because the signing system was using the legitimate private keys rather than the weak keys embedded in the certificates. Instead of investigating why the keys did not correspond, the team reportedly reconfigured the CRL signer to use the weak keys and marked the issue as resolved. That decision turned what could have been an opportunity to catch a serious cryptographic failure into a much more consequential security problem.

Official statements have been released by eMudhra and CERT-In.

According to eMudhra, the ECC root in a Key Generation Ceremony (KGC) and a flaw in the KGC caused a wrap/unwrap step to produce a second set of weak keys alongside the original strong keys. The weak keys were the ones published to the browser root stores.

Eight intermediate CA keys were compromised, and browsers moved to distrust them within hours. The harder question is how to revoke trust from software that never checks for revocation.

The breach and the cryptographic proof

On the weekend of October 17, 2026, security researcher Wayne publicly disclosed that the private keys for eight intermediate certificate authorities run by eMudhra, an Indian digital trust provider operating under the emSign brand, had been compromised. To prove possession of the keys without exposing them, the researcher signed a plaintext message, “We have a problem here – Wayne,” with the private key for each of the eight intermediates. The proof went straight to the root program teams at Mozilla, Microsoft, Apple, and Google and set off a weekend of emergency patches across the software ecosystem. The private key in question? 4. Yes. Literally 0x4.

Why an intermediate compromise is worse than a leaf compromise

Losing a leaf certificate, the kind issued to a single website, is a local problem. The domain owner generates a new key pair, requests a replacement, and the old certificate expires or is revoked.

An intermediate CA is different. Intermediates exist to keep the root CA keys offline and locked in hardware security modules. The root delegates its signing authority to the intermediate, which issues certificates to the public. An attacker who controls an intermediate’s private key inherits the trust placed in that whole branch of the hierarchy. They can mint valid TLS certificates for any domain and skip the domain validation checks that legitimate CAs enforce.

How the proof can be verified

A certificate binds an identity to a public key. The researcher signed with the compromised private key, so anyone can extract the public key from the affected eMudhra intermediate and check the signature with a standard toolkit like OpenSSL. A successful verification proves the signer held the private key at the time of signing. In a terminal it looks like this:

bash

openssl x509 -in compromised_intermediate.pem -pubkey -noout > intermediate.pub
openssl dgst -sha256 -verify intermediate.pub -signature wayne.sig message.txt

That settles key possession and says nothing about impact. Holding the key does not mean fraudulent certificates were issued, and it does not prove that man-in-the-middle attacks hit banking portals or government services. The available disclosures, including Mozilla’s security advisory MFSA2026-113, confirm the key compromise and the distrust actions. None of them confirms exploitation in the wild. The vector is also unconfirmed: it could be an insider, a hardware security module failure, a leaked backup, or a breach of the signing infrastructure.

Revocation versus hard distrust

The key technical lesson is the gap between certificate revocation and client-side distrust. In the traditional PKI model, the issuing CA revokes a compromised certificate by adding its serial number to a Certificate Revocation List (CRL) or updating an Online Certificate Status Protocol (OCSP) responder. Any client that checks status should then abort the connection.

In practice, revocation is unreliable. Many applications, libraries, and embedded systems skip revocation checks because they add latency and failure points. Under a soft-fail configuration, an unreachable OCSP responder lets the connection proceed anyway, whatever the certificate’s real status.

Soft-fail is not good enough for an intermediate CA breach, so browser and runtime vendors rely on hard distrust. Mozilla moved fast. It received the report at 20:06 UTC on October 17 and pushed a blocklist update through OneCRL on its Remote Settings infrastructure by 22:59 UTC. That forces Firefox to reject the specific certificates regardless of cryptographic validity or expiration date. Mozilla then released Firefox 158.0.1 and updates to the Network Security Services (NSS) library so clients disconnected from Remote Settings also received the blocklist.

Cross-signing

Cross-signing complicated the incident. So that older devices without the newest eMudhra roots would keep working, these intermediates were cross-signed by established authorities, specifically Sectigo’s AAA Certificate Services root. A client can therefore build a valid chain to a different root anchor. If a browser distrusts only the eMudhra root, an attacker could still present a chain that runs through the Sectigo root.

Distrusting the Subject Public Key Info (SPKI) hashes of the compromised intermediates closes every chain-building path. Blocking the public keys, rather than certificate serial numbers or root issuers, means the keys are rejected whichever valid path the client builds. After the disclosure, Sectigo moved to pull its cross-signs for the affected intermediates to cut the alternate trust paths.

The long tail of the software supply chain

Browsers can push emergency blocklists to hundreds of millions of users within hours. The rest of the internet is slower and more fragmented. On October 19, the Go team issued emergency security updates, versions 1.27.3 and 1.26.10, assigned CVE-2026-111943. Unlike a web browser that relies on the host operating system’s certificate store, Go’s standard crypto/x509 library implements its own certificate verification logic and bundles its own trust verification mechanisms. The Go team had to hardcode distrust of the eight eMudhra intermediate keys into the standard library.

That fix creates real work for enterprises. If a backend microservice was compiled with an older Go version, updating the toolchain on the host does nothing for the running binary, which already contains the old verification logic. Securing the environment means finding every compiled Go binary, updating the build pipeline, recompiling against the patched toolchain, and redeploying to production.

The same problem runs through the rest of the supply chain. Python applications using the certifi package, Rust applications using rustls-webpki or webpki-roots, and Electron desktop apps each keep their own certificate bundles and verification libraries. An enterprise can patch every Windows and macOS workstation and still have dozens of internal API clients, CI/CD pipeline runners, and containerized applications that never saw the OneCRL updates from Mozilla or Apple. In those environments, a successful TLS handshake only shows that the client accepted the certificate under its outdated validation rules. It says nothing about whether the connection is secure.

What eMudhra still has to prove

For eMudhra, the immediate technical fix is the easy part. Generating new keys and issuing replacement certificates for legitimate customers is routine engineering. The harder job is convincing the root programs that the underlying operational failure has been found and permanently fixed.

CAs are expected to maintain separation of duties, multi-person authorization, and heavily audited hardware security modules. Eight intermediate keys compromised at the same time points to a systemic failure rather than a one-off accident. eMudhra has to complete a root-cause analysis and share it with the CA/Browser Forum and the root store operators. Until the industry knows how the keys were extracted, relying parties cannot assess the risk to the rest of eMudhra’s infrastructure.

Establishing trust across the internet is largely a solved problem. Revoking it instantly across millions of unmanaged, unpatchable clients is still one of the hardest problems in security. For administrators and developers, that means looking past browsers to compiled binaries, container images, and third-party dependencies. After a CA compromise, the software you forgot about is usually the software that still accepts the bad certificates.