eMudhra Certificate: 8 weak certificates raise Internet Security concerns as browsers act

New Delhi: A serious weakness has been found in the private keys of 8 intermediate certificates linked to Indian digital security company eMudhra, raising concerns about Internet Security. CERT-In issued an advisory on 21 October 2026, and browser makers including Google and Mozilla have taken steps to block the affected certificates.

The incident is significant because a TLS Certificate is used to create a secure connection between a Browser and a website and to verify the website’s identity. If an attacker were able to use an affected private key to issue a fake certificate, the attacker could, in some circumstances, try to imitate a genuine website or read or modify network traffic. However, the information currently available does not establish that the weakness was used to steal data from users on a large scale.

What went wrong with the eMudhra Certificate?

According to CERT-In, sufficient cryptographic randomness was not used when the private keys for the affected certificates were generated. As a result, the keys were far weaker than normally secure keys, and could be recovered very quickly using publicly available information.

The weakness was not in the P-384 elliptic-curve cryptography algorithm itself. Instead, it was in the key-generation process: the method used to create the secret keys intended to protect the certificates. That distinction matters because the incident concerns the implementation of key creation rather than a stated failure of the underlying P-384 algorithm.

Private keys are intended to remain secret. In this case, the concern described by CERT-In is that the affected keys could be recovered from public information because they had not been generated with enough randomness. That could undermine the trust placed in certificates connected to those keys, even though the issue did not affect every certificate associated with eMudhra.

What is an Intermediate CA Certificate?

An intermediate CA certificate is one link in the internet’s certificate trust system. It operates between a trusted Root Certificate Authority and a website’s final TLS Certificate. This structure allows trust to pass through a chain rather than relying on a single certificate for every website or service.

If an attacker gains control of an intermediate CA’s private key and the relevant systems continue to trust that certificate, the attacker may try to create fake website certificates. This can create confusion about a website’s identity and, in some circumstances, make a man-in-the-middle attack possible. The possibility described here does not mean that such an attack occurred; it explains why weak certificate keys are treated as a serious Cyber Security issue.

Steps taken by Google, Mozilla and Cloudflare

After the issue came to light, Cyber Security and technology companies adopted different measures to stop trusting the affected certificates or to protect their infrastructure.

Google Chrome: Google applied a blocking update for the affected public keys on 17 October. The company also put security measures in place for supported Android devices. These steps were intended to prevent the affected keys from continuing to be accepted in the relevant browser and device environments.

Mozilla Firefox: Mozilla blocked the affected TLS intermediate certificates through its OneCRL blocklist. It also issued additional security updates for users with certain configurations. The response reflects the fact that certificate trust can be managed through browser-specific systems as well as through broader operating-system updates.

Cloudflare: Cloudflare applied security measures across its infrastructure and issued updates for products including WARP, Cloudflare One Client and Cloudflare Tunnel. Cloudflare said that its investigation of its services found no evidence of active exploitation of the weakness. That statement relates to the company’s investigation of its own services and does not change the need for affected systems to apply the relevant protections.

Not every device or application checks certificates in exactly the same way. Some software uses its own Trust Store instead of relying entirely on the store maintained by an operating system or browser. Consequently, a security update may not reach every system at the same time, and the availability of a fix for one product does not automatically mean that all other applications have adopted the same change.

Are all eMudhra certificates and digital signatures affected?

No. The scope of the incident is limited, according to eMudhra. The company said that the event was confined to specific intermediate CA certificates. It said that only one of the affected intermediate CAs had been used in production, and that none of them had issued final, or end-entity, certificates for websites or other services.

eMudhra also said that the private key of its Root CA was not affected and that its other intermediate CAs were not affected by the incident. This means the reported weakness should not be treated as a statement that every eMudhra certificate, certificate authority or service has the same problem.

CERT-In’s advisory further states that eMudhra’s domestic Digital Signature Certificate (DSC) and eSign services were not affected. The incident is connected to the company’s public web-certificate trust infrastructure. That distinction separates the reported public web-certificate issue from the domestic DSC and eSign services identified in the advisory.

What should Smartphone and Internet Users do?

For ordinary users, the most important immediate step is to keep devices and applications updated. The incident does not mean that every smartphone or every website has become unsafe. Users should continue to apply available security updates and should treat certificate warnings as important signals rather than routine messages.

Browser updates: Keep Google Chrome, Mozilla Firefox, Edge and other browsers updated with their available security releases. Browser updates may include changes to certificate blocklists or other protections related to how certificates are checked.

Operating System updates: Do not ignore security updates for Android, Windows, macOS and other systems. Operating-system updates can be important where certificate trust is managed through the system’s own Trust Store.

Certificate warnings: If a browser displays a warning about a website’s certificate, do not ignore the warning and continue automatically. A warning can indicate that the connection or the website’s identity could not be verified as expected.

Suspicious links: When logging in to banking or other sensitive services, check that the website has the correct domain. A secure connection alone does not establish that a link has taken the user to the intended website.

Company IT systems: Organisations and website operators should review their certificates, Trust Store settings and application dependencies. This review is particularly relevant for systems that use separate certificate stores or applications that may not receive browser or operating-system updates automatically.

The presence of HTTPS or a lock symbol is not, in every situation, a guarantee that a website is trustworthy. HTTPS helps secure the connection, but checking the actual identity of the website is equally important. Users should therefore consider both the browser’s certificate status and the domain they are visiting.

Why the incident matters for Web Security

The eMudhra Certificate incident shows that internet security depends on more than strong encryption algorithms. A serious error while generating a private key can weaken the trust on which Browsers, websites and online services operate. Even when the underlying cryptographic algorithm is not itself identified as the problem, an unsafe key-generation process can create a risk for certificates that rely on the resulting keys.

Browser companies and security teams have taken steps to block the affected certificates, but protection also depends on how individual devices and applications handle trust. Older devices, software that uses a separate Trust Store and systems that have not been updated for a long time may not adopt the necessary security changes at the same time. Ensuring that those environments receive and apply the relevant protections remains an important part of the response.