Browsers Block Eight eMudhra Certificates After Private Keys Proven Compromised
Major browser vendors and root trust stores have revoked eight intermediate certificates from eMudhra after researchers demonstrated that weak entropy allowed trivial recovery of the associated private keys.
Key points
- Google, Mozilla, Apple, and Microsoft blocked the compromised eMudhra intermediate certificates between October 17 and October 20.
- The private keys were generated with insufficient randomness, allowing near-instant recovery via discrete log algorithms.
- No evidence of malicious use has appeared in Certificate Transparency logs, but clients not enforcing CT may remain at risk.
Major technology companies have blocked eight intermediate certificates issued by Indian certificate authority eMudhra after the private keys associated with them were compromised. Root programs and global trust stores have initiated blocking measures to prevent attackers from using these keys to forge trusted HTTPS certificates and impersonate any website.
According to SecurityWeek, the certificates were issued in April 2025. Google and Mozilla took action on October 17, followed by Apple on October 19 and Microsoft on October 20. Sectigo also took revocation steps, while Cloudflare patched its services. eMudhra revoked the specific certificates and communicated the issue to downstream trust stores.
Technical Cause of Weak Keys
Google explained that the private keys were generated with insufficient randomness, resulting in weak cryptographic entropy. This flaw enabled anyone to forge trusted certificates against clients that have not yet removed trust in those specific certificate authorities. Mozilla engineer Dennis Jackson published a tool to help administrators check if their clients still trust the compromised certificates.
Jackson noted that the private keys were incorrectly generated and could be retrieved directly from the certificates themselves. He warned that several individuals have independently recovered the keys because the process is fast and easy. The keys are effectively all-zeros except for the last byte, allowing recovery near instantly via the baby-step giant-step discrete log algorithm.
Context and Background
eMudhra stated that a flaw in the script used during the key generation ceremony created a second, weaker key pair. This weaker pair was mistakenly used to create certificate signing requests because its labels were similar to those of the original, secure keys. The company clarified that these issuers were intended for export to US and European data centers to address data sovereignty issues for certain customers.
According to eMudhra, these certificates never ended up operationally in production except for one instance. This incident follows earlier reporting by Threat Times on October 21, 2026, which noted that major browsers blocked eight eMudhra intermediates after researchers proved weak entropy allowed trivial key recovery and potential impersonation.
Who Is Affected
Although the certificates have been blocked and revoked, some clients may require software updates to ensure the compromised intermediates are no longer trusted. There appears to be no evidence in Certificate Transparency logs that the keys were used maliciously before revocation. However, not all clients enforce Certificate Transparency logging, meaning threat actors may have used them to impersonate services to those specific clients.
What should you do?
Organizations should verify whether their internal systems still trust the eight compromised eMudhra intermediate certificates. Administrators can use the tool published by Mozilla’s Dennis Jackson to check for this specific trust relationship. Until all clients are updated or configured to distrust these intermediates, the risk of impersonation remains for those users.
What to do and how to stay safe: eMudhra
- Use Mozilla’s diagnostic tool to check if your systems still trust the eight compromised eMudhra intermediate certificates.
- Monitor Certificate Transparency logs for any unusual signing activity related to these specific intermediates, though not all clients enforce CT.
- Plan for software updates that explicitly remove trust in these specific compromised keys, as automatic revocation may not reach all legacy clients.
- Review internal certificate pinning configurations to ensure they do not inadvertently rely on these revoked intermediates for validation.
Step-by-step guide: Social Engineering Warning Signs and How to Respond
General security guidance from the Threat Times newsroom. It is not confirmed advice from the organisations named in this story.
Frequently asked questions
Did eMudhra confirm the private keys were exposed?
Yes, eMudhra confirmed a script flaw during key generation created a weaker key pair that was mistakenly used for certificate signing requests.
Are there signs the keys were used for attacks?
No evidence of malicious use has been found in Certificate Transparency logs, but clients not enforcing CT may still be vulnerable to impersonation.
When did browsers block these certificates?
Google and Mozilla blocked them on October 17, Apple on October 19, and Microsoft on October 20, according to SecurityWeek.
