A certificate authority is only as trustworthy as the secrecy of its private keys. On Saturday, October 17, 2026, a security researcher reported that eight of eMudhra's keys were not secret in any meaningful sense. According to Google's Chrome Security team, the private keys behind eight eMudhra subordinate (intermediate) CA certificates had been generated with insufficient randomness. That weakness meant anyone could work out the keys and use them to forge HTTPS certificates that browsers would trust.

Within days, Chrome, Android, Firefox and the Go programming language each shipped blocks against the eight certificates. Google and Mozilla are also going further and pulling the root certificate that signed them. For most people the browser fixes arrive automatically. Site operators whose certificates chain to that root, and teams that ship Go binaries, have work to do.

What went wrong

Some background first. Browsers trust a short list of "root" certificates. Those roots sign "intermediate" certificates, and the intermediates sign the certificates that websites actually present. If an attacker holds an intermediate's private key, they can issue a certificate for any domain, and every client that trusts the root will accept it.

Cryptographic keys are only safe when they are generated from enough unpredictable random data, which cryptographers call entropy. Without enough entropy, the possible keys fall into a small range that can be searched. The Hacker News, in a corrected version of its report, said the keys could be computed from the public certificates. It also reported that Mozilla recovered the keys itself within two hours of receiving the report, and that researchers have since published them. Whether anyone exploited the flaw before disclosure is unknown.

The publication identified the eight certificates as EM DV, OV and EV TLS CA - G3B and G3C, which are six intermediates for website certificates, plus EM OV CS CA - G3B and G3C, two for code signing. The six TLS intermediates were issued by emSign Root TLS CA - G3, which chains up to emSign ECC Root CA - G3. That root was trusted in Chrome's and Apple's root stores, and in Mozilla's until October 20. The Hacker News added that each of the eight also exists in a version cross-signed by Sectigo's AAA Certificate Services root. Because Chrome's block matches the public key rather than the certificate, it catches those cross-signed copies too.

eMudhra's account

eMudhra published a statement on October 20 and updated it on October 21. This is the company's own version of events and has not been independently confirmed. It says the eight intermediates were created in a key generation ceremony on April 30, 2025. A flaw in one key wrap/unwrap step of that ceremony produced a second, weak set of keys next to the intended strong ones, and the weak set was the one published to browser root stores. The company says the keys were held on FIPS 140-2 Level 3 hardware security modules and that the problem went unnoticed for about 18 months, through two audit cycles. eMudhra says it has not yet confirmed the exact root cause.

On the timeline, eMudhra says it learned of the issue late on October 18, India time. It says the researcher notified Apple, Google, Microsoft and Mozilla, and that eMudhra revoked all eight intermediates on October 19. In its latest update, the company says seven of the eight were never used in production and the one that was issued no certificates. eMudhra also says its infrastructure was not compromised and that it has no evidence the keys were recovered or exploited before disclosure. It describes the impact as limited to TLS certificates chaining to the distrusted ECC root, within one US customer ecosystem, and says its Indian digital signature and eSign services are separate.

The market reacted. The Hacker News, citing Business Standard, reported that eMudhra shares fell 20% in Mumbai on October 21.

How each platform responded

Chrome and Android

Google says the Chrome Root Program received the report at 18:05 UTC on October 17. By 19:45 UTC the same day it had shipped a CRLSet update that blocks the certificates by the hashes of their public keys (SPKI hashes). CRLSet is Chrome's built-in, automatically updated revocation list. Android received an equivalent block through Google Play Services at about 22:00 UTC on Monday, October 19.

Google says none of the TLS certificates chaining to the six TLS intermediates had been logged to Certificate Transparency (CT) before the block. CT is a set of public, append-only logs of issued certificates, and Chrome enforces CT for publicly trusted certificates. That means any forged certificate would not have worked against clients that enforce CT, which includes Chrome and Android apps that target the latest SDK version or have otherwise opted in to CT. Google says CT logs have also been updated to reject chains to these CAs, and that a review of its root stores turned up no other keys with the same weak-entropy problem.

The bigger step is the root. Google has removed emSign ECC Root CA - G3 from the Chrome Root Store. It expects the change to reach all devices on the morning of Tuesday, October 27, 2026 (Pacific time), with Canary and Beta channels getting it sooner. Google also says it is closely investigating whether eMudhra's remaining CAs should stay in the store.

Firefox and Thunderbird

Mozilla blocked the intermediates on October 17 through OneCRL, its revocation list, and pushed that block out through its RemoteSettings channel the same day. The October 20 advisory MFSA 2026-111 tracks the issue as CVE-2026-113470, rated high impact by Mozilla. Firefox 158.0.1 builds the updated OneCRL list into the browser, so the block still applies on machines where RemoteSettings is disabled by policy or otherwise unreachable.

According to the NVD record, the fix is also in Firefox ESR 153.5.1, Firefox ESR 115.43.1, and Thunderbird 158.0.1 and 153.5.1. The record carries a secondary CVSS 3.1 score of 5.4 (Medium). CISA's SSVC entry lists exploitation as "none." The same Firefox advisory fixes three unrelated bugs: CVE-2026-113399 (SVG boundary conditions, high), CVE-2026-113400 (uninitialized memory in cubeb, moderate) and CVE-2026-113401 (PDF viewer denial of service, low). eMudhra's statement, quoting Mozilla, adds that Mozilla is updating NSS, its cryptographic library, to version 3.131.1 to remove the root.

Go

Go took the least visible route with the most practical consequences. On October 20 the project released Go 1.27.3 and Go 1.26.10 on its URGENT security track, with no advance notice. The releases make Go's certificate verifier reject any chain that passes through the eight intermediate keys. Because the filter matches hashes of the public keys, cross-signed copies of the certificates are blocked too. Affected chains fail with the error "x509: no valid chains built."

The fix is CVE-2026-111943, titled "Distrust compromised intermediate certificates in crypto/x509." It affects Go versions before 1.26.10 and from 1.27.0 up to, but not including, 1.27.3. The Go CVE record does not name eMudhra. The Hacker News reports that the eight hashes in Go's code match the eight eMudhra certificates, and the CVE was reserved on October 17. Two details matter more here than for browsers. Go does no revocation checking, so revoking the certificates does nothing for Go clients. And Go programs keep the old behavior until they are rebuilt with a patched toolchain, so a service compiled last month still trusts the bad intermediates.

What It Means for Defenders

  • Browsers: Chrome's CRLSet and Android's Play Services block arrived automatically. Update Firefox to 158.0.1, Firefox ESR to 153.5.1 or 115.43.1, and Thunderbird to 158.0.1 or 153.5.1. This matters most on managed fleets where RemoteSettings is disabled by policy, because those machines will not have received the October 17 OneCRL push.
  • Go services and tools: Rebuild with Go 1.27.3 or 1.26.10 and redeploy. Updating the toolchain alone protects nothing that was already compiled. Make a list of Go binaries you ship or run, including vendor CLIs and agents, and ask suppliers for rebuilt versions.
  • Site operators: If any of your certificates chain to emSign ECC Root CA - G3, Google says you must replace them with a certificate from a different hierarchy in the Chrome Root Store before the root removal reaches users around October 27. Check certificates on load balancers, CDNs and APIs, not just your main website.
  • Other TLS stacks: Custom trust stores, Java keystores, appliances and anything that bundles its own CA list will not pick up browser blocklists. Check them for the eight intermediates (including the Sectigo cross-signed copies) and the emSign ECC root, and remove or distrust them where your platform allows.
  • Code signing: Two of the eight were code-signing intermediates. If your allowlisting or software-trust policies accept eMudhra code-signing chains, review that trust now, since the keys have been published.
  • CMMC and compliance teams: Note in your records which trust anchors you removed and when. It is the kind of change assessors may want to see documented.

The weak keys being public is what keeps this from being a non-event. Google's point that no affected TLS certificates appeared in CT logs protects clients that enforce CT. It does nothing for the many non-browser clients that don't enforce CT and don't check revocation, and Go is the textbook example. Those clients are where a forged certificate could still work, and they are the ones that need a rebuild or a trust-store edit.

Sources