2026 · Security

The eMudhra key compromise: when a certificate authority’s keys could be guessed

Last reviewed 26 October 2026

In October 2026 a researcher showed that eight intermediate certificate authority keys belonging to India’s eMudhra were so weak they could be recovered in under a second. Browsers blocked them within hours, and eMudhra quit the global TLS certificate business.

Why a certificate authority’s keys matter

The padlock in a browser rests on certificate authorities (CAs). A CA vouches that a certificate for a website really belongs to whoever runs that site, and browsers and operating systems ship with a list of CAs they trust. Most certificates are signed by intermediate CAs, which in turn are vouched for by a trusted root.

If someone obtains an intermediate CA’s private key, they can sign a certificate for any domain they like, such as a bank, an email provider or a government portal, and devices that trust that CA will accept it. That allows an attacker in a position to intercept traffic to impersonate the real site, read the traffic or change it. For code-signing CAs, the same applies to software that claims to come from a trusted publisher.

eMudhra is a listed Indian company based in Bengaluru and one of the country’s largest issuers of digital signature certificates. It says it has issued more than 60 million certificates, and its emSign roots were trusted by Apple, Google, Microsoft and Mozilla.

What went wrong

The problem affected eight intermediate CAs using NIST P-384 elliptic-curve keys: six for website (TLS) certificates and two for code signing. They were created on 30 April 2025 in a key ceremony that produced 24 intermediates. Sectigo cross-signed the eight in May 2025, extending their trust further.

A P-384 private key should be a random number about 384 bits long. Mozilla’s Dennis Jackson confirmed that all eight affected keys were integers smaller than 256. The security researcher Scott Helme found that one of them was simply the number 4. Anyone with a public certificate could work out the private key almost instantly.

eMudhra’s explanation is that a test routine in the ceremony script, used to check the hardware security module’s key wrap and unwrap functions, generated a second set of keys with almost no randomness. Their labels resembled those of the properly generated keys, and staff picked the weak ones. The company said the hardware worked as designed, blamed the automation script and admitted human errors at several steps.

There may have been an earlier warning. In May 2025, monitors of public certificate data noticed eMudhra publishing revocation lists with invalid signatures for these intermediates (Mozilla bug 1970728). According to analyses of that record, the fix was to re-sign the lists with the second set of keys, which hid the underlying problem rather than revealing it.

How it was discovered

On 17 October 2026 an independent researcher, credited by Mozilla only as “Wayne”, found that the keys could be reconstructed while looking through the Common CA Database, the shared record that browser makers use to track CAs. To prove it, Wayne signed the message “We have a problem here - Wayne” with each of the eight private keys and sent it to Apple, Google, Microsoft, Mozilla and eMudhra.

eMudhra later said the weak keys were found “possibly with AI-assisted techniques”. That has not been confirmed, and given how small the keys were, no special tools would have been needed. Dennis Jackson made the problem public on 20 October, and Scott Helme independently recovered all eight keys in under a second.

The response, hour by hour

Chrome received the report at 18:05 UTC on 17 October and had blocked the six TLS intermediates through its CRLSet mechanism by 19:45 UTC. Mozilla received it at 20:06 UTC and finished pushing a OneCRL block at 22:59 UTC. eMudhra revoked the eight intermediates on 18 October, and Sectigo revoked its cross-signatures. Apple and Android blocked the certificates on 19 October and Microsoft on 20 October.

Software outside browsers needed separate fixes, because many programs carry their own lists of trusted CAs. Go shipped fixes under CVE-2026-111943 (1.27.3 and 1.26.10), Firefox 158.0.1 carried the block under CVE-2026-113470, and Node.js added it to its 21 October security releases (26.12.1, 24.22.1 and 22.23.4). Python’s certifi, Rust’s webpki-roots, Composer, Debian, Ubuntu and Homebrew updated their certificate bundles. Cloudflare, which learned of the issue on 19 October, updated its WARP client, 1.1.1.1 app and cloudflared before the problem became public.

Mozilla went further and removed eMudhra’s emSign ECC Root CA - G3 root from its trust store. Chrome scheduled the same removal to reach users on 27 October and said it was reviewing eMudhra’s remaining CA certificates.

What the impact was

No exploitation has been found. Cloudflare saw no attacks against its services, and Google reported that none of the six TLS intermediates appeared in Certificate Transparency logs, the public record of issued certificates. eMudhra says only one of the eight keys was ever put into use, none issued certificates to customers, and no customer data or systems were breached. Its domestic eSign and digital signature services run on separate infrastructure and were not affected.

The open question is the past. The weak keys existed for about 17 months before the report, and it is not known whether anyone else recovered them in that time. A certificate forged with one of them would not have needed to appear in public logs to work against some clients.

The bigger disruption came from removing the root. Chrome counted about 30,800 unexpired certificates chaining to the emSign ECC root as of 21 October, 99.9% of them issued through InCommon, a certificate service used by US universities. eMudhra estimated about 30,000 certificates would need to be moved to another CA. Some sites became unreachable after the revocations, reportedly including Indian government sites such as FSSAI’s and a Kerala higher education portal. Apps, servers and devices that do not receive trust-store updates may continue to trust the bad intermediates for a long time.

Was eMudhra punished?

As of 26 October 2026 we found no report of a fine, penalty or formal enforcement action against eMudhra by any government or regulator. Claims that eMudhra has been fined or banned should be treated with caution unless they cite an official decision.

The consequences so far have come from the browser makers and the market. On the web, root programmes run by Mozilla, Google, Apple and Microsoft are in effect the regulators: their decision to remove a root is the most serious sanction a public CA can face. Previous cases ended badly for the CA concerned. DigiNotar went bankrupt after its 2011 breach, and Google and Mozilla phased out trust in Symantec’s certificates in 2017 and 2018.

eMudhra’s shares fell 20%, the maximum daily drop allowed, on 21 October and about 40% over two days. On 22 October its board decided to leave the global SSL/TLS certificate business, which the company said earned about 1% of its revenue. It promised free replacement certificates for TLS customers, a full incident report through the Common CA Database, an independent audit of its development processes and a recheck of every key ceremony it has run.

In India, CERT-In issued advisory CIAD-2026-0050 on 21 October, telling organisations to update trust stores and not to disable certificate checks. The Ministry of Electronics and Information Technology said that digital signature certificates and eSign services regulated by the Controller of Certifying Authorities were not affected, and was reported to have set up a special investigation team. Whether that leads to action against eMudhra is not yet known.

Lessons

Key ceremonies are slow, scripted and audited precisely so that mistakes like this cannot happen. A simple check that each new public key was not trivially small would have caught it. The episode echoes the 2008 Debian OpenSSL bug, when a code change left keys with so little randomness that every possible key could be listed.

For everyone else, the lesson is about the long tail. Browsers fixed this within hours. Older phones, embedded devices, containers and applications with their own CA bundles can take months or years. Knowing which trust stores your systems use, and updating them, is now part of routine patching. For the same week’s software vulnerabilities, see our explainers on PHP2Shell and on AI and security.