Chrome Drops eMudhra Root on Oct 27 After CA Keys as Small as the Number 4

Google Chrome will stop trusting an entire root certificate from Indian certificate authority eMudhra on Tuesday, October 27, 2026, after researchers found that eight of its signing keys were so weak that one of them was literally the number 4. The keys could be recovered from public certificates in under a second, which in theory let anyone create a trusted HTTPS certificate for any website.

Browsers blocked the eight certificates within hours of the October 17 report, and there is no public evidence anyone abused them. But many apps, servers and devices still trust them until they are updated, and eMudhra has now quit the global website certificate business.

Key facts at a glance

• What broke: eight eMudhra intermediate certificate authority (CA) keys, created on April 30, 2025, had private keys of 4, 56, 66, 115, 155, 156, 230 and 237. A properly made key is a random 384-bit number.
• Browser response: Chrome received the report at 18:05 UTC on October 17 and blocked the certificates at 19:45 UTC, according to Google.
• The deadline: Chrome removes the emSign ECC Root CA - G3 root for all devices on the morning of October 27, Pacific time. Mozilla removed it from Firefox's NSS trust list on October 20.
• The company's exit: on October 22, eMudhra's board decided to leave the global SSL/TLS certificate business, which it says is about 1% of its revenue.
• Who still needs to act: website operators using that root, and anyone running software that keeps its own list of trusted certificates.

How a certificate authority's keys ended up this weak

Every browser padlock depends on a chain of trust. A website's certificate is signed by an intermediate certificate authority, which is signed by a root that browsers and operating systems trust. Whoever holds an intermediate's private key can sign a certificate for any domain.

These keys use elliptic-curve cryptography on the P-384 curve. Security researcher Scott Helme explained that the private key should be a random 384-bit number, giving roughly 10 to the power of 115 possibilities. Instead, each eMudhra key fit in a single byte, so finding it took at most 255 guesses. Helme said he recovered all eight on his laptop "in less than a second."

The eight certificates were six website (TLS) issuing CAs and two code-signing CAs, all created in April 2025, Helme wrote. Each was also cross-signed by Sectigo's AAA Certificate Services root in May 2025, which widened the number of systems that trusted them.

eMudhra has given its own account. In a statement on the incident, it said the keys were generated on FIPS 140-2 Level 3 certified hardware security modules, and that a flaw in a key wrap/unwrap step during the ceremony produced a second, weak set of keys alongside the strong ones. The weak keys were the ones published to browser root stores. The company said the problem went undetected for about 18 months, through two independent audit cycles, and that it has not yet confirmed the exact root cause.

The researcher, credited as Wayne, proved it by signing the message "We have a problem here – Wayne" with each key, according to a disclosure site run by Mozilla engineer Dennis Jackson.

How browsers and big platforms responded

Google said Chrome pushed a CRLSet update, its built-in blocklist, less than two hours after the report, so users were protected without updating or restarting the browser. Android devices received an equivalent block through Google Play Services around 22:00 UTC on Monday, October 19.

Mozilla received the report at 20:06 UTC on October 17 and finished pushing a Firefox block at 22:59 UTC. Jackson's disclosure site says Microsoft platforms have blocked the certificates since October 20 and Apple products since October 22.

A key safeguard also held. Google said no website certificates chaining to the six TLS intermediates had been logged in Certificate Transparency, the public record that trusted certificates must appear in. Because Chrome enforces that record, no forged certificate from these CAs could have worked in Chrome. Google also said it checked the other keys in its root stores and found none with the same weakness.

Cloudflare learned of the problem around 17:00 UTC on October 19. Its blog post says it found no active exploitation and shipped updated WARP and 1.1.1.1 apps plus cloudflared 2026.10.2 by October 20.

Key dates

Why the cleanup outside browsers is the hard part

Browsers have one product to fix and a way to push blocklists instantly. Most other software does not. Helme noted that tools such as curl, Python, Node, Go, Java and git typically trust a certificate bundle stored on disk, do not check revocation by default and do not check Certificate Transparency. For those clients, eMudhra revoking the certificates changes nothing until the bundle itself is updated.

"This will be a massive cleanup job, bigger than Heartbleed," Filippo Valsorda, a cryptography maintainer for the Go programming language, said. He pointed to "a very, very long tail" of IoT devices, Docker containers, forgotten Linux machines and command-line tools that ship their own copy of the roots.

Progress is uneven. Patches have landed for Go, Python's certifi, pip, uv and Electron, and for the ca-certificates packages of Ubuntu, Debian, Fedora, Arch and Alpine, while Node.js, Bun and FreeBSD were still listed as pending. Jackson's site warns that Electron-based apps such as Slack and Discord only get the fix when the app itself is rebuilt on a patched Electron release.

Java is another gap. Java vendor Azul said that Java does not check revocation by default, and said its updated Zulu builds block the eight certificates.

eMudhra exits global website certificates

eMudhra announced on October 22 that its board had decided to voluntarily withdraw from the global SSL/TLS certificate business. In the press release, the company said it revoked the affected CAs within 14 hours of discovery, that its infrastructure was not compromised and that no data was breached.

The company also said the distrusted root affects one customer ecosystem in the United States, and that seven of the eight intermediates were never used in production. The one that was had not issued a single certificate. eMudhra said it will replace affected certificates free of charge through partners, and it is offering certificates issued by Sectigo. Its G1 RSA roots keep working during the transition.

Its digital signature, eSign and enterprise products in India and elsewhere run on separate infrastructure and are not affected, the company said.

Other views on the risk

eMudhra's chairman, V. Srinivasan, argued the reaction has been outsized. "The level of social media amplification around this incident has brought scrutiny that is out of proportion to SSL/TLS's place in our business," he said in the October 22 release.

Some analysts also see the remaining danger as narrow. Sakshi Grover, research director at IDC, said that exploitation would require an attacker positioned to intercept traffic, describing the risk as "limited and targeted rather than broad." Apps such as Signal, WhatsApp and WireGuard, which do not rely on TLS for confidentiality, are unaffected.

Others are less relaxed about the company's fallback plan. Niyati Daftary, principal analyst at Gartner, said organisations should treat the G1 roots "as a possible bridge, not automatically as the final destination." Yash Kadakia, CTO of Security Brigade, added: "The last thing organisations need is to migrate twice."

What it means for you

If you are an everyday user in the US, UK, Canada or Australia, an up-to-date Chrome, Firefox or Safari browser already blocks these certificates. The practical steps are to install pending operating system updates, restart Android phones so Google Play Services applies its block, and update desktop apps like Slack and Discord when they prompt you.

Public Wi-Fi deserves a little extra care until your apps are patched. Attackers with control of a local network, such as at a coffee shop or university, face a much smaller hurdle in intercepting traffic.

If you run a website, check whether your certificate chains to emSign ECC Root CA - G3. Google's instruction is direct: operators "must immediately acquire and install a new TLS certificate" from another trusted hierarchy before Chrome's change lands.

If you manage servers or write software, update system ca-certificates packages, language libraries such as certifi, container base images and Java runtimes, then restart or redeploy services. Cloudflare warned against "fixing" new certificate errors by turning off verification, since that removes the protection the updates restore.

What happens next

The next milestone is Tuesday, October 27, when Chrome's root removal reaches all devices that rely on the Chrome Root Store. Any site still serving a certificate from that root will start showing errors in Chrome.

eMudhra has promised a full root-cause report to the browser root programs and says revocation services will keep running until every certificate it issued has expired or been replaced. Linux distributions and runtimes still listed as pending, including Node.js, Bun and FreeBSD, have yet to ship fixes, and Jackson's site is tracking them.

The open question is the long tail. Helme pointed out that the keys were recoverable for about 17 months, and "there is no way to know whether someone did." That risk sits mainly with software that does not check Certificate Transparency.

The bottom line

One mistake in a key ceremony has rippled across the internet's trust system, even though browsers reacted within hours. Ordinary browsing is protected, but servers, apps and devices with their own certificate lists need attention now.

1. Update your browser, operating system and desktop apps this week, and restart Android devices.
2. Site owners should check their certificate chain and replace any certificate from emSign ECC Root CA - G3 before October 27.
3. Developers and IT teams should refresh trust stores in packages, containers and Java runtimes, then redeploy.
4. Never disable certificate verification to silence new errors; replace the certificate or update the client instead.
5. Test with Jackson's checker at emudhra.we-have-a-problem.com to see whether a client still trusts the compromised certificates.