Certificate authorities have one core job: keep their private keys safe. eMudhra, a CA with roots in the Netherlands and India, has failed at that in spectacular fashion. Eight of its intermediate CA certificates, including their private keys, ended up in outside hands. Anyone holding them could issue a perfectly valid TLS certificate for any domain, and one researcher proved the point with a certificate for q3k.google.com. Browsers have already blocked the certificates. If you run servers, though, you may still have work to do.
Not stolen, just guessable
The incident was reported to Mozilla and Google on October 17. The affected certificates are intermediates, the middle layer between a root certificate and the end certificate a website presents. CAs use intermediates to separate product lines or validation methods, and because they chain up to a trusted root, browsers trust them just as much.
Early reports assumed the keys had been stolen. By Tuesday evening, researchers had found something worse. eMudhra had generated the keys so poorly that they could simply be guessed. With EC-384, the private key is a number that defines a point on an elliptic curve. Every one of the eight keys was a value between 0 and 255. That is 8 bits of security. One key was literally the number 4.
The CA/Browser Forum's Baseline Requirements exist precisely to prevent this kind of failure. eMudhra will have some uncomfortable questions to answer, and so will BDO, the firm that carried out the WebTrust audit required for inclusion in browser root stores. A key generation process this broken should not survive a serious audit.
Limited risk for everyday users
A forged certificate on its own does not get an attacker very far. To intercept your traffic, they also need to redirect it, which means controlling DNS resolution or IP routing for their target. The researcher's demo only worked when curl was pointed at a specific IP using --resolve. Still, for the trust model behind HTTPS, this is about as bad as it gets.
Browser vendors moved quickly. Mozilla added the certificates to its OneCRL revocation list roughly three hours after the report and removed the related roots from its trust store on October 20. Firefox, Chrome and Safari now show a clear warning on the demo site. You can check your own browser at emudhra.we-have-a-problem.com.
What admins should do now
Servers are a different story. Linux and BSD systems ship their own CA bundles, and until those are updated, curl, wget and your applications keep trusting the bad certificates. The issue is tracked as CVE-2026-111943, with advisories from Go, Python-certifi and NetBSD, among others.
- Debian and Ubuntu: update the
ca-certificatespackage. The new version drops trust in eMudhra entirely. - NetBSD: remove the two roots manually:
certctl untrust /usr/share/certs/mozilla/all/emSign_Root_CA_-_C1.pemcertctl untrust /usr/share/certs/mozilla/all/emSign_ECC_Root_CA_-_C3.pem- Python and Go: make sure
certifiand any embedded root stores are current.
To confirm the change worked, loop over the test hosts:
for i in dv-g3b-emudhra dv-g3c-emudhra ov-g3b-emudhra ov-g3c-emudhra ev-g3b-emudhra ev-g3c-emudhra dv-g3b-aaa-emudhra dv-g3c-aaa-emudhra ov-g3b-aaa-emudhra ov-g3c-aaa-emudhra ev-g3b-aaa-emudhra ev-g3c-aaa-emudhra; do echo -n "$i: "; curl https://$i.we-have-a-problem.com; doneIf you see "Your client successfully connected to the site. That's bad!" anywhere, your system still trusts eMudhra. Fix it and check again, and don't forget container images and CI runners that bring their own CA bundles.