Browsers Dumped eMudhra's Keys — They Were Numbers Under 256
A padlock icon in your browser is a promise. This weekend, the company that broke it is an Indian certificate authority — and the numbers behind the failure are almost funny, until you realise what they were protecting.
Eight intermediate certificate-authority keys run by eMudhra, the firm behind the emSign brand, turned out to be so weakly generated that a security researcher could simply compute them. According to Mozilla's incident notes, the private keys behind those certificates were integers smaller than 256 — numbers you could guess on a slow afternoon. Within two hours of the report, Chrome and Firefox had blocked them. Apple and Microsoft followed within days. And on 27 October, Chrome finishes the job by ripping the emSign root clean out of its trust store — which will break some legitimate websites too.
We spent this evening cross-checking the timeline across the Mozilla incident report, eMudhra's own statement, Cloudflare's write-up and the Indian government's response. Nobody has found a single forged certificate in the wild. That is the good news. The bad news is what the incident quietly proves about the trust system the whole web runs on — and the cleanup that Go's cryptography maintainer calls "a massive cleanup job, bigger than Heartbleed."
Illustration: the padlock browsers show for HTTPS depends on certificate authorities like eMudhra keeping their private keys secret. Public-domain illustration via Wikimedia Commons (AJ Ashton / Open Clip Art Library).
What a certificate authority key actually is
Every time your browser shows that padlock, a quiet chain of trust is doing the heavy lifting. At the top sits a root certificate authority — a company or organisation whose key is baked into your operating system and browser. The root never touches the web directly. Instead it signs intermediate certificates, and those intermediates sign the certificates websites actually use. Your browser trusts a site because the chain leads back to a root it trusts.
That is why the private keys of intermediates are the crown jewels. Whoever holds one can mint a certificate for any domain on earth — your bank, your email, your government's tax portal — and your browser would accept it without a blink. This is not a theoretical design flaw. It is the documented, intended power of an intermediate CA key, which is why the industry wraps their generation in hardware security modules and ceremony-grade procedure. On Saturday, we learned what happens when the ceremony goes wrong.
A Saturday report, a two-hour response
The timeline reads like an incident-response textbook. An independent researcher discovered on Saturday 17 October that the private keys of eight eMudhra intermediate certificates were recoverable, and reported it to Mozilla's root programme at 20:06 UTC, in a Bugzilla incident report. Dennis Jackson, a Mozilla cryptography engineer who ran the disclosure, wrote that the affected P-384 keys — created on 30 April 2025 — "all used integers less than 256," which lets them be recovered almost instantly. One analysis put it more vividly: each of the eight private keys was a number between 4 and 237.
Let that sit for a moment. The security of the intermediate keys guarding who-knows-how-many websites came down to guessing a number a toddler could count to. A P-384 private key is supposed to be a random 384-bit integer — a number with more possibilities than atoms in the observable universe. These were, in effect, three-digit passwords on the master key ring.
The response was brutally fast. Google's Chrome had the six TLS intermediates blocked through its CRLSet mechanism about an hour and forty minutes after the report landed. Mozilla had Firefox covered through its OneCRL revocation list by 22:59 UTC the same evening — under three hours from report to protection. Apple platforms followed on 19 October, Microsoft on 20 October. For most users, no browser update was needed; the block arrived silently in the background. "Many clients outside of the browser ecosystem do not enforce Certificate Transparency," Jackson's incident page noted dryly — a warning that the fix would not be nearly this clean everywhere else.
How the numbers got so small
eMudhra's own statement, issued from Bengaluru on 21 October, reads like a confession written by engineers who cannot quite believe what their own equipment did. The eight intermediates were created under the company's ECC root in a Key Generation Ceremony on 30 April 2025, inside FIPS 140-2 Level 3 hardware security modules — the tamper-resistant devices that are supposed to make this exact failure impossible. Somewhere in the ceremony, a key wrap/unwrap step produced a second, weak set of keys alongside the original strong ones. And it was the weak keys — the accident — that got published to the browser root stores.
Pause on the absurdity of that. The ceremony produced the strong keys and the broken ones side by side, and the pipeline shipped the broken set. The intermediates then sat in every major browser's trust list for over a year — they had been audited two years running and trusted since mid-2025 — while their private keys were, mathematically speaking, lying in the open. The weakness went undetected for about eighteen months.
eMudhra says its infrastructure was never compromised and no data was breached — the keys were weak, not stolen — and that its Indian digital-signature and eSign businesses run on completely separate infrastructure and are unaffected. The company also notes the researcher reported that the weak keys could be reverse-engineered "possibly with AI-assisted techniques." That is a detail worth filing away: frontier models are now the instrument both attackers and defenders reach for first — the same models whose safety behaviour we have been tracking all month.
New Delhi draws a line between two businesses
The Indian government moved quickly to contain the political blast radius. The Ministry of Electronics and Information Technology emphasised the distinction between eMudhra's domestic digital-signature business — the certificates that underpin India's e-sign and document-signing ecosystem — and its international website-security operation, which it said runs under a global trust framework subject to independent audits, including WebTrust audits by BDO International. "The reported security incident pertains to this only," the ministry said, adding pointedly: "MeitY is not involved in its audit."
That last sentence is doing a lot of work, and it deserves a sceptical read. The ministry is simultaneously claiming the domestic business is untouched and distancing itself from the oversight of the one that failed. A special team has been constituted to investigate, according to a report in the Indian Express. Whether that team asks why an 18-month weakness survived two annual audits — the question everyone outside the ministry is asking — will tell us how serious the inquiry really is.
What breaks on 27 October — and the cleanup nobody sees
The browser blocks were the emergency room. The surgery comes next. Chrome will remove the emSign ECC Root CA – G3 root from its trust store entirely on 27 October 2026 — less than a week from now. When a root is removed, every certificate chaining to it stops being trusted, including perfectly legitimate ones issued under the good intermediates. Site operators chaining to emSign roots have days to reissue. Some will miss it, and some real websites will start throwing certificate errors next Tuesday. That is the collateral damage of distrust, and the root programmes chose it deliberately: you cannot keep trusting a CA whose key custody failed this badly.
Then there is the long tail. Browsers were the easy part — they have revocation machinery built for exactly this. But the same intermediates live in operating-system trust stores, Linux distributions, language runtimes, container base images, embedded devices and application trust bundles, each with its own update cadence. Filippo Valsorda, the Go cryptography maintainer, told Ars Technica the cleanup would be "a massive cleanup job, bigger than Heartbleed." Coming from the person who maintains the cryptography of one of the world's most-used languages, that is not hyperbole. It is a schedule.
Cloudflare, which learned of the compromise around 17:00 UTC on 19 October, has already done its own surgery in public. The company patched its critical services before the public disclosure on 20 October — updating systems that use public certificates to verify remote endpoints, refreshing shared trust stores and base images, restarting services — and pushed mitigations for its CDN and Zero Trust products by 19:20 UTC. Updates for the Cloudflare One client, WARP and the 1.1.1.1 app went live on 20 October at 02:00 UTC. The company found no evidence of exploitation on its services, and was careful to note the issue concerns certificate-based authentication, not the TLS encryption algorithms themselves.
And the one genuinely good piece of news: Certificate Transparency logs — the public, append-only ledgers every publicly trusted certificate must now be logged in — show no entries from these intermediates since they were created in April 2025. As one analysis put it, CT-enforcing browsers could not have been attacked by forged certificates that were never logged. The transparency system the industry built after the last generation of CA failures did its job. The non-browser clients that never enforced it remain the open question.
Our read: the ceremony was the security, and the ceremony failed
Strip away the press statements and eMudhra is the opposite of the PHP2Shell story running alongside it this week. PHP2Shell was a bug nobody knew how to exploit until an AI walked through the gap. The eMudhra failure needed no cleverness at all — just someone to look. The ceremony was the security. The ceremony generated two sets of keys, published the wrong one, and then the auditing regime the industry points to as its answer — two clean years of WebTrust audits — waved the result through for eighteen months.
That is the genuinely frightening part, and it is worth saying plainly: the system that is supposed to catch exactly this kind of failure did not catch it. A browser's padlock is only as honest as the weakest CA in its trust store, and there are dozens of CAs in that store, each with their own ceremonies, their own HSMs, their own auditors. The eMudhra incident is a Q-Day rehearsal — not because quantum computers broke anything, but because it showed how the web behaves when a trust anchor fails suddenly and completely. Browsers moved in two hours. The rest of the stack — the Linux boxes, the runtimes, the embedded devices, the corporate trust bundles — gets to spend months doing what Valsorda calls the bigger-than-Heartbleed cleanup.
There is a second lesson, and it is about the browser makers. Google, Mozilla, Apple and Microsoft did exactly what the system designed them to do: block first, ask questions later, protect the user. But their power to reach into every device and silently rewrite the trust store is also the system's single point of leverage — and it worked this time because the researcher went to them first. The next failure might surface on a forum, or in an exploit kit, before anyone files a Bugzilla report. The eighteen months these keys sat trusted is the number that should haunt the industry, not the two hours the browsers took to kill them.
Were any fake certificates actually used?
None have been found. Certificate Transparency logs show no entries from these intermediates since their creation in April 2025, and Cloudflare found no evidence of exploitation on its services. That does not prove nothing happened outside the logged ecosystem — but it is the best evidence the industry has, and it is reassuring.
Do I need to update my browser?
Probably not. Chrome's CRLSet and Firefox's OneCRL pushed the blocks automatically; Apple and Microsoft handled their platforms. The people who need to act are server operators and developers: check whether any certificate you run chains to the emSign ECC Root CA – G3 root, and reissue it before 27 October.
What happens on 27 October?
Chrome removes the emSign ECC Root CA – G3 root from its trust store. Certificates chaining to it will throw errors in Chrome. If your site or app depends on one, reissue from another CA now — not on the 27th.
The trust-infrastructure beat is one we keep returning to: AI found the PHP2Shell flaws in the language behind 70% of websites, OpenAI's own agents were caught weakening their safety monitoring this month, Palo Alto Networks shed 18% as a zero-day met AI-debt panic, and the full picture of rogue agents, kill switches and what safety means in 2026 is in our explainer.
Sources: Mozilla Bugzilla incident report via Mozilla cryptography engineer Dennis Jackson's disclosure page (report received 17 Oct 2026, 20:06 UTC; P-384 keys "all used integers less than 256"; Firefox OneCRL block 22:59 UTC); Ars Technica via postquantum.com (Filippo Valsorda, Go cryptography maintainer — "a massive cleanup job, bigger than Heartbleed"); eMudhra press release, Bengaluru, 21 Oct 2026 (8 intermediates; 30 April 2025 Key Generation Ceremony; key wrap/unwrap flaw; no infrastructure compromise; Indian DSC/eSign unaffected); YourStory (MeitY statement via Indian Express — domestic vs global TLS business distinction; special investigation team); Cloudflare blog via Moneycontrol/WebProNews (learned ~17:00 UTC 19 Oct; no exploitation evidence on its services; patch timelines); Certera (Chrome CRLSet block ~1h40m; emSign ECC Root CA – G3 removal from Chrome 27 Oct 2026; 6 TLS + 2 code-signing intermediates); WebProNews (Apple 19 Oct, Microsoft 20 Oct; CT log findings). No forged certificates have been found in the wild as of publication.
eMudhra fallout: the questions everyone is asking
Who found the weak keys? A researcher known only as "Wayne" reported them on October 17, proving the break by signing a message with the recovered keys. Mozilla independently re-derived the keys in under two hours.
Why did eMudhra generate keys as small as the number 4? eMudhra told Mozilla's public incident record that a flaw in its key-ceremony script created a second, weak key pair on the HSM during a key-wrapping test; the weak keys carried labels similar to the intended ones, and human error compounded the failure at multiple steps.
Was anyone actually attacked? No confirmed abuse as of October 21. Google found zero TLS certificates from the six affected intermediates in Certificate Transparency logs before blocking them — but the keys were recoverable for roughly 17 months, since the April 30, 2025 ceremony.
What happens on October 27? Chrome's removal of the emSign ECC Root CA – G3 reaches all devices; about 30,000 certificates chain to that root (roughly 97% issued via ACME), and sites that haven't migrated will break in Chrome. Mozilla already removed the root on October 20; Apple blocked the intermediates on October 19 and Microsoft on October 20.
Update, Oct. 22
eMudhra's shares crashed 20% after the browsers moved to distrust its certificates (NDTV Profit). The researcher's handle is "Wayne"; Mozilla re-derived the weak keys on its own in under two hours. eMudhra's explanation, filed in Mozilla's public incident record: a flaw in its key-ceremony script generated a second, weak key pair on the HSM during a key-wrapping test, the weak keys carried labels similar to the real ones, and human error compounded the failure at multiple steps. Mozilla removed the emSign ECC Root CA – G3 root from its trust store on October 20; Chrome's removal lands on all devices October 27. Google says it is "closely investigating whether eMudhra's remaining CA certificates should stay in the Chrome Root Store." The keys were recoverable for roughly 17 months — no confirmed abuse, but about 30,000 certificates chain to the root Chrome is about to drop.
Comments
Post a Comment