Technology / A private key is supposed to be the one secret the whole secure web rests on — a number so large and so random that no computer on Earth could guess it. Eight certificate-signing keys belonging to eMudhra, the Indian certificate authority behind the emSign brand, turned out to be numbers smaller than 256. One, an expert told businessline, was literally the number 4. Browsers blocked the keys within hours, India's CERT-In issued advisory CIAD-2026-0050 on October 21, the stock fell more than 20 percent in a day — and on October 27 Chrome removes the emSign root altogether.
The eMudhra certificate keys compromised story is, at its core, a story about how the eMudhra weak certificate keys were made. According to CERT-In, the eight intermediate certificate authority (CA) keys were generated in April 2025 with insufficient cryptographic randomness, so the resulting P-384 elliptic-curve private keys had exceptionally small values — all of them below 256 — and could be recovered almost instantly from their own public keys. CERT-In stressed that the P-384 algorithm itself is not weak; the failure was in the key-generation process. Six of the intermediates could sign TLS website certificates and two could sign code, which means whoever recovered those keys could, in principle, have minted a trusted certificate for a website they did not own, or made malicious software look as if a trusted publisher had signed it.
What happened, and when
The flaw surfaced on October 17, 2026, when researcher Dennis Jackson reported the weak keys on Mozilla's Bugzilla tracker and demonstrated that they could be recovered — in his account, AI agents he tested recovered a key on the first attempt when prompted as if solving a capture-the-flag puzzle, and Mozilla independently recovered the keys within hours without knowing his method. The response moved at the speed the risk demanded. Chrome blocked the six TLS intermediates through its CRLSet revocation mechanism on October 17, and Mozilla blocked them in Firefox through OneCRL the same day. eMudhra revoked all eight intermediates on October 18, according to CERT-In's summary of the incident. Apple followed with its own block on October 19 and Microsoft on October 20.
On October 21 the public institutions caught up with the browser engineers. CERT-In published advisory CIAD-2026-0050, warning that an attacker able to exploit the compromised TLS keys could issue fraudulent certificates, impersonate legitimate websites and intercept or modify traffic — potentially enabling credential theft, sensitive-data exposure and financial fraud — and that the compromised code-signing keys could make malicious software appear to come from a trusted publisher. India's Ministry of Electronics and Information Technology (MeitY) said it had taken serious note, formed a special team to investigate, and assessed the impact on Indian websites and applications as limited and confined to a very short interval. eMudhra's shares nevertheless fell more than 20 percent on Wednesday, October 21, hitting the lower circuit in Mumbai trading.
eMudhra, a Bengaluru-based, publicly listed company and one of India's 14 licensed certifying authorities, attributed the incident to human errors at multiple stages of a key-generation ceremony and said it would reverify every key ceremony it had conducted. Its account of the blast radius is narrow, and it is important to keep it labelled as the company's account: only one of the eight intermediates was deployed in production, none of the eight issued any end-entity certificate, its root CA keys and other intermediates were not compromised, no infrastructure was breached and no data was taken. Public Certificate Transparency logs — the open ledgers where issued certificates are recorded — have so far supported the claim that no fraudulent certificates appeared before the blocks, and CERT-In recorded no confirmed malicious use of the keys in the public disclosures as of October 21.
Why this matters
It matters because a certificate authority sells exactly one product: trust that cannot be checked by the buyer. When you see a padlock in a browser, you are not checking anything yourself — you are outsourcing the check to a chain that runs from your browser's root store, through an intermediate CA, to the certificate on the site in front of you. That system works only if every private key in the chain is genuinely secret. A key with the value 4 is not a weakened lock; it is a lock whose combination is printed on the door. Yash Kadakia, CTO of Security Brigade, put the scale question plainly to businessline: eMudhra had eight certificate-signing keys that were supposed to be difficult and random to guess, one was literally the number 4, and how many systems around the world trusted those keys is what will decide the impact.
The second reason it matters is the calendar. Blocking an intermediate is an emergency brake; removing a root is a sentence. Google has said Chrome will remove the emSign ECC Root CA - G3 from the Chrome Root Store, with the change expected to reach devices from October 27, 2026, and the Internet Freedom Foundation notes Mozilla has already removed the same root from its trust store. Every legitimate certificate that chains to that root then stops validating in the world's dominant browser until its operator replaces it. The cure and the disruption are the same event: the system protects users by breaking, on a fixed date, a slice of the web that did nothing wrong except buy certificates from the wrong hierarchy.
And it matters because of the long tail, which is where CA incidents actually live. Browsers updated in hours, but browsers are the easy part. Filippo Valsorda, a cryptography engineer and maintainer, warned in remarks reported by Ars Technica that the tail runs through IoT devices, Docker containers, forgotten Linux machines and command-line tools that ship their own copy of the root store — Python ecosystems among them — while Linux distributions were still rolling out updates that administrators then have to apply machine by machine. A compromised intermediate stays dangerous exactly as long as the slowest, least-maintained device that still trusts it. That is why several experts have compared the cleanup's scale, if not its cause, to Heartbleed: not because the flaw is similar, but because the remediation is a census of everything on the internet that nobody has patched in years.
The numbers in context
Start with the smallest number in the story: 256. A correctly generated P-384 private key is a number drawn from a space of roughly 2 to the power of 384 possibilities — a space so large that brute force is a physical impossibility, not merely an inconvenience. These eight keys sat inside the first 256 integers. The search space collapsed from astronomical to something a person could enumerate by hand, which is why recovery took seconds and why an AI agent handed a puzzle-style prompt could do it on the first try. This was not a subtle cryptographic weakness at the edge of feasibility; it was the near-total absence of the randomness that is the entire security argument.
Then consider the exposure arithmetic. Eight intermediates, six for TLS and two for code signing, trusted — before the blocks — by the Chrome, Mozilla, Microsoft and Apple root programmes in the TLS case, and by Microsoft for code signing. Against that, the mitigating numbers are real and should not be waved away: one of eight in production, zero end-entity certificates issued according to the company, zero fraudulent certificates found in Certificate Transparency logs, and zero confirmed malicious use in public disclosures as of the CERT-In advisory. The honest summary is a worst-case capability that was, on current evidence, never used — discovered, on current evidence, before an attacker used it. Both halves of that sentence matter, and the second half is only as strong as the logs and disclosures behind it, which is why the IFF has pressed CERT-In on whether it independently checked the company's claims or relayed them.
The commercial numbers tell a different asymmetry. eMudhra says the affected global TLS business is about 1 percent of revenue — a rounding error in the accounts — yet the stock lost more than a fifth of its value in a single session, and the company itself warned of reputational risk that, in its own words, cannot be quantified. That gap between 1 percent of revenue and 20 percent of market value is the market pricing the actual product correctly: a CA's franchise is not its certificate volume, it is the presumption that its ceremonies are flawless. Audits that missed weak keys for roughly 18 months — the keys were generated in April 2025 — are now the central question. As Praveen Babu C of SPR Consultech told businessline, when weak keys pass through issuance and cross-signing, it raises questions about the effectiveness of independent security validation itself. MeitY, for its part, has noted the global TLS business is governed by global standards and independent WebTrust audits in which the ministry is not involved.
Who gains, who loses — and what critics say
The losers are clearest at the edges. Website operators holding certificates that chain to the emSign ECC root face a hard October 27 deadline in Chrome whether or not they ever touched the eight bad intermediates — replacement certificates, redeployment, and testing, on a timetable set by someone else's failure. eMudhra's competitors gain the obvious opening: every rival CA in India and globally can now sell the one claim eMudhra temporarily cannot, an unblemished ceremony record. Browser root programmes gain leverage, and arguably vindication: their ability to distrust a CA quickly, unilaterally and publicly is the enforcement mechanism the whole Web PKI relies on, and it worked here in hours.
Critics split in two directions, and both deserve airing. One camp — including the Internet Freedom Foundation, which has written to MeitY, CERT-In and the Controller of Certifying Authorities (CCA) — argues the Indian state's response was slow and thin: CERT-In's advisory arrived on October 21, four days after the researcher went to the browsers, the CCA had issued no public statement at the time of the IFF's writing, and the advisory relays eMudhra's no-issuance account without stating whether it was independently verified. MeitY's October 22 pushback — that some social-media accounts were indulging in fear-mongering and that the CCA-regulated Indian business remains completely unaffected — answers the panic, but not the verification question. The other camp warns against over-correction: researchers and practitioners quoted in Indian coverage argue the failure was carelessness in one key-generation ceremony rather than proof of a systemic Indian CA problem, and that heavy-handed government intervention in the Web PKI could erode trust in India's CA ecosystem further than the incident itself has. Both can be partly right: a single ceremony can be a single company's failure and still expose a supervisory gap, because supervision exists precisely for the day a ceremony fails.
The scope line everyone official agrees on should be stated plainly, because readers in India will ask it first: eMudhra's Indian digital signature certificate (DSC) and eSign services — the regulated domestic business used for filings and signatures — are, on MeitY's and the company's statements, not affected by this incident, which sits entirely in the company's international public-trust business. No statement in the record contradicts that separation, and this article treats it as the current official position, not as an independently audited fact.
What users and website owners should do
For ordinary users, CERT-In's advice is short and worth following exactly: update your browser, operating system and trust stores, and never bypass a certificate warning. The modern browser on your phone or laptop has, in all likelihood, already blocked these intermediates; the risk concentrates in old devices and outdated systems that do not refresh their trust lists — one more reason the dusty tablet in a drawer should not be the device you bank on. A test site published by the researcher lets a visitor check whether their browser still trusts certificates issued with the compromised keys; a browser that refuses the test connection has already been fixed.
For website owners and administrators, the work is a search, not a guess. Inventory every certificate in your estate — including the ones in containers, appliances, Java runtimes and embedded systems that keep their own CA bundles — and replace any certificate that chains to the affected intermediates or to the emSign ECC Root CA - G3 before Chrome's removal lands around October 27. Review code-signing chains as well, since two of the eight keys were code-signing keys, and watch Certificate Transparency logs for your domains so that a fraudulent issuance, if one ever appears, is spotted by you rather than by a researcher. Vendors should add integrity and provenance checks beyond the signature alone. And CAs watching this unfold have been handed their checklist by CERT-In itself: approved random-number generators, proper hardware security module controls, and independent maker-and-checker verification of every generated key — the controls whose absence, or failure, is the only way a key ceremony ends with the number 4.
What happens next
Three scenarios now run in parallel. In the contained scenario — currently the one the evidence supports — MeitY's special team confirms the narrow blast radius, no fraudulent certificates surface in the transparency logs, operators replace root-chained certificates ahead of October 27 with only scattered breakage, and the story becomes an audit-reform story: WebTrust and root-programme reviews tighten key-ceremony verification, and eMudhra spends quarters, not weeks, earning back a presumption it lost in a day. In the messy-middle scenario, the root removal and the long tail do the damage instead: legitimate sites fail in Chrome on October 27 because a certificate three layers down a chain nobody documented still points at the emSign root, embedded and IoT fleets trust the bad intermediates for months, and the incident's cost is paid in a thousand small outages rather than one big breach. In the adverse scenario — for which there is currently no public evidence — a fraudulent certificate or a signed malicious binary surfaces that predates the October 17 blocks, converting a near-miss into an active-compromise investigation and putting every other key ceremony eMudhra has run, which the company says it is reverifying this week, under a microscope. The single most informative event in the next ten days is boring on its face: what, if anything, appears in the Certificate Transparency logs, and whether the reverification of past ceremonies reports clean. Until then, the fairest verdict is the uncomfortable one — the system caught this, and it caught it by luck, speed and one researcher's curiosity, not by the audits that were supposed to make catching it unnecessary.
Sources
Sources: CERT-In advisory CIAD-2026-0050 (October 21, 2026); The Hindu businessline — eMudhra's flawed certificate triggers CERT-In probe (October 21–22, 2026); MediaNama — eMudhra security flaw explained (updated October 22, 2026); The Hacker News — Eight eMudhra CA keys compromised; Livemint — eMudhra intermediate CA certificates compromised, explained; Internet Freedom Foundation — A private key with the value 4; Mozilla Bugzilla incident record and eMudhra's October 21 statement, as reported by MediaNama and businessline.
Related
Related on Signal Post News: PHP2Shell: the critical PHP flaw that forced an emergency patch · When hackers send AI agents to do the breaking in · Cohere buys Aisle as AI cybersecurity consolidates