eMudhra's private key was the number 4. Chrome blocked it in 100 minutes

01A 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.⁴ 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.⁵ Scott Helme recovered all eight from the public certificates in “less than a second”, and a researcher published one on GitHub.⁴ Nothing was stolen. The key had been effectively public since the day the certificate existed in April 2025.

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.²

02Eight 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.⁴ 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.¹³

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.¹ 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.

03Browsers 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.³ eMudhra revoked the eight on 18 October, “within 14 hours” of confirming the problem.¹

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.³ On 22 October eMudhra announced a voluntary wind-down of publicly trusted TLS, a business its press release put at around 1% of revenue.³

04The 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.³ CERT-In’s advisory names exactly this class: systems that “maintain separate CA certificate bundles or do not reliably check certificate revocation”.²

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”.² Note the order. Replacement and bundle updates come first; CT monitoring is the alarm, not the lock.

05What 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”.⁶ 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.

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.¹ 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.