Tech Giants Move to Block 8 eMudhra Certificates Linked to Fake Sites

Major browser vendors and cloud security providers have rolled out emergency blocks for eight intermediate TLS certificates issued by India-based certificate authority eMudhra Limited after researchers determined the certificates’ key-generation process was flawed and “trivial to exploit.” Mozilla says it was able to recover the affected private keys after receiving notice of the issue, underscoring how attackers could potentially impersonate legitimate websites.

The incident is a reminder that public key infrastructure (PKI) failures don’t stay confined to a single browser. While many organizations quickly added certificate blocks, Mozilla warns the risk can persist for systems and applications that don’t automatically consume those updates.

Key takeaways

• Mozilla says the flawed eMudhra intermediate certificates could enable man-in-the-middle style impersonation of legitimate sites.


• Tech companies responded by blocking the eight certificates across major browsers and platforms, including Firefox, Chrome, Apple devices, and Microsoft environments.


• Mozilla implemented protections via OneCRL and also shipped browser updates to ensure users received the necessary mitigations.


• Mozilla emphasizes there’s no clear evidence of active exploitation against browsers, but non-browser clients may still be exposed.

Why the eMudhra certificate flaw matters

According to Mozilla cryptography engineer Dennis Jackson, the problematic certificates stem from a key-generation process that was “flawed” and “trivial to exploit.” In an incident report, Jackson says Mozilla independently recovered the private keys shortly after first receiving notice on Saturday, which helped confirm the underlying weakness.

If an attacker can intercept a user’s connection, they may be able to present fraudulent certificates to masquerade as real websites. Mozilla explains that such impersonation could allow adversaries to read or alter information exchanged during the session, depending on how the attack is carried out and what protections the target environment applies.

That potential impact is the core reason for rapid emergency action across trust stores: certificate trust is the foundation that browsers and many client applications use to decide whether an endpoint is authentic.

How protection was rolled out across browsers and platforms

Mozilla’s Firefox security team said it received the report on Saturday and moved quickly to block the affected intermediate certificates in Firefox using OneCRL, completing that work the same day. Mozilla then released updates for Firefox on both Desktop and Android.

Mozilla also indicated that those updates included custom settings meant to prevent certain users from missing the OneCRL mitigation. This detail is significant because blocking certificates isn’t only about whether a block exists—it’s also about whether client configurations actually pull the block changes in a timely way.

Cloudflare, which also operates security infrastructure for web traffic, reported that it learned about the issue on Monday. It subsequently published updates for Cloudflare One and WARP Clients and for Cloudflare Tunnel on Tuesday, along with mitigations across related services.

Jackson further stated that the certificates have been blocked in Chrome since Saturday, on Apple devices since Monday, and on Microsoft platforms since Tuesday. In other words, multiple trust ecosystems moved from identification to trust-store enforcement within days.

What’s known about exploitation—and what remains uncertain

Jackson said there is no evidence that Firefox, Chrome, Edge, or Safari have been attacked in this particular way. He pointed to the absence of entries in certificate transparency logs for the intermediate certificates since April 2025.

However, Mozilla’s engineer also cautioned that many clients outside the browser ecosystem don’t enforce Certificate Transparency. That means the lack of log entries doesn’t fully eliminate risk—attackers might still be able to target systems that rely on different validation behaviors.

In the same incident discussion, Jackson said many downstream clients do not apply the same transparency checks, and “we do not know if attackers exploited the flawed key generation to target these clients.” For organizations, this highlights a common PKI asymmetry: browsers may provide stronger guardrails, while custom clients, embedded systems, and legacy enterprise components may not.

Lessons from past certificate authority incidents

The response to eMudhra echoes historical trust-store failures—most notably the 2011 DigiNotar breach. In that case, attackers compromised a certificate authority and issued hundreds of fraudulent SSL certificates, enabling impersonation and surveillance of users.

While the current incident is tied to a different set of certificates and a different origin, the operational takeaway is similar: once a certificate authority’s keys are mishandled or generated incorrectly, attackers can potentially produce believable certificates that evade naïve defenses.

Mozilla’s emphasis on where blocks may not propagate automatically is particularly relevant in enterprise environments, where internal proxies, specialized clients, and private application stacks can behave differently than mainstream browsers.

Next, readers should watch for confirmation that the blocked certificates are fully removed from all major client trust stores and for guidance on exposure in non-browser clients that may not use Certificate Transparency. The longer tail is less about browsers—already largely mitigated—and more about any systems that depend on trust decisions that aren’t automatically updated when certificate blocks are published.

https://www.cryptobreaking.com/tech-giants-move-to-block/?utm_source=blogger%20&utm_medium=social_auto&utm_campaign=Tech%20Giants%20Move%20to%20Block%208%20eMudhra%20Certificates%20Linked%20to%20Fake%20Sites%20