The private keys associated with eight intermediate certificates issued by Indian certificate authority (CA) eMudhra have been compromised, and root programs and trust stores have started blocking them.
The certificates were issued in April 2025, and some of the compromised keys could allow attackers to generate fraudulent certificates and impersonate any website.
On October 17, Mozilla and Google blocked the certificates in Firefox and Chrome. Apple and Microsoft blocked them on October 19 and October 20, respectively. Sectigo took revocation steps too, and Cloudflare patched its services.
eMudhra revoked the compromised certificates, and the issue was communicated to downstream trust stores.
“The private keys for these certificates were generated with insufficient randomness (i.e., weak cryptographic entropy), enabling anyone to forge trusted HTTPS certificates to impersonate any website against clients that have not yet removed trust in those CAs,” Google explains.
Although the certificates have been blocked and revoked, some clients may require software updates to ensure that the compromised intermediates are no longer trusted.
Mozilla’s Dennis Jackson has published a tool to check whether clients still trust the compromised certificates. He also explains that the private keys were incorrectly generated and could be retrieved from the certificates.
In fact, Jackson warned that several individuals have independently retrieved the keys, as the process is fairly easy and fast.
“The private keys are effectively all-zeroes apart from the last byte. They can be recovered near instantly via the baby-step giant-step discrete log algorithm,” Jackson said.
There appears to be no evidence in Certificate Transparency (CT) logs that the keys were used maliciously before revocation, but not all clients enforce CT, and threat actors may have used them to impersonate those clients.
According to eMudhra, a flaw in the script used during the key generation ceremony created a second, weaker key pair, which was mistakenly used to create the certificate signing requests because its labels were similar to those of the original keys.
“Some additional context – these issuers created were meant for export to our US and European data centers to solve data sovereignty issues for some of our customers (but never ended up operationally in production except for one),” the CA said.
“There were human errors in multiple steps of the process that resulted in significant flaws in the key lifecycle integrity process for this KGC. We are now digging deeper for code flaws, process gaps, and maker/checker controls specific to this issue. Over the next week, we will reverify every key ceremony we have done,” eMudhra added.
Related: Let’s Encrypt Cuts Default Certificate Validity to 64 Days Ahead of 45-Day Switch
Related: PHP2Shell: Mass Exploitation Looms for Leaked Critical PHP Flaws
Related: AOMEI Backupper Compromised in Short-Burst Supply Chain Campaign
Related: AI Platform Cairn Abused to Hack Over 100 Organizations
