The most consequential story in cybersecurity news today is not a breach of a website — it is a breach of the system that decides which websites to trust. The private keys of eight intermediate certificate authority (CA) certificates belonging to eMudhra — the Indian CA that sells certificates under the emSign brand — are compromised, Mozilla and Google's Chrome Root Program confirmed on October 20, 2026. Whoever holds an intermediate CA key can mint a certificate for any website that browsers would accept. Chrome and Firefox blocked the certificates within hours of the October 17 report. The rest of the software world only caught up on October 20 — and only where someone actually installs the update.
Two days after the root programs moved, eMudhra's board decided on October 22 to exit the global SSL/TLS certificate business entirely. That business brings in about 1 percent of the company's revenue. Affected customers will get free replacement certificates from partner certificate authorities, though eMudhra has not named the partners and has given no date for the exit. Its revocation and status services keep running until every certificate it issued has expired or been replaced, and its other businesses (digital signatures, eSign and the CertiNext platform) continue.
The deadline that matters is October 27. Chrome stops trusting the emSign ECC Root CA - G3 root on the morning of October 27, Pacific time, and Mozilla decided on October 20 to remove the same root from Firefox. About 30,800 unexpired certificates chain to that root, by Chrome's count from Certificate Transparency logs on October 21, and 99.9 percent of them were issued through InCommon, the higher education certificate service run by Internet2, which moved onto eMudhra's CertiNext platform between April and July 2026. Google has told operators whose certificates sit under that root to get new certificates from another PKI hierarchy in the Chrome Root Store right away.
The RSA root, emSign Root CA - G1, keeps serving for now. Mozilla is not removing it yet, and Chrome is still deciding what to do with eMudhra's remaining roots. One detail needs watching: a revocation list published on October 14 for emSign Root TLS CA - G1 carries a signature that does not verify. A participant in Mozilla's public bug report said on October 22 that it appears to have been signed with the key of an OCSP certificate, which points to the wrong signing key being used rather than another weak key. Chrome posted 12 questions to the bug report on October 21; as of October 22, eMudhra had not answered any of them in public.
The history behind those questions is not reassuring. In 2025, eMudhra published invalid revocation lists for six of the same intermediates and later told Mozilla they had been re-signed with the flawed keys, the same weak keys exposed this month. Chrome says that failure to disclose raises serious concerns about eMudhra's transparency and incident handling. eMudhra says the eight weak keys were never used to issue certificates and that its systems were not breached.
About 30,000 certificates need replacing, and the mechanics are the hard part. Roughly 97 percent were issued through ACME, the automated protocol most servers use to request and renew certificates, and a standard ACME client will not replace a certificate outside its renewal window unless it supports ACME Renewal Information (ARI) or someone steps in by hand. If your certificate chains to the ECC root, waiting for automatic renewal is not a plan.
Six of the eight compromised intermediates — 75 percent of the set — exist to sign website certificates; the remaining two sign code. The six TLS intermediates were issued by emSign Root TLS CA - G3 and chain to emSign ECC Root CA - G3, a root that sat in the Chrome and Apple root stores and, until October 20, in Mozilla's. Each of the eight also exists as a cross-signed copy under Sectigo's AAA Certificate Services root; Chrome's block matches the public key, so it catches the cross-signed copies too. The compromise was reported on the evening of October 17 by a researcher credited by Mozilla only as Wayne, who proved possession by signing a message with each of the eight keys. How the keys left eMudhra — and when — is not known. eMudhra has revoked all eight certificates.
The browser response was the fast part. Chrome's CRLSet block was live 100 minutes after the report arrived; Mozilla finished pushing its OneCRL block to standard Firefox installations by 22:59 UTC the same evening. Apple blocked the certificates on October 19 and Microsoft on October 20. None of this required a browser update or a restart — revocation lists are fetched automatically. That machinery is exactly what the rest of the ecosystem lacks. A Go binary, a Python script using certifi, or a Rust program using webpki-roots carries its own bundled root store and typically never checks revocation at all: it keeps trusting a chain until the bundle changes. That is why the October 20 fixes matter more than the browser blocks — and why they only protect you if you install them, and, for Go, rebuild with the new release.
Note the split in approach: key-blocking (Chrome, Go) surgically rejects the eight compromised keys, while root removal (NSS, certifi, webpki-roots) cuts off every certificate chaining to the emSign root — including perfectly legitimate ones. Mozilla, which removed the root from NSS, acknowledged some servers will become unavailable to users of its trust list until those servers move to new chains. Chrome has also said it will remove emSign ECC Root CA - G3 in version 43 of its root store and is reviewing eMudhra's other root, emSign Root CA - G1.
DomainGuard — Ingenious AI's domain-impersonation and trust shield — exists for the layer this incident exposes: the names, domains, and certificate chains your customers are asked to trust. Get early access on WhatsApp.
1. How was the compromise of the eight eMudhra keys proven to the root programs?
2. How fast did Chrome block the TLS intermediates after the October 17 report?
3. Were rogue certificates issued with the stolen keys found?
4. Why do Go and Python programs stay exposed after browsers are fixed?
5. What happens to legitimate websites that chain to emSign ECC Root CA - G3?
The private keys of eight eMudhra intermediate certificate authority (CA) certificates were compromised: the EM DV, OV, and EV TLS CA - G3B and - G3C certificates, plus two code-signing intermediates (EM OV CS CA - G3B and - G3C). A researcher reported the compromise to the browser root programs on October 17, 2026, proving possession of the keys by signing a message with each one. How the keys left eMudhra, and when, is still unknown. eMudhra has revoked all eight certificates.
Very low. Chrome received the report at 18:05 UTC on October 17, 2026 and had a CRLSet update blocking the six TLS intermediates by 19:45 UTC; Mozilla finished pushing its OneCRL block to Firefox by 22:59 UTC the same evening. Both browsers fetch these revocation lists automatically — no update or restart was needed. Chrome also confirmed that no TLS certificates chaining to the six web intermediates had been logged to Certificate Transparency before the block, so none could have been trusted by default in Chrome or other CT-requiring browsers.
Inspect your site's certificate chain: in a browser, open your site, view the certificate details, and read the issuer chain; from a terminal, run openssl s_client -connect yourdomain:443 -showcerts and read the issuer names. If any intermediate is named EM DV TLS CA - G3B or - G3C, EM OV TLS CA - G3B or - G3C, or EM EV TLS CA - G3B or - G3C — or the chain tops out at emSign ECC Root CA - G3 or emSign Root TLS CA - G3 — your chain is affected and you should re-issue under a new chain. Free chain visualizers such as SSL Labs' SSL Test show the same issuer names.
Fixes released October 20, 2026: Go 1.27.3 and 1.26.10 reject any chain containing one of the eight keys (CVE-2026-111943), but Go programs only pick this up when rebuilt, and Go 1.25 and older get no fix. Firefox 158.0.1 (and ESR releases) carries the OneCRL block for installations that cannot receive Remote Settings (CVE-2026-113470). NSS 3.131.1 removes emSign ECC Root CA - G3 from its trusted list; Python's certifi 2026.10.19 and Rust's webpki-roots 1.0.10 drop the same root from their bundles. Node.js and Composer fixes were still pending as of October 20.
Re-issue your certificates under a new chain that does not pass through the eight revoked intermediates or the emSign ECC Root CA - G3 root. Several trust stores (NSS, Python certifi, Rust webpki-roots, Homebrew ca-certificates) removed that root entirely rather than blocking only the compromised keys, and Mozilla has removed it from NSS — so even a legitimate certificate chaining to that root will stop being trusted by software using those stores until the site moves to a new chain.
Sources: The Hacker News, October 20, 2026 (reporting Mozilla's and the Chrome Root Program's October 20 confirmations, the October 17 report and block timelines, and the October 20 fix releases) · Dennis Jackson's published certificate list for the eight compromised intermediates · Go security release notes for 1.27.3 / 1.26.10 (CVE-2026-111943) · Mozilla security advisory for Firefox 158.0.1 (CVE-2026-113470). Facts cross-checked against the Mozilla blog and Chrome Root Program statements as cited in that reporting on October 20, 2026.
Update — October 22, 2026: The Node.js fix that was still pending when this page was written has shipped. Node.js's October 21, 2026 security releases (22.23.4, 24.22.1, and 26.12.1) block the same eight compromised eMudhra intermediate keys and remove three emSign roots from Node's bundled trust list. The block had to ship in code because Node.js does not perform certificate revocation checks by default — without the update, a chain built on one of these keys still passed. Go made the same block on October 20. The same Node.js releases also fix a Brotli decoder flaw the project says can allow remote code execution — see the Node.js Brotli RCE check.