--- title: "eMudhra's private key was the number 4. Chrome blocked it in 100 minutes" summary: "How a CA key below 256 ended emSign ECC Root CA – G3 in October 2026: the trust-store clock from 100 minutes to ten days, what is unaffected in India, and the inventory CERT-In asks for." url: https://www.thetechbag.com/blog/emudhra-root-distrusted-in-100-minutes format: Analysis desk: "Security operations" published: 2026-10-28 facts_checked: 2026-10-28 author: TechBag (The TechBag Journal) tags: ["eMudhra","PKI","certificate authority","TLS","CERT-In","MeitY","trust stores","code signing","DSC","eSign"] cover: https://www.thetechbag.com/blog/covers/emudhra-root-distrusted-in-100-minutes.png --- # eMudhra's private key was the number 4. Chrome blocked it in 100 minutes *How a CA key below 256 ended emSign ECC Root CA – G3 in October 2026: the trust-store clock from 100 minutes to ten days, what is unaffected in India, and the inventory CERT-In asks for.* Analysis · Security operations · By TechBag · Published 2026-10-28 · Facts checked 2026-10-28 · Canonical: https://www.thetechbag.com/blog/emudhra-root-distrusted-in-100-minutes The short version - Eight eMudhra intermediate certificate authorities, signed under **emSign ECC Root CA – G3**, had private keys below 256. One was the number 4. Anyone with the public certificate could recover the key in under a second.[4] - Chrome blocked the TLS intermediates 100 minutes after the report, Firefox in 294; eMudhra revoked them the next day, the root was distrusted, and on 22 October the company announced it was leaving publicly trusted TLS altogether.[3] - Indian DSC, eSign and the GST, MCA and income-tax filings that ride on them are on separate, CCA-regulated hierarchies and are unaffected, per eMudhra and MeitY. The work left for an Indian IT team is an inventory: every runtime, container image and appliance that still trusts the G3 root.[2] The question an Indian buyer is really asking after the eMudhra incident is not “was I hacked?” Nobody has shown that anyone was. CERT-In’s advisory of 21 October says the public disclosures “do not establish confirmed malicious exploitation of the affected keys”.[2] The question is whether a thing you never bought, a publicly trusted TLS certificate from an Indian CA, is nonetheless sitting in a trust store you depend on, and whether the argument for buying Indian PKI on sovereignty grounds survives a week in which the arithmetic failed and the browsers, not the regulator, caught it. ## A root, an intermediate, and a number that should have had more than 100 digits Every HTTPS connection rests on a chain of three signatures. A **root** certificate ships inside your browser or operating system; you trust it because the vendor put it there. The root signs an **intermediate**, which does the daily work. The intermediate signs the certificate for a website, or for a piece of software. At each link, the signature is produced with a**private key** that only the CA is supposed to hold, and verified with the public key printed in the certificate. The entire value of the chain is that the private key cannot be worked out from the public one. For the P-384 curve eMudhra used, a private key should be a random whole number more than 100 digits long.[4] The eight eMudhra intermediates had private keys of 4, 56, 115 and the like, every one below 256; the certificate named` EM OV TLS CA - G3C` had the key 4.[5] Scott Helme recovered all eight from the public certificates in “less than a second”, and a researcher published one on GitHub.[4] Nothing was stolen. The key had been effectively public since the day the certificate existed in April 2025. 4 The private key of EM OV TLS CA - G3C, a publicly trusted intermediate A P-384 key should be a random number more than 100 digits long.[5] **Figure: A weak intermediate key lets a stranger sign as the CA for any domain, with no break-in required** *The three-link certificate chain and what a 256-guess private key does to it, as of October 2026* 1. 01RootemSign ECC Root CA – G3, shipped inside browsers, operating systems and CA bundles. Trusted because the vendor included it. 2. 02IntermediateOne of 24 CAs generated on 30 April 2025 and signed by the root. Eight carried a private key below 256. 3. 03Site or code certificateSigned by the intermediate. A browser accepts it because the chain back to a trusted root verifies. 4. 04What the weak key allowsAnyone recomputes the key, mints a certificate for any domain or signs malware, and every device trusting the root accepts it. Source: CERT-In CIAD-2026-0050; Help Net Security; BleepingComputer · as of 21 October 2026 The attack this enables is impersonation. With an intermediate’s key you issue yourself a certificate for a bank’s domain, stand between a user and that bank, and the padlock still shows. With a code-signing intermediate you sign an installer and Windows calls it trusted. CERT-In spells out both consequences in its advisory.[2] ## Eight of 24 keys were weak, one was in production, none had issued a certificate The scope is narrower than the headlines and wider than eMudhra’s first statement. At a key generation ceremony on 30 April 2025 eMudhra created 24 intermediate CAs; eight of them, six for TLS and two for code signing, came out with the weak keys, and Sectigo cross-signed all eight in May 2025.[4] By eMudhra’s account only one of the eight was ever in production and none issued an end-entity certificate, which Certificate Transparency records corroborate: Chrome found no TLS certificate chaining to the six TLS intermediates logged before its block.[1][3] **Figure: The failure was a third of one ceremony, caught before it issued anything** *Intermediate CAs from eMudhra's 30 April 2025 key generation ceremony, by status, October 2026* Generated at the ceremony 24 intermediate CAs With a weak private key every key below 256 8 intermediate CAs Of which TLS 6 intermediate CAs Of which code signing 2 intermediate CAs Ever in production 1 intermediate CAs End-entity certificates issued 0 intermediate CAs | | Value (intermediate CAs) | | --- | --- | | Generated at the ceremony | 24 | | With a weak private key | 8 | | Of which TLS | 6 | | Of which code signing | 2 | | Ever in production | 1 | | End-entity certificates issued | 0 | Source: Help Net Security (24, 6 + 2); eMudhra incident statement, Update 3 (1 in production, 0 issued); Chrome CT check via The Hacker News · as of 21 October 2026 · Counts are eMudhra's own and the trade press's; the 24 is not stated on eMudhra's page ReportedeMudhra’s two explanations, in its own words Update 3, 21 October: “During the ceremony, a key wrap/unwrap step produced a second, weak set of keys alongside the original strong keys”, and “we have not yet confirmed the exact root cause.” Update 5, 26 October: “A script error resulted in issuing CA’s with weak keys.” The strong keys stayed in the hardware security module; the weak set, carrying similar labels, was the one published to root stores. The company says the hierarchy “passed two independent audit cycles” in the roughly 18 months the keys went unnoticed.[1] Hold the two wordings side by side. A wrap/unwrap defect and a script error are different failures with different fixes, and the company has promised a root-cause analysis through the CCADB process rather than reconciling them yet.[1] The governance point is the one that should worry a buyer of any CA, Indian or not: a WebTrust audit checks that a ceremony was followed and witnessed. It does not recompute the key. Two audit cycles passed a private key of 4. ## Browsers had a kill-switch: 100 minutes for Chrome, ten days for the root The response clock is the most instructive thing about the incident, because it shows which parts of the internet can be fixed centrally and which cannot. The Chrome Root Program received the report at 18:05 UTC on 17 October and had a CRLSet update blocking the six TLS intermediates in place at 19:45. Mozilla received the forwarded report at 20:06 and finished pushing a OneCRL block to standard Firefox installations at 22:59.[3] eMudhra revoked the eight on 18 October, “within 14 hours” of confirming the problem.[1] **Figure: The browsers were safe before eMudhra had revoked anything; everything else took days** *Each block or fix after the researcher's report at 18:05 UTC, 17 to 27 October 2026* | Date | Event | Detail | | --- | --- | --- | | 17 Oct 2026 | Report reaches Chrome | 18:05 UTC; forwarded to Mozilla at 20:06 | | 17 Oct 2026 | Chrome blocks, 100 min | CRLSet update, 19:45 UTC | | 17 Oct 2026 | Firefox blocks, 294 min | OneCRL push, 22:59 UTC | | 18 Oct 2026 | eMudhra revokes the eight | within 14 hours of confirmation | | 19 Oct 2026 | Apple and Android | Apple trust store; Android via Play Services about 22:00 UTC | | 20 Oct 2026 | Microsoft and Go | Microsoft trust store; Go 1.27.3 and 1.26.10, binaries must be rebuilt | | 21 Oct 2026 | Node.js releases | Node.js 26, 24 and 22 | | 27 Oct 2026 | Chrome drops the G3 root | expected on devices | Source: The Hacker News timeline (Chrome, Mozilla, Apple, Android, Microsoft, Go, Node.js, Chrome root removal); eMudhra Update 5 (revocation) · as of 27 October 2026 · Chrome and Firefox are exact to the minute; the revocation, Apple, Microsoft, Go, Node.js and the root removal are published as dates only, so their position within the day is approximate CRLSet and OneCRL are lists of blocked certificates that Chrome and Firefox fetch on their own schedule, independently of any website or CA. That is why a browser can be made safe in an evening. Apple followed on 19 October, Microsoft on 20 October, and by 20 October Mozilla had removed emSign ECC Root CA – G3 from NSS 3.131.1 outright, with Chrome’s own removal of the root expected to reach devices on 27 October and a review of emSign Root CA – G1 under way.[3] On 22 October eMudhra announced a voluntary wind-down of publicly trusted TLS, a business its press release put at around 1% of revenue.[3] ## The long tail does not have a kill-switch, and it is your inventory Everything that is not a browser trusts whatever root list it shipped with, and much of it never checks revocation at all. Go binaries carry their own trust logic and needed a new compiler release and a rebuild; Go 1.25 and older are out of support and get no fix. Python programs using the `certifi` bundle, Node.js, Java keystores, container base images, VPN concentrators, load balancers, payment terminals and anything embedded keep trusting a chain until their code or their bundled roots change.[3] CERT-In’s advisory names exactly this class: systems that “maintain separate CA certificate bundles or do not reliably check certificate revocation”.[2] **Figure: Browsers fixed themselves in hours; your appliances and runtimes will trust the G3 root until you change them** *How the two halves of the trust ecosystem respond to a compromised CA, October 2026* Browsers: central kill-switch - Chrome CRLSet and Firefox OneCRL push blocks without any site or CA acting - Blocked within 100 and 294 minutes of the report - Root removal follows in the next release: NSS 3.131.1, Chrome root store 43 - Certificate Transparency lets the vendor prove nothing was issued Runtimes and appliances: the long tail - Go needed a compiler release and a rebuild; Go 1.25 and older get nothing - certifi, Node.js and Java bundles update only when you update them - Network appliances and embedded devices rarely check revocation - Cross-signed paths via Sectigo reach the same weak keys by another route Source: The Hacker News; CERT-In CIAD-2026-0050 recommendations 2, 3 and 7 · as of 21 October 2026 So the job for an Indian IT team is the one CERT-In sets out in its ten recommendations: identify every certificate that chains to the eight intermediates or to emSign ECC Root CA – G3, including cross-signed chains; replace legitimate certificates under that root with ones from an unaffected hierarchy; update the CA bundles in applications, runtimes, container images, TLS libraries, network appliances and embedded systems, and redeploy where a bundle is baked in; verify code-signing trust separately; and monitor Certificate Transparency, which the advisory says “should supplement, rather than replace, certificate revocation and trust-store controls”.[2] Note the order. Replacement and bundle updates come first; CT monitoring is the alarm, not the lock. TechBag countTechBag count TechBag maintains six eMudhra pages: the vendor hub and five products, DSC, emSigner, SecurePass, CertiNext and emCA. None of them covers publicly trusted TLS; the business that failed was the one Indian buyers had never asked us to catalogue. Across the estate, two product pages are built around discovering and rotating certificates at scale, Entrust Certificate Lifecycle and CyberArk Machine Identity Security, which is the shelf this inventory job sends a buyer to.[7] ## What this does to the sovereignty argument for Indian PKI The case for buying certificates from an Indian CA has always rested on two legs: regulatory reach, because the Controller of Certifying Authorities licenses and audits it under the IT Act, and resilience, because a foreign root program cannot switch off your trust. This week tested both. The CCA’s reach stops at DSC and eSign; eMudhra’s global TLS business sat outside it, and MeitY officials said plainly that the ministry “is not involved in its audit”.[6] And the foreign root programs did switch off the trust, in 100 minutes, which is exactly what you want them to do when a key is 4. **Figure: A business worth 1% of revenue cost 20% of the share price in a day and the whole root** *The incident in eMudhra's and the market's own numbers, 21 to 28 October 2026* ~1% Share of eMudhra revenue from global TLS, per its press release The Hacker News, 21 Oct 2026 20% One-day fall in eMudhra shares in Mumbai, 21 October Business Standard via The Hacker News ~30,800 Certificates under the G3 hierarchies for one US client ecosystem, moved to the G1 RSA root eMudhra Update 6, 28 Oct 2026 18 months The weak keys went unnoticed, through two independent audit cycles eMudhra Update 3, 21 Oct 2026 Source: eMudhra press release via The Hacker News (1%); Business Standard via The Hacker News (20%); eMudhra Update 6 (30,800); eMudhra Update 3 (18 months) · as of 28 October 2026 · The 20% fall is cited at second hand; the 30,800 is eMudhra's own figure and sits unreconciled with its statement that the eight intermediates issued nothing Our view Our view: sovereignty was never the right reason to pick a public CA, and this incident does not make it one. A publicly trusted root is trusted at the pleasure of five root programs, none of them Indian, and that is a feature. Buy Indian where the regulator genuinely governs the product, which is DSC and eSign under the CCA, and judge a public TLS or code-signing CA on its incident record, its audit depth and how fast it revoked. On that last measure eMudhra did well: 14 hours. On the first two it did not, and it has left the market rather than argue. The one place sovereignty does hold is private PKI, where you own the root and the ceremony; the HSM and lifecycle tools on our estate are that shelf. The second thing the week changes is how a buyer should read any CA’s audit letter. eMudhra’s own promise is a full root-cause analysis through the CCADB process explaining “why our controls failed to detect it”, and an independent expert review.[1] Until a CA’s audit includes an arithmetic check of the keys it publishes, treat the audit as evidence of process and the Certificate Transparency logs as evidence of behaviour. If you are buying this in India **Unaffected:** every Digital Signature Certificate and eSign transaction, and so every GST return, MCA filing, income-tax return and tender signed with one. eMudhra’s statement says digital signature, eSign, emSigner, CertiNext, emCA, PrivaTrust and SecurePass “are not affected”; CERT-In’s advisory of 21 October 2026 records that the DSC and eSign services regulated by the CCA under MeitY were not affected; and MeitY, which constituted a special investigation team the same day, called the impact on Indian websites and applications “very limited and for a very short period”.[1][2][6] Those are the vendor’s and the ministry’s statements, not an independent audit, and MeitY has said more will follow once its inquiry is complete. **Affected, possibly:** any Indian enterprise that bought a publicly trusted TLS or code-signing certificate from eMudhra under the G3 hierarchies, and any team whose internal systems chain to that root. eMudhra says the “vast majority” of its remaining TLS customers have been moved to alternate providers at no charge and offers Sectigo-issued certificates as the alternate; the replacement certificate costs you ₹0, and the real cost is the inventory.[1] Budget the people, not the certificate. If a paid replacement from another CA is needed, TechBag quotes it in INR with 18% GST. **Obligations:** CERT-In CIAD-2026-0050 is an advisory, not a direction, but its ten recommendations are what an auditor will ask about next quarter; and eMudhra’s own disclosure went to the stock exchange on 21 October as a listed-company event.[3] We make no claim that any SEBI or CSCRF obligation was breached; nothing published says so. How we did this Figures as of 28 October 2026 Scope, production and issuance counts, the revocation timing, both root-cause wordings, the audit-cycle statement, the 30,800 figure and the list of unaffected services are quoted from eMudhra’s own incident page, Updates 1 to 6 (20 to 28 October 2026). The 24 intermediates, the 6 + 2 split, the key values and the Sectigo cross-signing are from Help Net Security (21 October); the name of the certificate whose key was 4 is from BleepingComputer (20 October). The response clock is The Hacker News’s timeline, with hours computed by TechBag from 18:05 UTC on 17 October; where a source gives a date and no hour we plotted midday and say so in the figure note. Two sources put Apple’s block on 19 October and one on 22 October; we used 19. The 1% revenue and 20% share-fall figures are cited at second hand through The Hacker News; Reuters and Business Standard were not fetched. The MeitY statements are from The Print and the government’s News on AIR (21 and 22 October). A figure for test certificates issued after disclosure that appears in one search summary could not be confirmed in any fetched source and is omitted. Whether any Indian government site used a G3-chained certificate is unknown; we do not infer it. The estate count is TechBag’s own. Spotted an error? Write to us; corrections are published at the foot of the piece. Sources 1. [eMudhra, Certificate Security Incident statement, Updates 1 to 6](https://emudhra.com/en/post/certificate-security-incident) — 20 to 28 October 2026 2. [CERT-In, CIAD-2026-0050: Compromise of eMudhra Intermediate CA Certificates](https://www.cert-in.org.in/s2cMainServlet?pageid=PUBVLNOTES02&VLCODE=CIAD-2026-0050) — 21 October 2026 3. [The Hacker News, Eight eMudhra CA keys compromised: response timeline, CT finding, MeitY, 1% of revenue, 20% share fall](https://thehackernews.com/2026/10/eight-emudhra-ca-keys-compromised.html) — 20 to 21 October 2026 Business Standard and the eMudhra BSE press release are cited through this article. 4. [Help Net Security, eMudhra certificates' private keys compromised: 24 intermediates, key values, Sectigo cross-signing](https://www.helpnetsecurity.com/2026/10/21/emudhra-certificates-private-keys-compromised/) — 21 October 2026 5. [BleepingComputer, Mozilla, Google, Apple block compromised eMudhra CA certificates (EM OV TLS CA - G3C key of 4)](https://www.bleepingcomputer.com/news/security/mozilla-google-apple-block-compromised-emudhra-ca-certificates/) — 20 October 2026 6. [The Print, MeitY sets up team to probe eMudhra certificate breach; News on AIR, MeitY says impact very limited](https://theprint.in/tech/meity-sets-up-team-to-probe-emudhra-certificate-breach-says-digital-signature-services-unaffected/3078125/) — 21 to 22 October 2026 7. [TechBag estate: eMudhra vendor hub and product pages; Entrust and CyberArk certificate-lifecycle pages](https://www.thetechbag.com/emudhra) — counted 28 October 2026 Related on TechBag: the [eMudhra hub](https://www.thetechbag.com/emudhra) covers the CCA-regulated products this incident did not touch; the [Entrust Certificate Lifecycle page](https://www.thetechbag.com/entrust/entrust-certificate-lifecycle) and the [Thales Luna HSM page](https://www.thetechbag.com/thales/thales-luna-hsm) are the discovery and custody tools for the inventory and the private-PKI route. **Disclosure.** TechBag is a software reseller: it earns a margin when a reader buys through it, including from vendors named here. The analysis is TechBag’s own; no vendor paid for or saw this piece before publication. Facts are labelled reported, TechBag count or our view. Go deeper on TechBag - [eMudhra vendor hub: DSC, emSigner, SecurePass, CertiNext, emCA](https://www.thetechbag.com/emudhra) — the CCA-regulated products the incident did not touch - [Entrust Certificate Lifecycle](https://www.thetechbag.com/entrust/entrust-certificate-lifecycle) — discover every certificate chain, then replace at scale - [Thales Luna HSM](https://www.thetechbag.com/thales/thales-luna-hsm) — key custody for a private PKI you own the root of