Browsers and Tech Firms Block 8 eMudhra Certificates Over Flawed Private Key Generation

Major browser developers and technology companies have moved to block eight intermediate digital certificates issued by India-based certificate authority eMudhra Limited, after a flaw in how their private keys were generated left them open to being guessed.

According to Cointelegraph, protections had been rolled out across the main browser ecosystems by Tuesday. The weakness could have allowed an attacker to forge HTTPS certificates for any website and use them to impersonate legitimate services.

What happened

The problem lies in the process used to create the private keys behind eight intermediate certificates operated by eMudhra. Those keys were not generated with enough randomness to keep them secret, meaning a determined party could work them out.

Mozilla cryptography engineer Dennis Jackson set out the issue in an incident report. He said Mozilla was able to recover the private keys on its own after first being alerted on Saturday, confirming that the generation method was faulty. Jackson described the weakness as "trivial to exploit".

Mozilla warned that an attacker able to intercept a user's connection could present a fraudulent certificate built on one of these keys. That would let the attacker pose as a genuine website and potentially read or tamper with the data passing between the user and the site.

How the industry responded

The response was fast by the standards of web infrastructure. Mozilla's Firefox security team said in a blog post on Tuesday that it had received the report on Saturday and blocked the affected certificates the same day through OneCRL, its mechanism for revoking intermediate certificates across Firefox installations.

Because some users run Firefox with custom settings that stop OneCRL updates from arriving, Mozilla also shipped a browser update for desktop and Android to cover them.

According to Jackson, Google's Chrome has rejected the certificates from Saturday onwards, Apple's devices began doing so on Monday, and Microsoft's platforms followed on Tuesday. Cloudflare said it learned of the report on Monday and on Tuesday released updates for its Cloudflare One and WARP clients and for Cloudflare Tunnel, alongside wider mitigations across its services.

According to Jackson, the problem had been responsibly disclosed to downstream trust stores on 19 October. He said many had already released updates or were in the process of doing so.

• Firefox: blocked via OneCRL on Saturday, with a follow-up browser update
• Chrome: blocked since Saturday
• Apple devices: blocked since Monday
• Microsoft platforms: blocked since Tuesday
• Cloudflare: client updates and mitigations released on Tuesday

Why intermediate certificates matter

The security of the encrypted web rests on a chain of trust. Browsers and operating systems ship with a list of trusted root certificates belonging to certificate authorities. Those authorities typically use intermediate certificates, signed by the root, to issue the everyday certificates that websites present when a user connects over HTTPS.

If someone obtains the private key of an intermediate certificate, they can in effect act as a certificate authority. Any certificate they sign will chain back to a trusted root and be accepted by software that trusts that root. That is why a compromise at the intermediate level is considered so serious: it is not limited to a single domain but can extend to any website.

In this case the risk did not stem from a break-in at the authority but from weak key generation. The outcome is comparable, however. A key that can be reconstructed by an outsider offers no more protection than one that has been stolen.

Revoking or distrusting the affected intermediates is the standard remedy. Once software has been told not to accept them, certificates signed by those keys should be rejected, whether they are legitimate or forged.

The limits of the fix

The speed of the browser response should not be read as a complete resolution. Cointelegraph noted that the danger persists for applications and systems that do not receive these blocks automatically.

Jackson said there was no evidence that users of Firefox, Chrome, Edge or Safari had been targeted in this way. He pointed to Certificate Transparency logs, the public records in which certificates are logged so that misissuance can be detected, which showed no entries for the intermediate certificates since April 2025. Major browsers generally expect certificates to appear in these logs, so a forged certificate used against them would be likely to leave a visible trace.

The picture is less clear elsewhere. Jackson cautioned that many clients outside the browser ecosystem do not enforce Certificate Transparency, and said it was unknown whether attackers had used the flawed key generation against them.

That category is broad. It can include mobile apps with their own networking code, enterprise software, embedded devices, command-line tools and automated systems that rely on an operating system's or library's certificate store. Some of these update slowly, or rely on trust lists that are refreshed infrequently, which can leave a window in which revoked certificates are still accepted.

For organisations, the practical task is to check which of their systems trust the relevant root and whether those systems have received updated trust data. Software that pins its own certificate bundle may need a manual update.

Echoes of DigiNotar

The episode inevitably recalls the 2011 compromise of DigiNotar, a Dutch certificate authority. In that attack, hackers breached the company and issued 531 fraudulent SSL certificates.

Those rogue certificates were used to impersonate Google and to spy on roughly 300,000 Gmail accounts in Iran. The incident became a reference point for the industry and helped drive later reforms in how certificate authorities are overseen, including wider adoption of public logging of certificates.

The contrast with the present case is instructive. In 2011, the fraudulent certificates were in active use before the breach was widely understood. This time, according to Jackson, the major browsers can point to transparency logs as evidence that no suspicious certificates chaining to the affected intermediates have appeared in recent months, and blocks were in place within days of the report.

Even so, the fact that keys could be recovered at all raises questions about key-generation practices and audit processes at certificate authorities, and about how such weaknesses went undetected.

What to watch next

Several questions remain open. The first is whether eMudhra or the wider community will publish more detail on how the flawed key-generation process came about and whether any other keys were produced in the same way.

The second is how quickly the long tail of non-browser software catches up. Trust stores that have not yet shipped updates will be under pressure to do so, and organisations running older systems may need to intervene directly.

The third is the response of the root programmes run by browser and operating system vendors. Incidents of this kind are typically followed by scrutiny of the authority involved, and the outcome of that process will shape how much trust is extended to eMudhra's certificates in future.

For most people using an up-to-date mainstream browser, the immediate risk appears to have been contained. The broader lesson is that the security of encrypted connections depends not only on strong cryptography but on every authority in the chain generating and protecting its keys properly.