eMudhra faces scrutiny after weak certificate keys raise web security concerns

Eight intermediate certificate authority keys linked to eMudhra’s global website-security business were found to be dangerously weak. They mattered because intermediate CAs can issue certificates trusted through a parent root, so faulty keys can undermine the web’s identity checks.

According to eMudhra, a key-wrap/unwrap step in its key-generation procedure produced a second, weak set of keys. The affected keys were generated on April 30, 2025, and were subsequently published to browser root stores. The company said its root private key was not compromised.

The weakness could have allowed attackers to create fraudulent HTTPS certificates and impersonate legitimate websites. Browser operators withdrew trust from the associated emSign ECC Root CA - G3 as a precaution. eMudhra said none of the eight authorities issued end-user certificates, and it is reviewing its procedures while the investigation continues.

A certificate authority, or CA, verifies an identity and issues a digital certificate. That certificate helps browsers decide whether a website is the site it claims to be. This matters because HTTPS depends on reliable identity checks, not encryption alone.

Intermediate authorities sit below a root certificate trusted by browsers and operating systems. They can issue certificates for websites while the root remains the higher-level anchor of trust. The structure lets a CA manage certificates through delegated layers rather than using the root directly for every website.

In eMudhra’s case, eight intermediate authorities were linked to its global website-security business. Their weak keys could have enabled fraudulent certificates that browsers might accept. Browser operators therefore withdrew trust from the associated emSign ECC Root CA - G3, showing that trust can be limited when a CA’s controls fail.

The eight weak intermediate CA keys were generated on April 30, 2025. eMudhra said the weakness remained undetected for about 18 months, according to its October 21, 2026 statement. The delay matters because certificate authorities are expected to protect the keys that support browser trust.

The incident involved eight intermediate authorities linked to eMudhra’s global website-security business. A key-wrap/unwrap step in the generation process produced a second, weak set of keys. Those keys were later published to browser root stores, where they became relevant to the trust decisions made by browsers.

The article does not identify the exact detection date or explain precisely how the weakness escaped review. It says the company is investigating and reviewing its key-generation procedures. It also raises questions about how the issue passed through two audit cycles, while eMudhra said no data was breached.

The weak keys could have let attackers create fraudulent HTTPS certificates. A forged certificate could make an attacker appear to be a legitimate website to clients that still trusted the affected certificate authorities. That threatens the identity check behind secure web connections.

The mechanism involved the intermediate CA keys. These authorities operate under a browser-trusted root and can issue website certificates. Google warned that anyone could forge trusted HTTPS certificates against clients that had not yet removed trust. In response, browser operators blocked the affected keys and withdrew trust from the associated root.

This protection reduces the chance that browsers accept certificates from the compromised trust chain. However, it can also affect legitimate sites using that chain. Google planned to remove the parent root from Chrome’s trust store from October 27, Pacific time, so some legitimate websites may stop functioning in Chrome until their certificates are replaced.

Chrome and Firefox moved to limit the risk from the weak keys. Google’s Chrome Security team blocked the affected keys and planned to remove the parent root from Chrome’s trust store from October 27, Pacific time. Mozilla blocked the affected certificates in Firefox within three hours of receiving the report.

Browsers maintain their own trusted certificate lists. When they remove a root or block certificates, websites relying on that trust chain can no longer complete the browser’s certificate check. This prevents forged certificates from being accepted by protected clients that have received the safeguard.

The same action can affect legitimate services. Google warned that some websites using certificates under the emSign ECC Root CA - G3 may stop functioning in Chrome. eMudhra identified one affected customer ecosystem in the United States, where certificates are being replaced. Its Indian digital-signature and eSign services use separate infrastructure and remain unaffected.

Certificate Transparency logs provide public records of certificate issuance. They help security teams and others spot certificates that look suspicious or were issued unexpectedly. This matters because a certificate authority’s mistake or compromise can otherwise remain difficult to see.

Browser trust stores provide the containment layer. They list the certificate authorities browsers accept, while browser operators can block affected keys or remove a parent root. In this incident, Google blocked the weak keys, and Mozilla blocked the affected certificates within three hours of receiving the report.

These defenses work in different ways. Logs can help detect questionable issuance; trust-store changes can limit acceptance after a problem is identified. The article says the incident raises questions about how the weakness escaped detection through two audit cycles. eMudhra is reviewing its procedures and offering certificates from an additional authority to reduce dependence on one trust chain.

HTTPS uses encryption to protect communications between a browser and a website. That protection helps keep traffic confidential while it travels. But encryption alone does not prove who is on the other end, so HTTPS also relies on digital certificates.

A certificate authority verifies a website’s identity and issues its certificate. The browser checks that certificate against a trusted authority chain, including any intermediate authority and its parent root. If the chain is accepted, the browser can use the certificate as evidence that the connection belongs to the intended site while encrypted communication is established.

The eMudhra incident shows why both parts matter. Weak CA keys could have enabled forged certificates and website impersonation, even though HTTPS encryption itself was not described as broken. Browser safeguards therefore blocked keys and withdrew trust from the affected root. Reliable certificates are essential for encryption to protect the right connection.