One of eMudhra's Certificate Authority Keys Was the Number 4, and Now Chrome Is Pulling Its Root

The secret keys behind eight trusted certificate authorities run by Indian CA eMudhra were numbers small enough to guess. One of them was 4. With any of the six TLS keys, anyone could have forged an HTTPS certificate for any website on the internet.

Browsers blocked the certificates within hours of the report. Now Google is removing eMudhra's ECC root from Chrome on October 27 and openly reviewing whether the company should stay trusted at all.

Just, 4

"One of eMudhra's certificate authority private keys is the number 4," security researcher Scott Helme wrote. "Not a number that starts with 4, or the number 4 followed by a few hundred random digits, just, 4." He recovered all eight from their public certificates on his laptop in under a second: 156, 230, 115, 56, 155 and 4 for the TLS intermediates, and 66 and 237 for two code-signing ones.

A P-384 private key should be a random 384-bit number, roughly 10^115 possibilities. Yet nothing looked wrong. A public key derived from 4 is a valid curve point and passes every structural check. Each key sat in two certificates, one issued by eMudhra and one cross-signed by Sectigo. Helme later noted that an AI agent recovered the keys from a single prompt.

"Normally when a CA key is compromised, someone stole it!" Helme wrote. "Here, nobody had to steal anything. The key was effectively public from the day the certificate existed."

The flaw was found on Saturday, October 17, by a researcher known as Wayne, who was running a check against the Common CA Database. Wayne proved it by signing "We have a problem here" with each key and reported it to Apple, Google, Microsoft, Mozilla and eMudhra. Mozilla's incident report says the eight came from a batch of 24 intermediates generated on April 30, 2025, all using integers below 256.

Cloudflare described the stakes plainly: "an attacker can create a forged certificate for any domain and use it to impersonate servers to intercept or modify traffic." Mozilla's Dennis Jackson said "the impact of this incident could not be higher," worried most about devices and apps with no reliable way to learn a certificate was revoked.

A fast block, a slow cleanup

Mozilla blocked the certificates through OneCRL within about three hours, shipped Firefox 158.0.1 and ESR updates, and is removing the root from NSS. Chrome landed a CRLSet block the same evening and Android received an equivalent update through Google Play Services. Apple followed on October 19 and Microsoft on October 20.

Google says no TLS certificates chaining to these CAs were logged to Certificate Transparency before its block, so clients that enforce CT, like Chrome, were not exposed to forgeries. There is no report that anyone used the keys. But Chrome is still pulling "emSign ECC Root CA - G3" from its root store starting the morning of Tuesday, October 27, Pacific time. Some legitimate certificates chaining to it will stop working, and site operators must "immediately acquire and install a new TLS certificate from another PKI hierarchy."

"Due to the seriousness of this incident, the Chrome Root Program is closely investigating the ongoing inclusion of eMudhra's remaining CA certificates in the Chrome Root Store," Google added.

eMudhra's side

eMudhra says none of the affected intermediates issued any end-entity certificates, seven of the eight were never in production, and its root keys and infrastructure were not compromised, with no data breached. It learned of the problem late on October 18, India time, and revoked all eight on October 19. The intermediates came from an April 2025 key ceremony, entered browser trust lists in mid-2025 and passed two independent audit cycles.

On Mozilla's bug tracker the company blamed a faulty ceremony script that created a second set of weak keys on the hardware security module. Their labels resembled the proper keys, and staff picked the weak ones. eMudhra has stopped issuing from that root and estimates about 30,000 customer certificates need replacing.

That bill lands on customers, and on the software that never checks revocation at all. The researchers' disclosure page notes many clients do not consume revocation information and will need updates to stop trusting the bad keys. Earlier this month, the web's trust chain was bent from a different direction, when hackers hijacked three countries' domain registries to obtain real HTTPS certificates for Google.

Some offers on this page may be paid placements or contain affiliate links.