Sixteen intermediate certificate authority (CA) certificates are now affected after eMudhra revoked eight more on November 7, concluding an internal investigation that found improper handling of private keys during a custom certificate-generation process.
The immediate revocations and the scale of impact
eMudhra’s new incident report states the latest revocations raise the total of affected intermediate CA certificates to 16. The company previously acknowledged eight intermediate CA certificates whose private keys were so weak that "anyone could recover them almost instantly." The eight certificates revoked on November 7 were RSA intermediate CAs, including certificates used to issue TLS and code-signing certificates. eMudhra says affected customer certificates have been replaced or migrated.
How a custom Python script broke key protections
eMudhra traced both sets of affected certificates to a custom Python script used in April 2025 to transfer private keys between hardware security modules (HSMs). The company developed the script to move CA keys between different HSM vendors at its facilities after delays in obtaining new hardware. The report explains that HSMs "are devices designed to securely generate and store cryptographic keys, preventing sensitive private keys from being exposed outside the hardware."
According to eMudhra, the script contained a bug that reduced eight ECDSA private keys to a single byte, making them extremely easy to recover. The same script also processed eight RSA private keys, but those RSA keys were handled in the memory of the host computer running the script rather than remaining protected inside the HSM. While the RSA keys were not weakened like the ECDSA keys, eMudhra said it "could not demonstrate that it handled them under its certificate security policies." The report quotes the company: "A re‑import performed from host process memory is not consistent with the CPS §6.2.6 and the RSA objects are therefore treated as not meeting that requirement."
This site is the portfolio.
OSINTSights runs on Cloudflare Workers, D1, R2, and Vectorize, with an AI pipeline on Hetzner ARM. Nubivance designed, built, and operates it. We do the same for clients.
See what we buildAn early warning that went uninvestigated
eMudhra’s investigation found a missed signal dating back to June 2025. At that time, the company detected certificate revocation lists (CRLs) that were signed with private keys not matching the corresponding CA certificates. The company corrected the immediate symptom by signing the revocation lists with the correct keys but did not investigate why the mismatch had occurred. The new report confirms that this was an early warning sign of the faulty key-generation process that remained undetected until a security researcher discovered the weakness in October 2026.
Vendor and platform responses: blocking and updates
The compromised certificates were trusted by major browsers and operating systems, creating the risk that attackers could forge certificates for legitimate websites or intercept encrypted communications. As reported earlier, a security researcher known as "Wayne" disclosed on October 17 that eight eMudhra intermediate CA private keys could be recovered by testing just 256 possible values. Mozilla, Google, Apple and other software vendors released protections to block the compromised certificates. Microsoft issued out‑of‑band Windows updates on October 26 to remove trust in affected eMudhra certificate trust chains on systems that could not receive automatic certificate trust updates.
Company response: exit plan, customer migration, and external review
Following the incident, eMudhra announced it will exit the publicly trusted TLS certificate business and transition remaining customers to another provider. The company said it plans to stop issuing certificates under its remaining G1 hierarchy by November 16. eMudhra has commissioned an independent review by KPMG, with findings expected by December 4, to identify improvements to its certificate management and key-generation procedures. The company also says it has not detected any evidence that the compromised keys were used maliciously.
What this means for customers, security teams, and platform vendors
- Customers and enterprises that relied on eMudhra-issued TLS or code-signing certificates should have received migrated or replaced certificates; eMudhra stated affected customer certificates "have also been replaced or migrated."
- Security teams must treat re-imports from host memory as non‑compliant with the company's CPS §6.2.6, per eMudhra’s own assessment, and verify key handling and provenance during any HSM migration activity.
- Platform vendors and browser maintainers who blocked the compromised chains will continue to monitor whether any other trust paths were affected; Microsoft, Mozilla, Google and Apple already deployed protections and Microsoft additionally pushed Windows updates for systems without automatic trust updates.
The record from eMudhra’s report ends with two concrete milestones: the company will halt issuance under its G1 hierarchy on November 16, and KPMG’s independent review is due December 4. Those dates frame the short-term audit and remediation window; the central unanswered operational question is whether the independent review will identify procedural controls that would have flagged the April 2025 transfer error earlier, preventing the year‑long period in which signs—already visible in June 2025—went unexplored.
