Why Chrome and Firefox Blocked Eight eMudhra Intermediate Certificates Within Hours

An intermediate CA signs the certificates that websites present.

Between 17 and 21 October 2026, eight intermediate certificates issued under eMudhra, an Indian certificate authority that sells certificates under the emSign brand, were found to have private keys that could be worked out from their public certificates. Chrome and Firefox blocked the affected certificates within hours of the first report. eMudhra has attributed the problem to a flaw in the key ceremony it ran in April 2025, which produced a second, weak set of keys.

Why an Intermediate Key Carries So Much Weight

The private key of an intermediate CA is what signs certificates for websites. Mozilla says these keys could allow attackers to issue fraudulent HTTPS certificates for sites they do not control. Someone who could also intercept a user’s connection could then impersonate those sites and potentially read or modify the traffic.

Browser makers blocked the affected intermediates through revocation lists that Chrome and Firefox fetch without an update or restart.

The First Block Took About 100 Minutes
Google says the Chrome Root Program received the report at 18:05 UTC on 17 October and that the block for the six TLS intermediates took effect at 19:45 UTC, with no browser update needed.

The Timeline From 17 to 21 October

The first report reached the Chrome Root Program at 18:05 UTC on Saturday, 17 October. Google says Chrome confirmed the findings and pushed a block at 19:45 UTC, and that users needed no browser update or restart. Mozilla received its report at 20:06 UTC and finished pushing a block to Firefox installations with standard settings at 22:59 UTC.

Android followed on Monday, 19 October. Google says Android devices and Googlebooks received an equivalent update through Google Play Services at about 22:00 UTC. The Hacker News reports that Apple blocked the certificates on 19 October and Microsoft on 20 October.

On Tuesday, 20 October, Mozilla and the Chrome Root Program published public accounts. Mozilla released Firefox 158.0.1 for desktop and Android and updated its NSS trust store to remove the root that signed the affected intermediates. Mozilla’s post does not name that root. The Hacker News identifies it as emSign ECC Root CA – G3 and reports that Mozilla removed it the same day.

On Wednesday, 21 October, eMudhra filed a press release with the BSE in India. The Hacker News reports that the filing says the company’s global TLS business is about 1% of revenue. The Hacker News also reports, citing Business Standard, that its shares fell 20% in Mumbai trading that day.

How the Keys Were Worked Out From Public Certificates

Scott Helme, whose write-up the sources cite, says the keys were never large random numbers. Each private key was a small whole number. The test was to check each small number in turn against the public key in the certificate until one matched. A key that anyone can work out from a public certificate offers no protection to the sites that depend on it.

Helme reports that all eight keys were recovered in under a second on a laptop. One of them is the number 4. Each key was used in two certificates, one issued by eMudhra and one cross-signed by Sectigo, so 16 certificates in all. The certificates look structurally valid, so the weakness showed only when someone tried to recover the key.

Helme reports eMudhra’s account of the cause. Helme says it seems a bug in the ceremony script created a second, weak key pair on the hardware security module, and human error then led to the wrong keys being used in the certificate signing request. Helme says the keys were effectively public from April 2025.

A key that anyone can work out from a public certificate offers no protection to the sites that depend on it.

Whether Ordinary Web Users Were Exposed

None of the sources reports that the keys were used in an attack. Mozilla’s post does not say whether they were, and says more information will follow when circumstances allow. Google says no TLS certificates chaining to the six TLS intermediates were logged to Certificate Transparency before the block. As a result, Google says, fraudulent certificates from those six could not have been used against clients that enforce the logs, including Chrome.

For a visitor on an updated browser, Helme says mainstream browsers are likely safe, because Chrome and Firefox block the intermediates directly. Many other programs, however, trust the root list on the computer without checking revocation or the logs by default. In the tests Helme describes, curl, Python and Node accepted a forged certificate for a test host, and Windows CryptoAPI did too unless revocation checking was switched on; even then, only one of the two routes came back as revoked.

Helme also notes that embedded devices with frozen trust stores could keep trusting these certificates until they expire in July 2039.

What Browser Makers Changed and What Remains Open

Chrome’s block works by key, so it also covers the Sectigo cross-signed copies. The two code-signing intermediates did not need blocking. The Chrome Root Program says its verifier does not build a web-page path through intermediates limited to code signing. That accounts for the difference between the eight certificates in the first report and the six TLS intermediates named later.

Chrome will remove emSign ECC Root CA – G3 in Chrome Root Store version 43. Google’s post expects the removal to reach devices that rely on the Chrome Root Store on the morning of Tuesday 27 October, Pacific time, and says some legitimate certificates under that root will stop working. The Chrome Root Program message gives no date beyond saying the release is coming soon.

Google says website operators with certificates under that root must immediately install a certificate from another hierarchy in the Chrome Root Store to avoid breakage. It says eMudhra has committed to helping affected subscribers migrate. Chrome is still assessing the remaining eMudhra CA certificates and will share updates in public forums, such as the Common CA Database list.