eMudhra has published its full incident report explaining how a single flawed Python script, run during a routine key-transfer step in April 2025, ended up producing cryptographically weak private keys for eight of its certificate authority (CA) certificates — and, it turns out, created a separate compliance problem for eight more. The filing, posted on Mozilla’s public bug tracker, is the most detailed account yet of what went wrong inside India’s largest certificate authority, and it ends with eMudhra deciding to exit the public TLS certificate business altogether.
A quick recap, for anyone just catching up
eMudhra is a Bengaluru-headquartered, NSE-listed company that is one of the relatively small number of certificate authorities trusted by default by every major browser and operating system. In October, a security researcher discovered that the private keys behind eight of eMudhra’s intermediate certificates were so weak they could be reconstructed almost instantly — the cryptographic equivalent of a bank vault whose 15-digit code turned out to have only two real digits, with the rest fixed at zero, a detail that had social media convinced eMudhra had simply mixed up a 256-bit key with a number between 0 and 256. Mozilla, Google, Apple and Microsoft all moved to revoke trust in the affected certificates within days, two of them went further and pulled an entire eMudhra root certificate, and the company’s listed stock hit its lower circuit and kept falling, wiping out roughly ₹1,450 crore in market value within two days as the news spread.
A plain-language breakdown of what a certificate authority actually does and why a compromised intermediate key matters so much covered the mechanics of the original flaw. What wasn’t known until now is exactly how the keys ended up that weak — and that a second set of certificates, using an entirely different kind of cryptography, was also caught up in the same incident for a different reason.
What eMudhra says actually happened
According to the report, the trouble began on April 30, 2025, during what’s called a “key-generation ceremony” — a formal, witnessed process in which a CA creates the cryptographic key pairs behind its certificates inside a Hardware Security Module (HSM), a tamper-resistant device specifically built so that a private key, once generated inside it, is never supposed to leave in readable form.
That day, eMudhra generated 16 new subordinate CA key pairs: eight using ECDSA (a type of elliptic-curve cryptography) and eight using RSA, a different, older cryptographic method. The keys were meant to eventually operate out of new US and EU data centres, but the hardware ordered for those facilities had been delayed by supply-chain issues, and a root-program policy deadline later in 2025 meant the keys had to be created immediately rather than waiting. eMudhra’s plan was to generate the keys on hardware it already had, then transfer them later to the new facility’s hardware, made by a different manufacturer.
Moving a private key between HSMs from two different vendors isn’t as simple as copying a file — by design, the key is supposed to stay encrypted (“wrapped”) at every step outside the secure hardware. To do this safely, eMudhra’s engineering team wrote a custom Python script to export the keys from the original device as encrypted blobs, ready to be imported into the new hardware later. It’s this wrap-and-unwrap script, used for the first and only time in eMudhra’s history for this purpose, where the mistake happened.
The ECDSA keys: a truncation bug
For the eight ECDSA keys, eMudhra says a single line of faulty code in the script’s “read-back” step — where it reads the key’s value out of the module to recreate a key object — accidentally chopped the private key down to just its first byte. A proper ECDSA private key here should be an enormous random number; what came out the other end of the buggy script was effectively a number somewhere between 0 and 256, small enough for a basic computer program to guess in well under a second. That truncated, far weaker key — not the original, correctly generated one — is what eMudhra unknowingly used to issue its certificates.
The RSA keys: a different, quieter problem
The eight RSA keys weren’t broken in the same mathematical sense — eMudhra says their signatures still check out fine, meaning the actual key values weren’t corrupted. But the same script handled the sensitive components of those RSA keys (the kind of raw values that must never leave a secure device) inside the ordinary, unprotected memory of a regular computer during the same export process. Because of how that memory works, eMudhra says it can no longer prove those values weren’t exposed at some point, which fails a specific compliance requirement for how private keys must be handled. There’s no evidence these particular keys were ever actually stolen or misused — but eMudhra couldn’t rule it out either, so it revoked them as a precaution.
Why nobody caught it for 18 months
Two further gaps let the problem slide for a year and a half. First, eMudhra’s ceremony process had no step that tested whether a newly certified CA key was actually strong, or confirmed it matched the key that was originally generated — a basic check that would have caught the truncated ECDSA keys immediately. Second, the original, correctly generated key objects and the faulty recreated ones ended up with nearly identical internal labels, making it easy for staff to pick the wrong one when the certificates were issued.
There was even an early warning sign: in mid-2025, eMudhra noticed that some certificate revocation lists (CRLs) for these same certificates were failing to verify, because they’d been signed with the original keys while the certificates themselves had been issued using the mismatched, recreated ones. At the time, the team simply re-signed the lists with the matching key and moved on, without digging into why two different key objects existed in the first place — a missed chance to catch the problem roughly 18 months before an outside researcher eventually found it.
The fallout: eMudhra is leaving the TLS certificate business
Perhaps the most significant line in the report isn’t about the bug at all — it’s eMudhra’s decision to exit the public TLS certificate business entirely. The company says it will transition its remaining certificate customers, primarily a university network in North America, to another publicly trusted provider, with a hard deadline of November 16, 2026 for all remaining certificate issuance to stop.
eMudhra says there is no known case of any of the affected keys being misused to forge a fraudulent certificate, and that the underlying hardware security modules themselves worked exactly as designed throughout — the fault, in its telling, was entirely in the custom script written around them, not the secure hardware itself. The company’s stock is still down nearly 40% from before the vulnerability was exposed.
The bigger picture
The incident is a reminder of something easy to lose sight of in day-to-day conversations about AI and software: the internet’s basic security still runs on a small number of specialized companies getting extremely precise, unglamorous cryptographic procedures right every single time, with very little room for a one-off script error. It’s also a case study in how a single exception made for an understandable, practical reason — hardware delayed, a deadline looming — can be the exact moment a process breaks down.