On October 26 we reported that the private keys of eight eMudhra intermediate certificates could be computed directly. In the two weeks since, several developments have mattered for site owners: Chrome removed emSign ECC Root CA - G3 from its root store on October 27 and on November 4 announced limits on another root, emSign Root CA - G1; Cloudflare published what it saw of exploitation and patching on October 30; Debian removed three eMudhra roots from NSS on October 31; and Ubuntu found on November 5 that removals from the system store had never reached Java keystores.
What Cloudflare Saw
- How weak were the eight keys? In Cloudflare's analogy, each should have been a 115-digit number; one was actually 4, and the rest were 56, 66, 115, 155, 156, 230 and 237. Anyone can compute them from the public certificates and issue certificates for any domain, which unpatched clients that don't enforce Certificate Transparency will accept.
- Cloudflare added logging to its outbound connections (fully rolled out October 21) and saw about 22,000 TLS handshakes using the weak keys in a week. Two-thirds were fetches of test sites, and almost all the rest went to origins that appeared to have issued certificates for themselves with the weak intermediates. About 160 handshakes carried certificates naming other organisations' domains, some related to consumer IoT devices; one forged certificate was dated October 20 at 18:19 UTC, less than an hour after Mozilla's bug report became public. Cloudflare says it has no evidence so far of these keys being used to intercept its connections.
- Patching looks grim: across some 50 million probes, up-to-date modern browsers were mostly patched, but bots and old browsers were not; embedded browsers such as Android WebView still accepted the compromised chain 30–40% of the time, and across large networks more than half of probes still accepted it, with little movement after the first weekend.
What Browsers and Distributions Did Next
- Chrome: to protect users of the Chrome Root Store that don't consume CRLSet updates, Google removed emSign ECC Root CA - G3, the root that signed the compromised intermediates, from the root store, with the change expected to reach all devices on the morning of October 27 (Pacific). Google says websites with certificates chaining to G3 must immediately obtain and install new ones.
- Chrome's November 4 update: TLS server certificates chaining to emSign Root CA - G1 whose earliest Signed Certificate Timestamp (SCT) is after November 16, 2026 at 23:59:59 UTC will no longer be trusted by default in Chrome 153 and higher; certificates issued before then are unaffected.
- Java: Ubuntu's USN-9001-1 says the ca-certificates Java integration had not been working, so CAs removed from the system bundle were not removed from the JKS keystore, meaning Java applications may still trust eMudhra. Fixed versions: ca-certificates
20260816ubuntu0.22.04.2plus ca-certificates-java20190909ubuntu1.4on 22.04,20260816ubuntu0.24.04.2plus20240118ubuntu0.24.04.1on 24.04, and20260816ubuntu0.26.04.2plus20260311ubuntu0.26.04.1on 26.04. Restart Java services such as Tomcat, Jenkins or Elasticsearch afterwards for it to take effect. - NSS: Debian's DSA-6599-1 removes three roots from nss, "eMudhra emSign Root CA - G3", "eMudhra emSign Root CA - C1" and "emSign ECC Root CA - C3"; the fixed version on Debian 13 is
2:3.110-1+deb13u5. Programs that verify certificates with NSS (such as Firefox and Thunderbird) depend on this package.
Don't Forget Programs With Their Own Certificate Bundles
Many programs don't read the system store and ship their own: WordPress 7.1.4 on October 28 updated its bundled roots (see this report), and Python's certifi and Go programs were covered in our report 85. Cloudflare's advice still stands: test after you update, and never "fix" resulting errors by disabling certificate verification. For why Certificate Transparency monitoring matters, see our report on the hijacked registries; to issue and renew certificates for your own site, see setting up Let's Encrypt SSL.