The eMudhra certificate incident is not a story about hackers breaking in. It is a story about a certificate authority that published eight signing certificates whose private keys were so weak that anyone could work them out in under a second. One of them was simply the number 4. Browsers blocked the certificates within hours to days of the report, but the weak keys had been sitting in public view for about 18 months before anyone noticed, and some software outside browsers may still trust them.
What a certificate authority does
When you open a website over HTTPS, your browser checks a digital certificate that proves the site is who it says it is. Those certificates are signed by certificate authorities (CAs), companies that browsers and operating systems trust by default. Large CAs usually sign through “intermediate” certificates that chain up to a trusted root. Whoever holds the private key of a trusted intermediate can issue a valid-looking certificate for any domain.
eMudhra is an Indian CA that says it has issued more than 60 million digital certificates, according to Help Net Security. Its roots, sold under the emSign brand, are trusted by the major browsers.
How eight keys became guessable
The affected certificates used elliptic-curve cryptography on the P-384 curve. In that system, the private key is just a very large random number, normally more than a hundred digits long, and the public key, which is printed in the certificate for everyone to see, is derived from it. The math is safe only because there are far too many possible private keys to try.
For these eight intermediates, the private keys were all below 256. Reported values were 4, 56, 66, 115, 155, 156, 230 and 237, according to Tech Insider. Anyone could recover a key by testing at most 256 numbers against the public key. Security researcher Scott Helme recovered them in under a second, Help Net Security reported. Heise showed what that means in practice by publishing a demonstration certificate for a Google subdomain that chained to eMudhra.
The certificates came from a batch of 24 intermediates eMudhra generated on April 30, 2025. Six of the eight weak ones could sign website certificates and two could sign software. Sectigo, another CA, cross-signed all eight in May 2025, Help Net Security reported. The flaw was found on October 17, 2026, by a researcher checking the public Common CA Database (CCADB), where CAs must disclose their certificates.
eMudhra’s explanation
eMudhra says no one stole anything. The company attributes the problem to a flaw in its key-generation ceremony: a “wrap and unwrap” step created a second set of weak keys alongside the properly generated strong ones, and the weak ones ended up in the certificates, according to Tech Insider. eMudhra says only one of the intermediates was put into production, none issued certificates to customers, and its physical and logical security controls “remained intact.”
Chairman V. Srinivasan said the certificates were revoked within 14 hours of discovery and no data was breached. The company’s board said the incident drew scrutiny “out of proportion to SSL/TLS’s place in our business,” and on October 22 eMudhra announced it would leave the global SSL/TLS certificate business, Help Net Security reported. About 30,000 customer certificates need to be replaced.
Browsers moved fast. Everything else is slower
Mozilla received the report at 20:06 UTC on October 17 and pushed the block to Firefox users through OneCRL, its central revocation list, by 22:59 UTC the same day, according to the Mozilla Security Blog. It also removed the eMudhra root from its NSS trust store, which other software copies. Chrome blocked the certificates the same day, Apple followed on October 19 and Microsoft on October 20, Help Net Security reported. Google plans to stop trusting the root in Chrome as well.
The weak spot is software that does not get those fast updates. Cloudflare, which patched its WARP and Zero Trust clients and its servers by October 20, warned that apps, SDKs and devices often bundle their own list of trusted roots or rely on an operating system that updates slowly. A browser or curl test that passes does not prove a background service is protected, the company wrote. “It’s important to not resolve these errors by disabling verification,” it added. Heise reported that Go, Python’s certifi package and NetBSD issued advisories, and that Linux administrators may need to remove the roots manually until updated packages arrive.
How big is the risk for ordinary users? Probably small. To abuse a forged certificate, an attacker also has to sit between the victim and the site, for example on public Wi-Fi or by hijacking DNS, heise noted. No attacks using the keys have been reported. A public test page shows whether a browser or tool still trusts the affected certificates.
Our take
The system worked, but late. Public disclosure rules, such as listing every CA certificate in the CCADB, are why a single researcher could spot the problem at all, and browser vendors showed they can cut off a bad CA within hours. Yet these keys passed a key ceremony, a cross-signing by another CA and about 18 months in a public database without anyone running a check that takes a fraction of a second. Simple automated tests on every newly disclosed CA certificate should become standard. The episode also matters for the much bigger job ahead, replacing today’s cryptography before quantum computers can break it, which we covered in our piece on Q-Day deadlines. If a CA can get a 384-bit key down to the number 4, the industry’s ability to swap keys safely at scale deserves more scrutiny.