eMudhra Quits the Global TLS Certificate Business Five Days After Its Weak-Key Disclosure -- Mozilla and Chrome Pulled a Whole Root, and Go Shipped a Denylist for Systems That Never Update

On October 22, 2026, eMudhra Limited, listed on the NSE and BSE and headquartered in Bengaluru, said its Board had decided "to voluntarily withdraw from the global SSL/TLS certificate business." It came five days after a researcher showed that eight of its intermediate CA keys were trivially recoverable, which this digest covered on October 21. Here is what has happened since.

From eight intermediates to a whole root

On October 20, Mozilla's Dennis Jackson wrote in the incident bug that "multiple individuals have independently recovered the private keys", some publicly. Mozilla therefore decided on "the emergency removal of trust in emSign ECC Root CA - G3" to protect "clients which do not use revocation information or lack a mechanism to withdraw trust in specific intermediates." The Chrome Root Program "committed to a similar path" the same day. eMudhra replied that it had ceased issuance from all intermediates chaining to that root. Mozilla said it was "not removing trust in emSign Root CA - G1" at that time.

eMudhra's October 21 statement gave its cause: "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." It said the ceremony used FIPS 140-2 Level 3 HSMs and that the root cause is still under investigation.

The exit, as eMudhra tells it

The October 22 release says global TLS contributes "about 1% of the global revenue", and that free certificates from large issuers had already reduced its return. It adds that "the level of social media amplification around this incident has brought scrutiny that is out of proportion to SSL/TLS's place in our business." It says the affected CAs were revoked "within 14 hours of discovery" and that no end-entity certificates were issued from them. eMudhra's G1 RSA roots will keep serving customers during the transition, replacements will come "free of cost from partners", revocation and status services will run until every certificate has expired or been replaced, and a full root-cause report will follow. Its digital signature certificate (DSC), eSign and other signing services, including those in India, along with emCA, CertiNext, emSigner and SecurePass, are described as unaffected and separately run.

What Chrome and other participants are asking

The bug thread has moved from remediation to explanation. On October 21 the Chrome Root Program posted twelve questions. It noted that emsign.com redirects to a product page that carries neither of eMudhra's incident notices, and that neither notice names the distrusted root or the affected intermediates. Using Certificate Transparency data, it counted "approximately 30,800 unexpired precertificates" chaining to emSign ECC Root CA - G3. Of these, 30,791 (99.9%) came from two Internet2 / InCommon subordinate CAs, which serve research and education institutions, and only 18 from eMudhra's own intermediates. It expects Chrome Root Store v43, which removes the root, to reach Stable on October 27. Its sharpest question is about June 2025. That month a CRL problem showed that the keys signing eMudhra's CRLs did not match the keys in its issued CA certificates. Chrome asks why eMudhra chose to "simply re-sign the CRLs with that second key rather than halting operations" and auditing why two key pairs existed.

Other participants in the bug have pressed on the key ceremony itself. One asked how a policy requiring key generation inside a FIPS 140-2 Level 3 device fits keys like these. Another wrote that "A P-384 private scalar below 256 is not something approved in-module key pair generation produces by itself" and asked for the ceremony script, the exact PKCS#11 call and the witness report. A third pointed out that the status page says eMudhra learned of the problem "late evening, India time" on October 18, while the bug records eMudhra's acknowledgment at 21:28 UTC on October 17 and all eight revocations between 09:24 and 09:38 UTC on October 18.

The Go fix

Go's security team published GO-2026-6809 (CVE-2026-111943) on October 21. It notes that Go usually relies on system roots, but "in some narrower cases, the system trust stores may not be updated without further action", so crypto/x509 now carries a denylist that makes Certificate.Verify fail for the untrusted intermediates. Go versions before 1.26.10, and 1.27 before 1.27.3, are affected. NVD lists the CVE as awaiting analysis, with no score yet.

What remains uncertain. eMudhra has not explained the wrap/unwrap flaw in detail, and nobody has said whether the keys were used before October 17. The partner and timeline for migrating G1 customers are also unknown.

Analysis: For Indian enterprises, the separation eMudhra describes between its global TLS hierarchy and its domestic DSC and eSign services is the claim to verify, because it carries the reputational weight here. For engineers, the Go advisory is the practical lesson. A denylist compiled into a binary only protects you after a rebuild with the fixed toolchain. Go-built agent CLIs, sidecars and MCP servers shipped as static binaries in slim images are exactly the "narrower cases". Rebuild them, then test from inside the container as well as from a browser.