eMudhra intermediate certificates with weak private keys enable certificate forgery

What happened and what to do

According to Cisco Talos, eight intermediate certificates from the eMudhra authority were issued with private keys that should have 384 bits of randomness but instead matched numbers of one or two digits. The cause was a key generation ceremony on 30 April 2025 under emSign Root TLS CA - G3 and the cross-signed Comodo AAA Certificate Services certificate, in which a fault created a second set of weak P-384 keys, mistakenly used in eight certificates. Six TLS certificates were blocked by Chrome, Mozilla and Apple, and two code-signing certificates used by Microsoft were also blocked. eMudhra revoked the certificates and stopped issuing under the G3 root. Talos expects additional patches from several technologies.

For a company, the case calls for action on three fronts. First, inventory: list which intermediate certificates and trust roots your infrastructure accepts, including clients, agents, build pipelines and package repositories, comparing against the SHA-256 fingerprints in the advisory. Second, monitoring: collect and alert on revocations, trust store changes and software updates, with dashboards showing exposure per system. Third, response: automate rotation of internal certificates and validation of code signatures, with audit trails. This is done with collection and alerting pipelines on the client's own infrastructure.

How the consultancy can help

Diagnosis of exposure to eMudhra and other intermediate CA certificates, with an inventory of trust chains across servers, devices and signing pipelines. Then implementation of revocation monitoring and alerts, and automation of rotation and validation, operated on the client's infrastructure.

Next step

Send a short description of your infrastructure and how your company uses TLS and code-signing certificates. Wendelmaques will then prepare a scoped proposal for the diagnosis and implementation.