eMudhra's Compromised Keys: What Indian Websites Must Do Before 27 October

eMudhra, an Indian certificate authority, blames a flaw in its April 2025 key ceremony. Sites with certificates chaining to one removed emSign root must move before 27 October.

Illustration of an eMudhra certificate store listing eight intermediate CA entries marked REVOKED, with the eMudhra logo
An illustration of a certificate store listing eMudhra intermediate CA entries marked as revoked.

An Indian certificate authority is at the centre of a global web-security incident. eMudhra, which sells certificates under the emSign name, had eight of its intermediate certificate authority keys found to be computable from the public certificates that carry them.

Browsers blocked the affected certificates within hours of a report on 17 October 2026. Chrome's removal of the root that signed them is expected to reach devices on 27 October, and any Indian company whose website uses a certificate that chains to that root has to move to another certificate before then.

Eight Intermediate Keys, Six for Websites and Two for Code Signing

The eight certificates are intermediate certificate authorities. An intermediate sits between a browser's trusted root and the certificate a website presents. Six of the eight issue website (TLS) certificates, and two issue code-signing certificates.

The Mozilla thread on the public security list describes six TLS-issuing intermediates and two code-signing ones.

The Hacker News describes the keys as generated with too little randomness, which is what allowed them to be computed from the public certificates. Mozilla's post describes the root that signed the affected intermediates as the one its update removes.

Because the private keys were generated with too little randomness, anyone could forge trusted HTTPS certificates for any site against clients that still trusted these intermediates, Google says. Cloudflare puts the risk the same way, noting that an attacker could forge a certificate for any domain and impersonate servers. Cloudflare also says its remediation work addresses certificate-based authentication, not a weakness in TLS's encryption algorithms.

Google says no TLS certificate chaining to these intermediates was logged to Certificate Transparency before the block.

The Timeline in Indian Standard Time

Google gives the first report to the Chrome Root Program at 18:05 UTC on 17 October 2026, which is 23:35 IST that night. Chrome shipped a block through its CRLSet list at 19:45 UTC, or 01:15 IST on 18 October.

Mozilla received its own report at 20:06 UTC on 17 October, which is 01:36 IST on 18 October. Its OneCRL block reached standard Firefox installs at 22:59 UTC, or 04:29 IST on 18 October. Android devices received an equivalent block through Google Play Services at about 22:00 UTC on 19 October, which is 03:30 IST on 20 October.

Cloudflare says it became aware of the problem at about 17:00 UTC on 19 October, which is 22:30 IST that night. It released updated Cloudflare One Client and WARP apps at 02:00 UTC on 20 October, a cloudflared update at 09:15 UTC, and finished deploying its CDN and server-side Zero Trust mitigations at 19:20 UTC, or 00:50 IST on 21 October. Cloudflare says it patched critical services before public disclosure and has found no active exploitation of the issue on its own services.

Mozilla and Google published their posts on 20 October. eMudhra posted a statement on its website on 20 October, and on 21 October it issued a press release filed with the BSE stock exchange, according to The Hacker News. Google says Chrome's removal of the emSign root is expected to reach devices on the morning of 27 October, Pacific time.

What eMudhra Says About Its Indian Signing Businesses

eMudhra attributes the weak keys to a flaw in its April 2025 key ceremony. According to The Hacker News, the company says its roots and issuing authorities passed independent audits two years in a row, and that its root keys and other intermediates are not affected.

The company also says its Indian digital signature certificate and eSign businesses run on separate infrastructure. The Hacker News reports that eMudhra puts its global TLS business at about 1% of revenue.

eMudhra says only one of the eight intermediates was deployed in production and that none had issued an end-entity certificate. Google separately says no TLS certificate chaining to these authorities reached Certificate Transparency before the block.

The compromise and the removal reach different parts of the chain. The keys belong to the intermediates, while the Chrome removal targets emSign ECC Root CA - G3, the root above them. Google says that root signed the compromised authorities, and that eMudhra has committed to helping subscribers whose certificates chain to it.

Some certificates that chain to the removed root are expected to stop working in Chrome once the removal reaches devices on 27 October unless they are replaced.

What Indian Websites Using emSign Certificates Must Do Before 27 October

Google says operators whose certificates chain to emSign ECC Root CA - G3 must obtain and install a new TLS certificate from another hierarchy in the Chrome Root Store. Some legitimate certificates chaining to this root will stop working in Chrome, and eMudhra has committed to helping affected subscribers migrate.

Some certificates that chain to the removed root are expected to stop working in Chrome once the removal reaches devices on 27 October unless they are replaced. Mozilla notes that trust-store operators should block the eight intermediates where a system allows it, or otherwise consider removing trust in the roots that signed them. Mozilla also says some servers may be unavailable to non-Firefox users of its trust list until they move to new chains.

Chrome's Certificate Transparency policy requires publicly trusted TLS certificates to carry enough valid Signed Certificate Timestamps from qualifying logs. Certificates without compliant logged timestamps fail validation in Chrome versions that enforce the policy, so a replacement certificate must meet that test as well as the new chain.

Systems that keep their own trust stores need checking separately from the browser. Cloudflare says customers running their own origins, mutual TLS, or containers may need to act on software or trust configurations. Customers on its Full (strict) or Strict encryption modes should review custom origin certificates and server configurations, and Cloudflare says it is updating Automatic SSL/TLS to notify customers still using distrusted certificates. Cloudflare also warns developers not to disable certificate verification to clear errors, because that removes the protection.

Google says it is closely investigating the ongoing inclusion of eMudhra's remaining CA certificates and will share further updates in public forums such as the CCADB public list.

What the Incident Means for India's Trust-Services Industry

Google says it confirmed that no other keys in its root stores share the same weak-randomness failure. Mozilla says it does not believe other certificate authorities are affected for now. Google adds that CT logs have been updated to reject certificates chaining to the compromised authorities.

The removal works at the root. Google says some legitimate certificates chaining to that root will stop working, so the cost of the incident reaches certificates that were never compromised.

Whether anyone exploited the flaw is not known, according to The Hacker News. Cloudflare reports no active exploitation on its services and says further remediation work is still ongoing.

Two questions remain open. The first is how the Chrome Root Program's review of eMudhra's remaining certificate authorities turns out; Google says it will share updates in public forums such as the CCADB public list. The second is what Indian signing customers will be told about their own products.