eMudhra CA Key Compromise: 8 Intermediate Certificates Cracked — What Indian IT Leaders Must Do Now

Today — October 27, 2026 — Google Chrome is pushing the final stage of its trust revocation that removes emSign ECC Root CA – G3 from every browser worldwide. If your organisation operates Indian-signed TLS certificates or distributes code bearing an eMudhra-issued signature, some of your users may already be seeing NET::ERR_CERT_AUTHORITY_INVALID errors. This is not a drill. Here is everything your security and infrastructure teams need to understand — and do — right now.

What Happened: A Certificate Authority’s Key Ceremony Goes Wrong

eMudhra Limited, headquartered in Bengaluru, is one of India’s largest licensed Certifying Authorities under the Controller of Certifying Authorities (CCA) and is also trusted globally under its emSign brand through several major browser root programs. In late April 2025, the company conducted a cryptographic key ceremony to generate new intermediate CA certificates — a routine operation that should be one of the most tightly controlled events in a PKI operation.

Something went catastrophically wrong during that ceremony. A flaw in eMudhra’s key generation process caused a secondary, weak set of P-384 elliptic-curve keys to be generated during a hardware-security-module (HSM) wrap/unwrap step. These weak keys were then mistakenly used to sign eight intermediate CA certificates rather than the correctly generated strong keys. The flaw reduced the effective entropy of the resulting private keys to an estimated 3 to 8 bits — compared to the 384 bits that the P-384 standard demands.

On October 17, 2026, a security researcher publicly disclosed that they had independently derived the private keys for all eight affected intermediates from data available in public certificate transparency logs. No intrusion into eMudhra’s infrastructure was required. The mathematical weakness of the keys was sufficient.

Timeline: From Key Ceremony to Global Browser Revocation

Technical Breakdown: How 3 Bits Killed 17 Months of Trust

Understanding the severity requires a quick look at P-384 cryptography. An elliptic-curve key on the P-384 curve should be an integer chosen uniformly at random from the range 1 to approximately 2³⁸⁴. The private key is supposed to be computationally impossible to derive from the public key alone — this guarantee holds only when the private integer genuinely spans all 384 bits of the curve’s order.

eMudhra’s key generation flaw produced private keys whose effective value was constrained to a tiny slice of that range — as few as 4 to 256 distinct values according to one researcher’s analysis, or roughly 3 to 8 bits of entropy. With such a small search space, a determined attacker needed only modest computing resources to try every possible private key and find the one that matched the public key embedded in the certificate. The intermediate CA private key is then available in full — and with it, the ability to issue any TLS certificate bearing the eMudhra chain of trust, including for domains the attacker does not own.

The downstream software impact is tracked under:

• CVE-2026-111943 — Go standard library (crypto/x509 and net/http trust-store hardcoding); fixed in Go 1.27.3 and Go 1.26.10
• CVE-2026-113470 — Firefox and NSS (Network Security Services); fixed in Firefox 136 and NSS 3.108
• Python certifi — updated to remove affected roots; install via pip install --upgrade certifi
• Rust webpki-roots — patch merged; update your Cargo.lock
• Homebrew ca-certificates — updated bundle available via brew upgrade ca-certificates

Notably, six of the eight affected intermediates issued TLS certificates for websites; the remaining two were code-signing CAs. Any software signed with those code-signing intermediates during the 17-month exposure window must be treated as potentially tampered unless provenance can be independently verified through a separate mechanism such as a reproducible-build hash or a Sigstore transparency log entry.

Why Indian Organisations Face a Unique Double Risk

eMudhra is not simply another global CA. It is one of the CCA-licensed authorities that issues Digital Signature Certificates (DSCs) used in Indian regulatory filings — MCA21, income-tax portals, GST submissions, and e-procurement. eMudhra has been careful to state that its root CA private keys and its DSC and eSign service infrastructure are separate from the affected global website-security intermediates, and that assertion is important.

However, Indian IT departments face two compounding risks that organisations in other countries do not:

1. Legitimate sites may lose trust today. CERT-In’s advisory CIAD-2026-0050 explicitly warns that removing emSign ECC Root CA – G3 from trust stores could cause legitimate, properly issued certificates under that root to fail validation. Indian banks, insurance portals, and government-linked e-commerce platforms that obtained valid TLS certificates from eMudhra may now present as untrusted to users whose browsers have updated — even though those certificates were correctly issued and the underlying site is genuine. This creates a social-engineering risk: end users who are trained to “click through” certificate errors on sites they consider routine may become blind to future, genuinely malicious certificate warnings.
2. Code-signing trust is harder to revoke end-to-end. Unlike TLS certificates, which browsers validate on every connection, a signed Windows executable, an Android APK, or a Java JAR is validated at install time and often again only at launch. Endpoint protection products and operating system smart-screen filters need to be explicitly updated with the revocation information. Any code-signed package distributed through an enterprise software depot or update pipeline may continue to carry what appears to be valid eMudhra signature validation on unpatched endpoints — even as the underlying key is now public.

This situation closely mirrors what we discussed in the context of the LiteLLM supply-chain compromise — where the attacker’s advantage lay not in brute-forcing systems but in appearing legitimate for long enough to steal credentials undetected. A compromised code-signing intermediate is arguably a more dangerous supply-chain vector.

What You Should Do: Sanjay’s Priority Action List

This incident demands action across four layers simultaneously. Below is the priority sequence I recommend to every client running enterprise infrastructure in India.

1. Inventory Your Certificate Exposure (Today)

Run a certificate scan against every externally and internally facing service. Qualys VMDR and Tenable.io both released detection content for the affected eMudhra intermediates on October 23. For teams without a commercial scanner, Qualys’s free community scanner can identify exposed assets. Key identifiers: the affected intermediates share the emSign ECC Root CA – G3 chain and were issued between April 30, 2025 and October 17, 2026.

2. Reissue or Replace Affected Certificates Immediately

Any TLS certificate that chains to the affected intermediates must be revoked and reissued from a different CA — not simply renewed from eMudhra’s current infrastructure. This is because even after revocation of the compromised intermediates, end-user devices that have not yet received the browser trust-store update will continue to accept certificates bearing the old chain. Use a CA from a fully separate root program (DigiCert, Sectigo, Let’s Encrypt, or ZeroSSL) for reissued certificates.

3. Update All Non-Browser Runtimes (This Week)

Browser vendors pushed automatic revocation to users within hours of disclosure. Your application runtimes did not. Audit and update:

• Go: upgrade to 1.27.3+ or 1.26.10+
• Python: pip install --upgrade certifi in every virtualenv and container image
• Java: update the JRE/JDK trust store — Oracle and OpenJDK builds require a manual cacerts update if the JDK has not shipped a bundled update yet
• Node.js: upgrade to the latest release; Node bundles Mozilla NSS
• curl / libcurl: rebuild against updated ca-bundle or run update-ca-certificates on Debian/Ubuntu
• Container base images: rebuild all production containers from updated base images

4. Treat All Code Signed with the Affected Chain as Untrusted

Identify every installer, update package, agent binary, or script that carries an eMudhra code-signing certificate from the April 2025 – October 2026 window. Verify hashes against known-good copies from the software vendor. If you cannot independently verify, treat the binary as potentially tampered and redeploy from a clean source.

In a Zero Trust architecture, this is precisely where device posture attestation pays off: a zero-trust NAC solution that validates application signatures at runtime will flag executables whose signing chain has been revoked, even on endpoints where the local trust store has not yet been updated.

Frequently Asked Questions

Are Indian DSCs (Digital Signature Certificates) affected?

According to eMudhra’s official statement, the incident is limited to its global website-security (TLS) and code-signing intermediate CAs under the emSign brand. The company states that its Indian DSC and eSign services operate on a separate PKI hierarchy that is not affected. However, given that the flaw originated in a key-generation process, independent verification by CCA India would provide greater assurance than the vendor’s self-assessment alone. Indian enterprises should request a written confirmation of DSC infrastructure separation from eMudhra until CCA India completes its review.

If no malicious use has been reported, why is this critical?

The 17-month exposure window means that any attacker who independently discovered this flaw could have quietly issued fraudulent TLS certificates or signed malware without triggering any public alert. The absence of known malicious use is not evidence of absence — certificate transparency logs can detect newly issued fraudulent certificates going forward, but they cannot retroactively reveal whether the private key was used privately during the exposure window. Treat the unknown-use period as a threat, not as a clean bill of health.

My firewall/proxy does TLS inspection. Does that protect my users?

Partially, but not completely. A TLS-inspecting proxy (like FortiGate with deep inspection or a Zscaler/Palo Alto CASB) that maintains an up-to-date CA bundle and performs CRL/OCSP checking will detect and block connections to a fraudulent certificate issued under the compromised chain — after revocation data is propagated. However, there is typically a delay between revocation and the time that OCSP/CRL information reaches every proxy in the estate. Ensure your FortiGate or proxy’s CA certificate bundle is updated and that certificate revocation checking is enforced, not merely advisory.

How long do I have before legitimate eMudhra TLS certificates stop working?

Most major browser updates reached the majority of users between October 17 and October 22. Chrome’s root-level push completes globally today (October 27). If your site is still serving a certificate chaining to emSign ECC Root CA – G3, a significant proportion of your visitors are already experiencing trust errors. Reissuance is not optional — it is overdue.

The Bigger Picture: PKI Trust Is Not a Fire-and-Forget Operation

The eMudhra incident is a reminder that certificate authority trust is a social contract that must be continuously earned, not a one-time technical achievement. Browser vendors operate root programs with strict audit and compliance requirements precisely because a compromised CA has the power to undermine HTTPS for the entire internet. When a flaw in a key ceremony goes undetected for 17 months, the root-program model reveals both its strength — coordinated revocation happened within hours of disclosure — and its weakness: the window of silent exposure can be vast.

For Indian enterprises, the actionable lesson is broader than “patch this CA.” PKI hygiene — inventory of issued certificates, automated expiry monitoring, supply-chain verification for signed binaries, and enforced CRL/OCSP checking at every TLS-inspection point — must be a standing programme, not a reaction to incidents like this one.

Sources used in this article:

• The Hacker News — Eight eMudhra CA Keys Compromised
• BleepingComputer — Mozilla, Google, Apple Block Compromised eMudhra Certificates
• Qualys Blog — How to Identify Compromised eMudhra Certificates
• Help Net Security — eMudhra Security Blunder Left Trusted CA Keys Exposed
• Cloudflare Blog — The eMudhra Certificate Compromise
• eMudhra Official Statement on the Certificate Security Incident