Google, Mozilla, Apple and Microsoft have blocked eight intermediate certificate authority (CA) certificates issued by Indian digital trust provider eMudhra. A researcher found that their private keys were generated from predictable numbers and could be reconstructed from the public certificates. Mozilla received the report on October 17, 2026, forwarded by the Chrome Root Program, and classified it as a private key compromise.
One correction to the circulating shorthand: this was not a classic hack, and "4" was not a login password. Reports describe the keys themselves as built from tiny, guessable values. According to coverage of the incident, the eight compromised keys corresponded to the numbers 4, 56, 66, 115, 155, 156, 230 and 237. Anyone holding the private key of an intermediate CA can sign certificates that browsers would trust, which is why the problem is so serious.
Why intermediate CA keys matter
Certificate authorities vouch for websites through digital certificates that browsers and operating systems check before opening an encrypted connection. Intermediate CAs sit between a trusted root and the certificates issued to websites. If an attacker controls an intermediate key, they can forge certificates for any domain without asking the CA for anything. Mozilla engineer Dennis Jackson wrote in the public bug report that such an attacker could impersonate any website or service.
Technical details of the failure
- Eight intermediate certificates were affected. Six were intended for TLS, the encryption behind HTTPS, according to Google's security blog.
- eMudhra says the intermediates were created during a key-generation ceremony on April 30, 2025. It attributes the flaw to one step of that process and says it will publish details when its investigation closes.
- The company revoked all eight intermediates on October 19. Sectigo, a U.S.-based CA that had separately vouched for the same eMudhra certificates, revoked its versions.
- Browser makers have also moved to distrust the emSign ECC Root CA – G3 certificate that signed the intermediates.
Who has blocked what, and the real-world impact
- Chrome and Firefox: emergency blocks were distributed on October 17, reportedly without requiring a restart in default configurations. Mozilla used its OneCRL revocation list and removed the G3 root in NSS 3.131.1. Chrome has planned its own root removal.
- Apple: devices blocked the certificates on October 19.
- Microsoft: blocked them on October 20.
- Developer tooling: Go 1.27.3 drops the eight intermediates from chain verification.
- Linux and BSD: users are advised to update their ca-certificates package. The NetBSD Foundation has published instructions for blocking the certificates manually.
Reported exposure appears limited so far. eMudhra says its core infrastructure was not compromised, no data was breached, and no end-entity (website) certificates were issued from the compromised intermediates in public Certificate Transparency logs, which browsers require before trusting a certificate. That means a forged certificate would not have been accepted by default in Chrome. A security analyst quoted by CSO Online noted, however, that a key holder could mint certificates without ever requesting them from eMudhra. As of October 21, public reports had not established widespread attacks using the keys.
eMudhra says one customer ecosystem in the United States is affected, and that its certificates are being replaced through an alternate, publicly trusted CA hierarchy. The company also says its digital signature services are not affected. A preliminary eMudhra estimate puts about 30,000 certificates in the wider G3 root hierarchy as needing migration. Those are legitimate customer certificates, not certificates known to have been issued with the compromised keys.
Outlook and what to do
The remaining questions are how a key-generation process produced such weak keys, and why the keys were used in certificates at all. eMudhra is still investigating. Reports also indicate the Chrome Root Program is weighing whether to keep other eMudhra certificates in its store, so the list of blocked items may still grow.
Some applications, developer tools and software packages use certificate stores separate from browsers, so they may keep trusting the compromised keys until updated. Recommended steps:
- Update browsers and operating systems to the latest versions.
- Update Linux distribution ca-certificates packages and application-specific trust stores.
- Identify and replace any certificates in your infrastructure that chain to the affected eMudhra hierarchy.
- Never click through browser certificate warnings.
Dennis Jackson has published a test page, dv-g3b-emudhra.we-have-a-problem.com, that shows whether a client still trusts the compromised CAs. A certificate error means the client is protected.
Sources:
