eMudhra revokes eight more intermediate CA certificates after private key mishandling

eMudhra revokes additional intermediate certificates

Following a detailed investigation, Indian certificate authority eMudhra announced the revocation of eight more intermediate CA certificates. The action comes after the company identified improper handling of private keys during the certificate‑generation process.

Background of the earlier incident

In early June, eMudhra disclosed a breach that exposed private keys used to sign a batch of digital certificates. The initial response involved revoking the affected leaf certificates and conducting a forensic review of internal processes.

Discovery of the new revocations

During the forensic audit, auditors uncovered evidence that the private keys for eight intermediate certificates had been generated in a non‑isolated environment. Because an intermediate certificate can issue many leaf certificates, the risk to relying parties was deemed significant, prompting the latest revocation.

Technical cause – mishandling of private keys

eMudhra’s certificate‑generation workflow normally isolates private key creation in a hardware security module (HSM). In this case, the keys were generated on a shared server that lacked adequate access controls. The server logs later showed that several administrative accounts could view the key material.

Certificate generation workflow

The standard workflow includes the following steps:

1. Generate a key pair inside an HSM.
2. Create a certificate signing request (CSR).
3. Sign the CSR with the CA’s root key.
4. Publish the signed certificate to the public repository.

When the private key is created outside the HSM, the cryptographic boundary is broken, allowing the key to be copied or exposed.

Risks of private key exposure

A compromised intermediate key can be used to issue fraudulent certificates that appear legitimate to browsers and applications. Attackers could impersonate websites, intercept traffic, or sign malware binaries, undermining trust in the public key infrastructure.

Impact on customers and relying parties

Organizations that rely on the revoked intermediate certificates must verify whether any of their own certificates were issued by the affected intermediates. If so, those certificates may need to be replaced promptly.

Immediate steps taken by eMudhra

• Published a list of the eight revoked intermediate serial numbers.
• Updated certificate revocation lists (CRLs) and Online Certificate Status Protocol (OCSP) responders.
• Issued a security advisory to all customers with migration guidance.
• Engaged an independent security firm to audit the entire key‑management process.

Guidance for affected organizations

Security teams should perform the following actions:

1. Check the issuer field of all in‑use certificates against the published revocation list.
2. Replace any certificates that chain to the revoked intermediates.
3. Validate OCSP responses for critical services.
4. Review internal PKI policies to ensure strict isolation of private key operations.
5. Consider implementing certificate pinning for high‑value applications.

Industry response and regulatory perspective

The incident has reignited discussion about key‑management standards and the role of oversight bodies.

Role of the CA/Browser Forum

The CA/Browser Forum, which maintains the Baseline Requirements for publicly trusted certificates, has urged members to review compliance with Section 9.4.3, which mandates the use of secure hardware for private key generation. The forum’s latest meeting minutes reference the eMudhra case as a real‑world example of why the controls are essential.

Indian IT Ministry statements

The Ministry of Electronics and Information Technology released a brief note emphasizing the need for “robust cryptographic hygiene” among domestic CAs. The ministry directed the Indian Computer Emergency Response Team (CERT-In) to monitor compliance and share best practices with the industry.

Best practices to prevent similar incidents

Experts agree that a layered approach to key protection can dramatically reduce the likelihood of accidental exposure.

Secure key management

Adopting hardware security modules, using role‑based access control, and enforcing multi‑person approval for key generation are core elements. The NIST key management guidelines provide a comprehensive framework that many enterprises follow.

Auditing and monitoring

Continuous monitoring of key‑usage logs, combined with regular third‑party audits, helps detect anomalies before they lead to a breach. DigiCert’s private key management best practices highlight the value of automated alerting for privileged account activity.

By tightening operational controls, certificate authorities can protect the integrity of the PKI ecosystem and maintain confidence among users and businesses alike.