Eight eMudhra Intermediate CA Keys Were Computable From Public Certificates

Eight intermediate certificate authority keys belonging to eMudhra, the Indian CA that sells certificates under the emSign brand, are compromised. Mozilla and the Chrome Root Program confirmed it on October 20, 2026. The keys were not stolen. They were generated with so little randomness that anyone can compute them from the public certificates. Mozilla did exactly that within two hours of receiving the report, and researchers have since published all eight keys.

An intermediate CA signs the certificates that websites and software publishers present. Whoever holds one of these keys could issue a certificate for any domain that a client trusting the chain would accept. Six of the eight were TLS intermediates covering DV, OV and EV issuance. Two were code-signing intermediates. The weak keys have sat in public root stores since the April 2025 ceremony that created them, roughly 18 months. Whether anyone exploited them in that window is not known.

What Was Compromised

eMudhra said on October 21 that a flaw in its April 2025 key ceremony produced a second, weak set of keys alongside the intended ones, and that the weak set is what was published to browser root stores. The affected certificates, issued through eMudhra BV in the Netherlands and eMudhra Inc in the United States, are:

• Domain validated TLS: EM DV TLS CA - G3B and EM DV TLS CA - G3C
• Organization validated TLS: EM OV TLS CA - G3B and EM OV TLS CA - G3C
• Extended validation TLS: EM EV TLS CA - G3B and EM EV TLS CA - G3C
• Code signing: EM OV CS CA - G3B and EM OV CS CA - G3C

The six TLS intermediates were issued by emSign Root TLS CA - G3 and chain to emSign ECC Root CA - G3, which sits in the Chrome and Apple root stores and sat in Mozilla's until October 20. Each of the eight also exists as a second certificate carrying the same public key, cross-signed by Sectigo under its AAA Certificate Services root, according to a list published by Mozilla cryptography engineer Dennis Jackson.

How Fast the Browsers Moved

The researcher, credited by Mozilla only as Wayne, proved possession by signing the message "We have a problem here - Wayne" with each of the eight keys and sending it to the root programs on October 17. The response timeline:

• October 17, 18:05 UTC: Chrome Root Program receives the report
• October 17, 19:45 UTC: Chrome CRLSet update blocks the six TLS intermediates, 100 minutes after the report
• October 17, 20:06 UTC: Mozilla receives the report
• October 17, 22:59 UTC: Mozilla finishes pushing a OneCRL block to Firefox installs with standard settings
• October 19: Apple blocks the certificates; other trust stores notified
• October 19, about 22:00 UTC: Android devices receive an equivalent block through Google Play Services
• October 20: Microsoft blocks the certificates; Go ships URGENT security releases

CRLSets and OneCRL are fetched by the browsers on their own schedule, so users needed no update or restart. Chrome's block matches the public key rather than the certificate, which also catches the Sectigo cross-signed copies. Chrome did not need to block the two code-signing intermediates because its TLS verifier will not build a path through an intermediate restricted to code signing. eMudhra has since revoked all eight.

Where the Exposure Remains

The CT protection and the pushed revocation lists cover browsers. They do not cover most of the software that runs inside an enterprise. Go binaries, Python applications using the certifi bundle, and many other TLS clients do not check revocation data and do not enforce CT. They keep trusting a chain until their code or their root bundle changes. A forged certificate never logged to CT would be accepted by those clients without complaint.

Apple is a second gap. Its root list for iOS 26 and macOS 26, published in December 2025, still includes Sectigo AAA Certificate Services, the root behind the cross-signed copies. Apple's October 19 block addresses the eight certificates, but it depends on devices receiving that update.

The two code-signing intermediates also fall outside the browser story entirely. A signing certificate issued from either key would carry an eMudhra chain into any platform that trusts it for code signing, and the browser CRLSet and OneCRL mechanisms do nothing for that path.

Vendor Fixes Released So Far

Mozilla's guidance for trust store operators is tiered: no action is needed where clients reliably check revocation and fail closed; where software can block individual intermediates, block the eight now; otherwise consider removing trust in the roots that signed them. Published fixes:

• Go 1.27.3 and 1.26.10: rejects any chain containing one of the eight keys, CVE-2026-111943, released October 20, rebuild required
• Firefox 158.0.1, ESR 115.43.1 and ESR 153.5.1: carries the OneCRL block for installs that cannot receive Remote Settings, CVE-2026-113470, released October 20
• NSS 3.131.1: removes emSign ECC Root CA - G3 from the trusted list, released October 20
• Python certifi 2026.10.19: drops emSign ECC Root CA - G3 from the bundle
• Rust webpki-roots 1.0.10: drops emSign ECC Root CA - G3
• Homebrew ca-certificates 2026-09-25_1: excludes emSign ECC Root CA - G3 and related emSign roots

Go handled its fix on the URGENT track, which its security policy reserves for threats to ecosystem integrity or flaws exploited in the wild. Neither the Go issue nor the release notes say which condition applied. The eight hash values in Go's code match the eight eMudhra certificates.

RedEye Assessment

This is a key generation failure, not an intrusion, and that makes it worse in one respect: there is no attacker dwell time to bound. The keys were derivable by anyone from the day the certificates were published. Mozilla says it does not currently believe other CAs are affected, and Chrome says it checked every other CA certificate in its store and "found no other instances of this failure mode."

The browser response was fast and effective. The residual risk sits in server-side and embedded TLS clients that rely on static root bundles, in unrebuilt Go services, in Apple devices that trust the Sectigo cross-sign root, and in code-signing trust. Those are the places a forged certificate from these keys would still work, and they are the inventory most organizations know least about. RedEye can assess where your environment depends on static trust stores and which deployed services still carry the affected roots.