Summary
- Eight eMudhra intermediate authorities had weak private keys that could enable fraudulent certificate issuance.
- Mozilla and Google blocked affected certificates on 17 October, followed by further browser and trust-store updates.
- eMudhra attributes the problem to a 2025 key generation process and says its infrastructure was not breached.
Indian certificate authority eMudhra has identified a flaw in its certificate key generation process that produced weak private keys, explaining the incident that prompted Mozilla, Google and other technology providers to block parts of its certificate infrastructure.
In a statement issued on 21 October, the company said a process used during an April 2025 key generation ceremony created a second set of weak keys alongside the intended strong keys. The weak keys became associated with eight intermediate certificate authorities used in its international certificate business.
The weakness made private keys recoverable from information contained in their corresponding public certificates, rather than requiring an attacker to compromise eMudhra’s systems to obtain them.
Private keys associated with certificate authorities can be used to sign certificates that other systems may recognise as trustworthy. If a private key is exposed or can be calculated, an attacker may be able to issue fraudulent certificates for websites or services that the authority was permitted to certify.
That capability does not establish that fraudulent certificates were used in an attack. As of 21 October, public disclosures had not confirmed malicious exploitation of the affected keys.
Flawed key generation undermined certificate security
The affected intermediate authorities were created during a key generation ceremony conducted on 30 April 2025.
According to eMudhra, the ceremony used hardware security modules meeting FIPS 140-2 Level 3 requirements. A flaw involving a key wrapping and unwrapping operation resulted in a second set of weak keys being produced.
Those keys did not provide the unpredictability expected from properly generated elliptic-curve cryptographic private keys.
India’s national computer emergency response team, CERT-In, said the affected P-384 private-key values were smaller than 256, making them recoverable almost immediately from their corresponding public keys.
The problem did not establish a weakness in the P-384 cryptographic algorithm. It arose from the way the particular keys were generated and handled during the certificate creation process.
The distinction changes the investigation. A stolen private key would prompt questions about unauthorised access to signing infrastructure, whereas a weak key generated through a defective process may be recoverable without any intrusion.
eMudhra says its physical and logical security infrastructure was not compromised and that no customer data breach resulted from the incident.
The company is investigating the generation process and reviewing the controls intended to verify the integrity and strength of cryptographic material.
Browser operators blocked the affected trust paths
Google’s Chrome Root Program received a researcher’s report on 17 October at 18:05 UTC. After corroborating the findings, Google distributed a CRLSet update blocking the affected TLS certificate public keys by 19:45 UTC.
Mozilla received its report later that day, at 20:06 UTC, and responded using OneCRL, its centrally maintained certificate blocking mechanism.
Mozilla completed distribution of the OneCRL update to Firefox users with standard configurations by 22:59 UTC, less than three hours after receiving the report.
Those systems allowed the affected certificate authorities to be rejected without waiting for every user to download and restart a full browser update.
Mozilla subsequently released Firefox 158.0.1 for desktop and Android, alongside Firefox ESR 115.43.1 and 153.5.1. These releases extended protection to installations whose custom configurations might have prevented delivery of the earlier OneCRL update.
The organisation also updated its Network Security Services certificate database through NSS 3.131.1, removing trust in the root certificate that signed the affected intermediates.
This additional measure is relevant to applications using Mozilla’s trust infrastructure without receiving Firefox’s browser-specific revocation information.
Chrome, operating systems and other applications can apply certificate distrust through different mechanisms. Updating a browser therefore does not necessarily establish that every software component on the same device rejects an affected certificate chain.
Production history limits known use, not the underlying risk
eMudhra says the incident is confined to the eight identified intermediate authorities and does not affect its root authority private keys or other intermediate certificates.
It states that only one of the affected intermediates was deployed in production and that none of them issued end-entity certificates, including the one that entered production use.
According to the company, its findings are supported by internal analysis and public certificate transparency records.
Google separately reported that no TLS certificates chaining to the affected TLS intermediates had appeared in Certificate Transparency logs before its blocking action.
That evidence limits the known history of legitimate certificate issuance but does not eliminate the reason for distrusting weak signing keys.
An attacker holding a recoverable intermediate private key could attempt to create a fraudulent certificate outside the issuer’s ordinary processes. Whether that certificate would be accepted depends on the client’s trust configuration and additional certificate validation requirements.
Browsers enforcing certificate transparency and emergency distrust rules provide protections that may not be present in older applications, embedded devices or software using separately maintained trust stores.
CERT-In has warned that the incident could affect website identity verification and other uses of certificate trust, while distinguishing the potential consequences from confirmed malicious activity.
Separate Indian digital signature services remain unaffected
eMudhra says its domestic Digital Signature Certificate and eSign services operate on separate infrastructure and are unaffected by the issue involving its international certificate business.
That separation is also reflected in CERT-In’s advisory, which distinguishes the global browser trust system from India’s separately regulated digital signature arrangements.
The company has revoked the affected intermediates and is reviewing its security and operational procedures with browser and root-store operators.
It has also clarified that previously planned removal of its C1 and C3 root authorities from Mozilla’s trust programme is unrelated to the current incident.
The investigation into the key generation failure remains open. Browser and certificate library updates have reduced exposure to the affected trust paths, while applications using independent certificate stores may still require assessment against the vendor corrections issued since 17 October.
