At 20:06 UTC on October 17, Mozilla received a report, forwarded by the Chrome Root Program, that the private keys of 8 intermediate certificates belonging to the Indian certificate authority eMudhra had been compromised; it included proof of control of all 8 keys. At 21:48, Mozilla recovered the keys itself without knowing the reporter's method — according to Mozilla's explanation in the incident (Bugzilla 2083449), all 8 P-384 private keys were integers less than 256, effectively all zeroes, and can be recovered almost instantly. 6 of the 8 are TLS intermediates trusted by the Chrome, Mozilla, Microsoft and Apple root programs; the other 2 are for code signing and trusted by Microsoft. The keys came from a key ceremony held on April 30, 2025.

Timeline

  • October 17: Firefox finished distrusting the certificates through OneCRL at 22:59 UTC.
  • October 18: at 09:38 UTC eMudhra revoked the 8 certificates (reason caCompromise). eMudhra says no end-entity certificates were issued from them, but since anyone can compute the keys, anyone can use them to forge a certificate for any domain.
  • October 20: Mozilla announced the emergency removal of trust in the root emSign ECC Root CA - G3, to protect clients that don't use revocation information or have no way to withdraw trust in specific intermediates; the Chrome Root Program committed to a similar path the same day. eMudhra stopped issuance from every intermediate under that root and estimated that about 30,000 certificates need to be migrated, about 97% of them issued through ACME.
  • October 22: eMudhra announced that its board had decided to voluntarily withdraw from the global SSL/TLS certificate business.

Why Servers Need Their Own Fix

Browsers have fast revocation mechanisms and could block this with the flip of a switch. Programs on your server are different: when curl, wget, Python, PHP, Node, Java or Go make HTTPS requests, they mostly rely on the system trust store or a bundled certificate list, and a browser update does nothing for them. Cloudflare's October 20 write-up specifically warns that updating an SDK may not change the underlying verification policy — it depends on which trust store is used in the end — and that if you see certificate errors after patching, you must not make them go away by disabling verification.

What to Do on a VPS

  • Ubuntu: USN-8944-1 on October 20 removed emSign ECC Root CA - G3 from ca-certificates — 20260816ubuntu0.22.04.1 for 22.04 and 20260816ubuntu0.24.04.1 for 24.04; USN-8947-1 on October 21 also updated NSS, removing that root and "Comodo AAA Services root".
  • Debian: DSA-6572-1 removes the same two roots, 20250419+deb13u1 for Debian 13; for Debian 12 it is DLA-4845-1, 20250419~deb12u2.
  • After updating, ls /etc/ssl/certs | grep -i emsign_ecc_root_ca_-_g3 should print nothing, which means the root is no longer in the system trust store.
  • Programs with their own certificate bundle need separate updates: Python's certifi no longer contains this root from version 2026.10.18 (we checked the bundled certificate file release by release). On Linux, Go programs use the system trust store by default, so updating ca-certificates covers most cases; to cover the narrower cases where the system store isn't updated, Go 1.26.10 / 1.27.3, released October 19, added a denylist to crypto/x509 (GO-2026-6809 / CVE-2026-111943), so rebuild Go programs you compile yourself with a new version. Docker images carry their own ca-certificates as well: rebuild the image and restart the container — see Docker on a VPS.
  • Restart the affected services afterwards; processes that are already running will not reload the trust store.

This doesn't directly affect most site owners' own certificates: if you use Let's Encrypt or another CA, there is nothing to replace — see setting up Let's Encrypt SSL for configuration. But it shows again that defending against forged certificates takes several layers; the CT monitoring and CAA records covered in our piece on the .gh, .sl and .as registry hijacks apply here too.