Why Sites Chaining to emSign ECC Root CA – G3 Need a New Certificate Before 27 October

On 17 October 2026, a researcher reported to the browser root programs that the private keys of eight eMudhra intermediate certificate authority certificates could be worked out from the public certificates. Chrome and Firefox blocked the affected keys the same day, and both browsers fetch their block lists without a restart.

For a small business, the browser block protects visitors’ browsers, but a website whose certificate chains to that root must still install a new certificate. Chrome is also removing the root that signed these intermediates, and that removal is expected to reach devices on 27 October.

Chrome generally does not run online revocation checks. Its CRLSet is, in Chromium’s description, the primary means by which Chrome quickly blocks certificates in emergency situations. Firefox uses OneCRL, which Mozilla introduced in Firefox 37 and which in 2015 covered only intermediate certificates. Both lists reach users without a browser update or restart.

Visitors’ Browsers Were Covered Within Hours

Chrome applied its block through its CRLSet list at about 19:45 UTC on 17 October, matching the affected intermediates by their public keys. Google says Android devices received the same protection through Google Play Services at about 22:00 UTC on Monday, 19 October, and that users can trigger the update at once by restarting their device.

Firefox received the report at 20:06 UTC on 17 October and finished its OneCRL block for standard installations at 22:59 UTC. Mozilla released Firefox 158.0.1 on 20 October for a minority of users whose custom settings may have prevented the OneCRL update.

The two lists differ in scope. OneCRL covered only intermediate certificates when Mozilla introduced it, which kept the list small, and Mozilla updates it when a certificate authority in its root program tells Mozilla that an intermediate needs revoking. Firefox delivers it through its existing blocklist, which the browser checks periodically. Mozilla’s 2015 post on the system described the older route for serious certificate problems, a Firefox update that users had to download and restart into, as slow. The 2026 block arrived through the channel that needs no action from the visitor.

Google says no TLS certificates chaining to the six TLS intermediates were logged to Certificate Transparency before the block, so no fraudulent certificates from them could be used against CT-enforcing clients.

Mozilla describes the risk as an attacker intercepting a connection and impersonating a website. The Hacker News says it is not known whether anyone exploited the flaw, and Cloudflare reports no active exploitation on its own services.

Key Date
Chrome’s block on the affected intermediates was in place by about 19:45 UTC on 17 October. Google says the removal of emSign ECC Root CA – G3 is expected to reach Chrome devices on the morning of 27 October, Pacific time.

How to Check Who Issued a Site’s Certificate

The names to look for are the TLS intermediates in this family, labelled EM DV, EM OV and EM EV TLS CA – G3B or G3C, with emSign ECC Root CA – G3 at the top of the path. According to The Hacker News, the domain-validated pair is labelled with eMudhra BV in the Netherlands and eMudhra Inc in the United States.

The count of eight can cause confusion. Google’s post uses both “eight” and “six”, and the six are the TLS intermediates within the eight. The Hacker News explains that the eight are six TLS intermediates plus two code-signing intermediates, EM OV CS CA – G3B and G3C. A website certificate from this family falls among the six TLS intermediates.

A chain may also show a copy cross-signed under a Sectigo root. The Hacker News says Chrome and Firefox already distrust that root for websites, so those copies did not widen the risk. If the chain leads to emSign ECC Root CA – G3, Google says the site must install a new certificate from another hierarchy.

What 27 October Changes, and What It Does Not

Google says the removal of emSign ECC Root CA – G3 from the Chrome Root Store is expected to reach devices on the morning of Tuesday, 27 October, Pacific time, and sooner on Chrome Canary and Beta.

Google’s advice to site owners is to obtain and install a new TLS certificate from another hierarchy in the Chrome Root Store now. Google warns that some legitimate certificates chaining to the root will stop working in Chrome after the removal.

Mozilla says the NSS 3.131.1 update removes the same root from its trust store, which protects other applications that use it. Firefox is already protected through OneCRL.

Two items are still open. Google says it is reviewing whether eMudhra’s remaining CA certificates stay in the Chrome Root Store, and it will share further updates in public forums, such as the Common CA Database Public list. The Hacker News reports that Chrome is also reviewing eMudhra’s other root, emSign Root CA – G1. The 27 October removal covers only the G3 root.

Browsers protected visitors within hours of the report, but a site’s own certificate still needs checking.

Questions for a Web Host or Developer

Ask which authority issued the certificate on the live site, and whether its chain runs through emSign ECC Root CA – G3. If it does, ask the date a replacement from another hierarchy will be installed, and whether that date falls before 27 October.

Google says eMudhra has committed to helping affected subscribers migrate. Ask the host or certificate provider whether the account is one of them. Asking for the replacement and its installation date in writing gives the owner a record if errors appear after 27 October.

If the site runs behind a CDN or proxy, ask whether it uses mutual TLS or custom origin certificates. Cloudflare says customers with those settings, or with Full (strict) or Strict mode, should review them, and that it is updating Automatic SSL/TLS to notify customers still using distrusted certificates.

Ask for a test through the real connection path. Cloudflare notes that a browser or curl test may not reflect other verifiers. It also warns that certificate errors should not be resolved by disabling verification.

What Is Still Unclear

According to The Hacker News, eMudhra says a flaw in its April 2025 key ceremony produced the weak keys. It also says its infrastructure was not compromised, no data was breached, and only one of the eight intermediates was deployed in production. None had issued end-entity certificates, it says.

The same account puts the global TLS business at about 1% of revenue, separates its Indian digital signature and eSign businesses, and says it is issuing replacement certificates to affected customers. Root-cause work is ongoing.

Google says no other keys in its root stores share the weak-randomness problem, that it is coordinating with other vendors, and that Certificate Transparency logs have been updated to reject certificates chaining to the compromised authorities.

No source reviewed here says whether anyone exploited the flaw. The Hacker News notes that no source offers a way to detect past misuse beyond a search of Chrome’s Certificate Transparency data.