Know how eMudhra’s weak private keys triggered a global security alert, what the certificate leak means for UIDAI and the Income Tax portal, and how users can stay safe online

Bengaluru: In mid-October 2026, a serious weakness in the digital certificate system of Bengaluru-based eMudhra Limited raised concerns across the global internet security community. eMudhra, one of India’s licensed Certifying Authorities and a major provider of digital signatures and website security certificates, faced a major security incident after researchers discovered that eight of its intermediate certificates used extremely weak private keys. One of those keys was simply the number 4.

The incident raised questions about the security of the HTTPS padlock that protects banking websites, government portals and other online services. Several Indian government websites, including portals associated with the Unique Identification Authority of India (UIDAI), which issues Aadhaar, and the Income Tax Department’s e-filing portal, have used technology or certificates linked to eMudhra or other Indian Certifying Authorities over the years. However, eMudhra and security researchers have stressed one important point: the company’s root certificates, which form the highest level of trust in its certificate system, remained unaffected.

Here is what readers and security-conscious internet users need to know about the incident, its potential risks and the steps they should take.

What Exactly Happened?

On 17 October 2026, a community researcher known as Wayne reported to Mozilla that attackers could potentially use the private keys of eight eMudhra intermediate certificates because the keys were weak. The researcher demonstrated control of the keys by digitally signing short messages with them. Within hours, Google Chrome and Mozilla Firefox blocked the certificates. Apple followed on 19 October, and Microsoft took action on 20 October. eMudhra revoked all eight certificates the day after the report.

The affected certificates included six Transport Layer Security (TLS) intermediates, which support HTTPS connections, across Domain Validated, Organisation Validated and Extended Validation categories. The set also included two code-signing certificates. eMudhra created all eight certificates during a Key Generation Ceremony on 30 April 2025. The company used Hardware Security Modules that met the FIPS 140-2 Level 3 standard and operated under its elliptic-curve cryptography (ECC) root.

Why Were the Keys So Easy to Break?

A properly generated P-384 elliptic-curve private key should use a random number drawn from an enormous range of possibilities. Its security depends on the difficulty of guessing that number. The eight affected keys, however, used integers smaller than 256. Their values were 4, 56, 66, 115, 155, 156, 230 and 237.

Security researcher Scott Helme recovered several of these keys from publicly available certificates in less than a second on a regular laptop. Mozilla’s Dennis Jackson confirmed the findings and explained that anyone could recover the keys almost instantly by testing the first 256 possible values. The incident did not require an advanced attack against eMudhra’s systems. Instead, a serious failure during key generation left the private keys effectively exposed to anyone who knew where to look.

eMudhra later explained that a flaw in a wrap-and-unwrap step during the key generation ceremony created a second set of weak keys alongside the intended strong keys. The company then published and placed trust in the weak set through browsers. eMudhra maintains that attackers did not breach its infrastructure, steal data or bypass its physical and logical security controls.

Inclusive language

Root Certificates Remain Safe

The most important reassurance concerns eMudhra’s root certificates. Certifying Authorities follow a hierarchy that determines how browsers establish trust in websites.

• Root certificates: These sit at the top of the hierarchy. Browsers and operating systems include them in their trusted certificate stores.
• Intermediate certificates: These receive signatures from root certificates and, in turn, sign the certificates that websites and other services use.
• End-entity certificates: These are the certificates that websites and services use to establish their identities and secure connections.

The incident affected only the private keys of the eight intermediate certificates. It did not compromise eMudhra’s root CA private keys. The investigation also found no impact on intermediate certificates outside this specific group of eight.

Certificate Transparency logs and eMudhra’s own analysis indicate that none of the eight affected intermediates issued publicly trusted end-entity certificates to websites or customers, apart from the possibility of internal test certificates. One intermediate certificate had entered production, but it did not issue any certificates. This significantly limits the evidence of direct exposure to websites and their users.

Connection to Indian Government Websites

eMudhra operates as a licensed Certifying Authority under India’s Information Technology Act, 2000. The company has issued more than 60 million digital certificates and provides services to major Indian banks and government-linked organisations.

Its global TLS business operates under the emSign brand. This business remains largely separate from eMudhra’s Indian Digital Signature Certificate (DSC) and eSign services.

The company has explicitly stated that the incident has “no connection with eMudhra’s Indian Digital Signature Certificate (DSC) and eSign businesses.” These services support a large volume of digital signatures used in Indian government and business transactions. According to eMudhra, they continue to operate normally on separate infrastructure. The company has also stated that its global TLS business contributes only about 1% of its revenue.

Some Indian government portals and services have historically used certificates or related technology associated with eMudhra and other Indian Certifying Authorities. However, no publicly available evidence links the compromised intermediate certificates to certificates issued for UIDAI, the Income Tax Department’s e-filing portal or other critical .gov.in websites.

The absence of publicly trusted end-entity certificates issued under the weak intermediates further reduces the immediate risk to these government portals. Still, the incident highlights why organisations must maintain strong certificate management practices and respond quickly when researchers identify cryptographic weaknesses.

Timeline of the Response

• 17 October 2026, around 20:06 UTC: Mozilla received the report through the Chrome Root Program.
• 17 October 2026: Google Chrome and Mozilla Firefox blocked the affected certificates through their certificate-blocking mechanisms, CRLSet and OneCRL.
• 18 October 2026: eMudhra revoked all eight certificates.
• 19 October 2026: Apple blocked the certificates. Sectigo, which had cross-signed some of them, also took action.
• 20 October 2026: Microsoft blocked the certificates. Mozilla removed the relevant root from its trust store through an update to Network Security Services (NSS). eMudhra also published its official statement.
• Following days: The Go programming language, Python’s certifi package, Rust’s webpki-roots and other software libraries released updates. Cloudflare and other service providers also patched their systems.

So far, investigators have found no forged certificates issued using the compromised keys in Certificate Transparency logs. These logs help security researchers monitor the public issuance of digital certificates and identify suspicious activity.

Real Risks and Who Is Exposed

An attacker who possessed one of the weak private keys could create an HTTPS certificate that appeared valid for almost any domain, including a bank, government portal, Gmail or another online service. The attacker could then exploit a man-in-the-middle position, such as a compromised Wi-Fi network, a malicious router or intercepted network traffic, to impersonate a website and potentially read or alter communications.

The two compromised code-signing certificates created a different risk. An attacker could potentially use them to make malicious software appear to come from a trusted publisher, increasing the chances that users or security systems would accept it.

Several factors have limited the practical risk:

• Investigators have found no evidence that the affected intermediates issued publicly trusted end-entity certificates.
• Major browser developers responded quickly and blocked the certificates.
• An attacker would still need a suitable man-in-the-middle position to exploit the TLS weakness against a user’s connection.
• Security updates have reached many browsers, software libraries and online services.

However, some systems may remain more vulnerable than others. These include devices and applications that do not check certificate revocation information, older Linux distributions with poorly maintained trust stores, software that carries its own outdated certificate lists, and systems that rely on untrusted networks.

Users and organisations should therefore avoid assuming that every device has received the necessary updates simply because major browsers have blocked the certificates.

What Ordinary Users and Organisations Should Do

For everyday users:

• Update your browser: Install the latest available versions of Chrome, Firefox, Edge and Safari. The specific Firefox version mentioned in the incident guidance is 158.0.1 or later.
• Keep your operating system updated: Install security updates for Windows, macOS, Linux, Android and iOS, as applicable.
• Update mobile apps: Some applications use their own certificate stores, so browser updates alone may not protect every connection.
• Use public Wi-Fi carefully: Avoid sensitive transactions on untrusted networks until you have updated your devices and applications. Use trusted networks whenever possible.
• Check certificate trust when necessary: You can use the community site emudhra.we-have-a-problem.com to test whether your browser still trusts the affected certificates.

For system administrators and developers:

• Update Go: Upgrade to Go 1.27.3, Go 1.26.10 or a later version, as applicable, and rebuild affected applications.
• Refresh certificate bundles: Update the certificate packages and trust stores used by Python, Node.js, Rust, Java and other development environments.
• Review hard-coded trust stores: Identify systems that bundle, cache or manually maintain certificate lists instead of receiving current updates.
• Check certificate chains: Review certificates that chain to the affected intermediates and replace any that remain in use.
• Review internal systems: Check test environments, production deployments and other systems that may use separately maintained certificate stores.

eMudhra estimated that its global TLS business needed to migrate around 30,000 certificates. Organisations that rely on its services should follow the company’s migration guidance and confirm that their systems no longer trust or use the affected certificates.

Broader Lessons for India and the Web

The incident shows how a single error during key generation can undermine trust across the entire Public Key Infrastructure (PKI), the system that helps browsers, websites and digital services verify identities and establish secure connections.

India’s digital economy relies heavily on digital signatures and trusted certificates for services ranging from income tax filing to Aadhaar-linked transactions. Although eMudhra’s root certificates remained safe and the company says its Indian DSC and eSign businesses operate separately, the incident demonstrates that even licensed and audited Certifying Authorities can suffer serious cryptographic failures.

The episode also highlights the importance of Certificate Transparency logs, prompt browser updates and independent security researchers. Researchers recovered the weak keys within seconds, while browser developers and software maintainers moved quickly to restrict their use. Their response helped contain the potential damage before investigators found evidence of widespread malicious exploitation.

That outcome reflects the value of cooperation across the global Web Public Key Infrastructure (WebPKI). However, the incident also raises questions about how a basic key-generation error passed through the company’s safeguards and resulted in certificates that browsers trusted.

Current Status

As of 21 October 2026, eMudhra has revoked all eight affected intermediate certificates, and major browsers and many software libraries have blocked them. The company continues to investigate the incident and has committed to providing further updates. Investigators have not found evidence of active exploitation.

eMudhra’s Indian digital signature and eSign services remain unaffected, according to the company. For most Indian citizens who use Aadhaar authentication, file income tax returns or bank online, the immediate practical risk appears low, provided they keep their browsers, devices and applications updated.

The incident nevertheless serves as a warning about the cryptographic systems that quietly protect everyday internet activity. Users rarely see the complex chain of certificates behind an HTTPS connection, but they rely on that chain whenever they enter a password, submit a tax return or access a government service.

The padlock in your browser’s address bar depends on the security of every certificate in the chain that establishes trust. In this case, one of the weakest private keys was the number 4. The internet security community detected the problem, acted quickly and appears to have contained the damage. But the incident will remain a reminder that even the most trusted digital systems can fail when their basic security processes go wrong.