eMudhra revokes eight more CAs after script error exposed RSA keys

Certificate authority eMudhra has revoked eight additional intermediate certificate authorities (CAs) after determining that a custom Python script used during a key ceremony exposed their RSA private keys. The company initially stated these CAs were unaffected by the October compromise but reversed its position in early November following further investigation and discussions with browser root programs.

What happened

The incident traces back to a key ceremony on April 30, 2025, where eMudhra generated 16 CA keys on Utimaco hardware security modules (HSMs). These keys were intended for transfer to Crypto4A HSMs at the company’s US and EU sites. Because moving keys between different vendor HSMs is restricted, the PKI operations team wrote a Python script to wrap and unwrap the keys for transport. During a practice run of this transfer, the script read private keys out of the HSM into the ceremony computer’s memory to rebuild them.

For eight ECDSA keys, a single line in the script truncated the private value to its leading byte, creating critically weak keys that were subsequently certified. While those eight were revoked in October, the company initially believed eight RSA keys processed through the same script were safe because the script did not truncate them. However, the investigation revealed that the private components of these RSA keys, such as the private exponent and primes, remained in the memory of the Python process on the ceremony computer.

This exposure meant eMudhra could not prove compliance with its own Certification Practice Statement (CPS) regarding key handling. The company stated it "cannot positively demonstrate that this key material was in compliance" with rules governing how keys move in and out of HSMs. Consequently, the eight RSA CAs were revoked late last week. Six were for TLS website certificates and two for code signing, covering 195 issued certificates, including 29 for eMudhra’s own domains.

Key details

• Eight intermediate CAs were revoked due to RSA key exposure in memory, not key truncation.
• The fault originated from a Python script used during a key ceremony on April 30, 2025.
• 195 certificates were affected, including those for universities, a county, and eMudhra itself.
• The company initially claimed these CAs were unaffected in an October 19 update to Mozilla.
• Revocation reason was listed as cessationOfOperation rather than keyCompromise.
• Microsoft will remove remaining eMudhra roots from Windows and Edge starting November 16.

Background

Hardware Security Modules (HSMs) are physical devices designed to generate and store cryptographic keys securely. A core principle of HSM usage is that private keys should never leave the device in plaintext. When organizations need to migrate keys between different HSM vendors, they often use wrapping processes that encrypt the key for transport. In this case, eMudhra’s custom script bypassed standard safeguards by reading the key into system memory for reconstruction, creating a window where the secret material was vulnerable to extraction or logging.

Certificate Authorities operate under strict audits like WebTrust and must follow a Certification Practice Statement (CPS). If a CA cannot prove that a private key was handled according to these rules, browsers and operating systems may revoke trust in that CA. This ensures that if a key is potentially compromised, even without proof of misuse, the risk is mitigated by invalidating the trust chain.

Why it matters

For teams running self-hosted software, this incident highlights the fragility of trust in the public certificate ecosystem. If you rely on certificates from eMudhra’s emSign brand, your services may soon face trust errors in browsers and operating systems. Microsoft is removing the remaining eMudhra roots on November 16, and Apple will end trust in all G1 certificates by November 30. This means internal tools, APIs, or customer-facing apps using these certificates will break unless migrated.

Beyond immediate breakage, this story serves as a cautionary tale about custom scripting in critical security infrastructure. Even large, audited organizations can introduce severe vulnerabilities through simple coding errors. For DevOps and IT leads, it underscores the importance of verifying the provenance and handling of cryptographic materials, especially when using third-party CAs that may be exiting the market or facing stability issues.

What you can do

• Check if your services use certificates issued by eMudhra’s G1 or G2C hierarchies via Certificate Transparency logs.
• Replace any affected certificates immediately with ones from a stable, trusted provider.
• Update macOS systems to versions 27.2.1, 26.7.3, or 15.8.3 to ensure bundled tools like curl reject compromised roots.
• Monitor your application logs for TLS handshake failures that may indicate trust issues with older certificates.
• Review your own key management procedures to ensure no custom scripts expose private keys in memory.
• Verify that your monitoring stack alerts you to certificate expiration or revocation status changes.