eMudhra Revokes 16 Certificate Authorities After Private Keys Pulled From HSM Memory
Indian digital‑identity provider eMudhra has now revoked 16 of its certificate authorities after discovering that a Python script could extract RSA private keys from hardware security modules into process memory, undermining confidence in every certificate tied to those authorities.
Indian digital‑signature firm eMudhra has expanded the fallout from a key‑handling flaw, revoking a total of 16 certificate authorities (CAs) after admitting that private keys were not kept fully inside secure hardware as expected.
According to a disclosure highlighted on 11 November, eMudhra revoked eight more CAs it had previously believed were unaffected, on top of earlier revocations. A Python script used within the company was able to retrieve RSA private key material from hardware security modules (HSMs) into process memory. Once keys reach standard memory, the company can no longer guarantee they were never copied or exposed.
Global browsers and operating systems rely on a limited set of trusted CAs to vouch for the identity of websites, software, and sometimes individuals. If a CA’s private key may have leaked from its HSM, every certificate issued under that authority comes into question. In this case, any server certificates, code‑signing keys, or digital‑identity documents chained to the affected eMudhra CAs will need replacement, and users of those certificates must be ready for browsers and systems to stop trusting them once updates land.
For end users, the problem is likely to appear as new warnings when visiting sites or installing software that previously validated without errors. Behind those alerts, administrators in banks, companies, and government offices that depend on eMudhra for secure communication and signatures now have to generate and deploy fresh certificates on a tight timeline.
The technical flaw doesn’t lie in the underlying cryptography but in how the HSMs were used. These devices are designed so that private keys stay inside the hardware, with signing operations carried out internally. The fact that a script could pull keys into application memory points to misconfiguration, misuse of interfaces, or integration errors. Once that boundary is broken, there’s no reliable way to reconstruct where the keys went or who might have had access to them.
Because CAs sit at the root of online trust, even the possibility of key exposure is treated as serious. A hostile party with access to a CA’s private key can forge certificates that make malicious sites or software look legitimate, opening the door to interception of encrypted traffic or poisoned updates.
Security teams and regulators will now track how quickly browser vendors and operating‑system developers push updates that distrust the affected eMudhra authorities, and whether any major public services report outages or trust failures linked to the revocations. Investigations may also look for signs that any of the exposed keys have already been abused, which would shift the incident from a theoretical risk to an active compromise.
Sources
- OSINT