The eMudhra Key Incident: How a Certificate Authority's Private Key Ended Up Being 4

On 17 October 2026 a researcher showed that eight intermediate certificate authority (CA) keys belonging to eMudhra, India's largest issuer of digital signature certificates, were not secret at all. A properly generated ECDSA P-384 private key is a random number about 115 digits long. These were integers below 256, and one of them was the number 4. Anyone with the public certificate could compute the key in a fraction of a second, and with it issue certificates that browsers would trust for any website.

Browsers blocked the intermediates within hours, and Chrome and Mozilla removed one of eMudhra's roots. The incident hit eMudhra's global TLS and code-signing business, not, on current evidence, the Indian digital signature certificates (DSCs) used for GST, MCA21 and income tax filings. This post covers what happened, how a key can end up being 4, what is still disputed, and what it means for people and businesses in India.

What Happened

The eight certificates were six TLS intermediates (EM EV, OV and DV TLS CA – G3B and G3C, under the emSign Root TLS CA – G3) and two code-signing intermediates (EM OV CS CA – G3B and G3C). The G3B and G3C intermediates served eMudhra's European and US entities. eMudhra says only one of the eight was in production and that none had issued end-entity certificates. Because Sectigo had cross-signed them, the weak keys appeared in 16 certificates across several trust paths, according to an analysis by PKI veteran Ryan Hurst.

How a Private Key Can Be 4

In elliptic-curve cryptography, a private key is a number d, and the public key is the point you get by "multiplying" a fixed base point G on the curve by d. Going forward is easy. Going backward, from the public point to d, is infeasible when d is a random number between 1 and roughly 2³⁸⁴. That is the whole security of the scheme.

If d is smaller than 256, there are only 255 possibilities. An attacker computes 1·G, 2·G, 3·G and so on, and compares each result with the public key in the certificate. The match turns up almost instantly. Mozilla's Dennis Jackson described the keys as recoverable "near instantly" after recovering them himself on the same evening, without knowing the researcher's method.

The uncomfortable part is that a key of 4 still produces a perfectly valid public key. Standard checks that a public key is a correct point on the curve pass. Only a check for known-weak values catches it, such as Google's open-source paranoid_crypto library, public since 2022. Hurst ran such a scan across all 10,313 CA certificates in Mozilla's CCADB and found exactly the 16 affected certificates, and nothing else.

How It Got There: eMudhra's Account and the Open Questions

In the Mozilla bug, eMudhra says the keys were generated on Utimaco hardware security modules (HSMs). Its account is that, during the April 2025 ceremony, staff ran an approved deviation to test wrapping and unwrapping keys for export. A flaw in that code created a second, weaker key pair on the HSM, and because the key labels were similar, staff used the weak pair when creating the certificate signing requests. eMudhra acknowledges "human errors in multiple steps."

Utimaco said on 23 October that it found no flaw in its HSMs' random number generation or key generation, that its devices do not let applications request an ECC key with a chosen value, and that a scripting error appears to have created the alternative keys. Commenters on the bug are still asking whether the weak keys were generated inside an HSM at all or imported into one, which matters because eMudhra's own policy requires generation inside FIPS 140-2 Level 3 hardware. eMudhra's status page has said the exact root cause is not yet confirmed. Until an independent review reports, the scripting-error explanation should be read as eMudhra's account.

There was also an earlier warning sign. In June 2025, six CRLs for the same new intermediates were published with invalid signatures. eMudhra attributed it to an "incorrect CA key configuration" and fixed it. In the 2026 bug, eMudhra explained that the CRLs had first been signed with the original keys and then re-signed with the flawed ones. Chrome's root program has asked why eMudhra did not halt and revoke at that point, and why its 2025 report did not mention two key pairs. Hurst argues that eMudhra had cryptographic evidence of the mismatch in 2025 and resolved it in favour of the wrong keys. eMudhra has not publicly answered those questions.

The flaw went undetected for about 18 months, through two audit cycles by its WebTrust auditor.

Was Anyone Attacked?

No malicious use has been reported. Google said no certificates chaining to the affected intermediates had been logged to Certificate Transparency (CT) before the block, so fraudulent certificates from them could not have been used against clients that enforce CT, which includes Chrome and most modern Android apps. Cisco Talos said on 21 October that it had not seen malicious use in the wild.

After disclosure, people did use the keys. Within about a day, more than 107,000 certificates signed with six of the keys were logged to CT, including over 106,000 proof-of-concept certificates for google.com. Those demonstrate that the keys are public; they are not evidence of attacks. The real exposure is in software that checks neither CT nor revocation and updates its trust store rarely: some VPN clients, IoT and network appliances, and old Java and Android trust stores.

There was also collateral damage. Removing the emSign ECC Root CA – G3 affected about 30,800 legitimate certificates, almost all issued through InCommon, a US university federation. eMudhra says those certificates were not signed with the weak keys, but they had to be replaced because their root lost trust.

How Browsers and the Government Responded

• Google Chrome blocked the intermediates' public keys through CRLSet at 19:45 UTC on 17 October and removed the emSign ECC Root CA – G3 from the Chrome Root Store, rolling out on 27 October. Chrome noted that eMudhra's roots had entered its store with the 2022 baseline without a full inclusion review, that its inclusion applications since then had been denied, and that it is reviewing eMudhra's remaining roots.
• Mozilla blocked the intermediates through OneCRL the same day and announced an emergency removal of trust in the root on 20 October, shipping an unscheduled Firefox release. Dennis Jackson wrote that the impact "could not be higher."
• Microsoft added the intermediates to its disallowed list and, on 26 October, released out-of-band Windows updates removing seven certificates. Apple blocked the certificates and asked for new attestations covering the cross-signs.
• MeitY said on 21 October that it had constituted a special team to investigate, that the impact on Indian websites and apps was "very limited," and that DSC and eSign services regulated by the CCA were "completely unaffected." It also warned against fear-mongering and noted that the global TLS business is audited under WebTrust, not by MeitY.
• CERT-In reportedly issued advisory CIAD-2026-0050 on 21 October, warning of website impersonation and man-in-the-middle attacks and recommending updates and certificate replacement.
• eMudhra apologised, said it had accepted its error "without qualification," announced its exit from the global SSL/TLS business, which it puts at about 1% of revenue, and appointed KPMG as an independent reviewer on 30 October. The scope and timeline of that review, and whether it will be published, have not been stated.

The market reaction was sharp: eMudhra's shares fell 20% to the lower circuit on 21 October and reached a 52-week low of Rs 318 on 26 October, roughly half their September high.

Does This Affect Indian DSCs and eSign?

On current evidence, no. Nothing credible shows that Indian DSC or eSign keys were weak or compromised. eMudhra and MeitY both say these services run on separate infrastructure. The design also differs: since November 2013, the Controller of Certifying Authorities (CCA) has required Class 2 and Class 3 DSC key pairs to be generated on the subscriber's own FIPS-certified hardware token, so eMudhra does not hold those private keys. Aadhaar-based eSign works differently again, with a one-time key generated and destroyed inside the provider's HSM, but it is also not implicated.

Three caveats are worth stating plainly:

• The "unaffected" assurance comes from the company and the ministry. It has not been independently verified, and the CCA itself has made no public statement.
• The certificate authority that signs Indian DSCs is a separate CA hierarchy, but it is run by the same organisation whose ceremony controls failed. The Internet Freedom Foundation has asked eMudhra to publish the results of re-checking every key ceremony, including domestic ones, and eMudhra has said it will re-verify its ceremonies.
• Indian websites and banks that use eMudhra TLS roots can still be affected by trust changes, as some reported loading failures showed. That is a TLS issue, not a DSC one.

Why it matters: under the IT Act 2000, a digital signature is legally equivalent to a handwritten one. A compromised DSC private key would let someone sign tax returns, company filings and tenders in another person's name. That did not happen here, but it is why the domestic ceremonies deserve the same independent scrutiny as the global ones.

What to Do Now

Lessons for Anyone Who Handles Keys

• Hardware does not guarantee good keys. An HSM protects a key once it exists. If the process around it can create, import or select the wrong key, the HSM will faithfully protect a bad one.
• Test the key itself, not only the certificate. Screening for weak and known-bad values is cheap, and it found every affected certificate here in one pass. The Baseline Requirements do not currently require it for subordinate CA keys.
• Treat anomalies as incidents. A signature that does not verify is evidence that something is wrong with a key. Fixing the symptom in 2025 left the cause in place until 2026.
• Audits are not a substitute for verification. The weakness survived two audit cycles. Independent researchers using public data found it.
• Certificate Transparency works. Public logs are the reason Google could say CT-enforcing clients were never exposed.

This is not the first time a trusted authority's keys failed. DigiNotar was hacked in 2011 and its certificates were used against users in Iran; Chrome distrusted Symantec in 2017–18 and Entrust in 2024 over compliance failures; and in 2017 the ROCA flaw in Infineon chips forced Estonia to suspend hundreds of thousands of ID-card certificates because their keys had been generated weakly. What makes the eMudhra case unusual is how simple the weakness was.

For messaging, the lesson is the same: the safest key is one generated on your own device and never handed to anyone else. That is how Lupyd works. Keys for direct messages (Signal Protocol) and group channels (MLS) are created on users' devices, and servers only relay ciphertext they cannot read. See how encryption and keys work for the basics, or try Lupyd for your team.

Frequently Asked Questions

Final Takeaway

The eMudhra incident was not a sophisticated attack. It was a key-generation process that produced keys anyone could guess, and controls that missed it for 18 months. The browser ecosystem's response was fast and, thanks to Certificate Transparency, largely effective. The open questions now are India's: whether the independent review covers the domestic CA ceremonies behind the country's digital signatures, and whether the regulator says so publicly.

Last updated: 2 November 2026. This article is general information based on public sources, not legal or security advice. The root cause is still under review; we will update this post when eMudhra's full incident report or the independent review is published.