eMudhra CA compromise: the 27 October Chrome cutoff

The eMudhra CA compromise did not involve a theft. Eight intermediate CA private keys were generated with so little randomness that, per Google, "anyone can compute them from the public certificates" — the keys were effectively published alongside the certificates in 2025. The operational deadline arrives this week: Chrome's removal of the affected root is expected to reach devices on the morning of Tuesday 27 October, Pacific time, and any site whose certificate chains to it stops being trusted when that lands.

If you hold a certificate issued under the emSign brand, this is a four-day problem, not a reading exercise. Here is what actually happened, what breaks, and the two details in Node.js's response that are worth understanding even if you have never bought an eMudhra certificate.

What the eMudhra CA compromise actually was

A researcher reported it to the root programs on the evening of 17 October 2026. Reporting on the incident gives a timeline that is, to be fair to everyone involved, extremely fast: Chrome received the report at 18:05 UTC and had a CRLSet block in place by 19:45 UTC; Mozilla received it at 20:06 UTC and pushed a OneCRL block by 22:59 UTC.

eMudhra said on 21 October that a flaw in its April 2025 key ceremony "produced a second, weak set of keys alongside the intended ones", and that the weak set is what went to the root stores. That is the whole mechanism. No intrusion, no stolen HSM — a randomness failure during key generation, which means the private keys were derivable by anyone who bothered to look for eighteen months.

Eight certificates are affected: EM DV TLS CA G3B and G3C, EM OV TLS CA G3B and G3C, EM EV TLS CA G3B and G3C, and the code-signing pair EM OV CS CA G3B and G3C. The six TLS intermediates chain to emSign Root TLS CA - G3, which chains to emSign ECC Root CA - G3.

On the question everyone asks first — was it abused? No mis-issued certificates have been reported. No TLS certificate chaining to the six intermediates had been logged to Certificate Transparency before Chrome's block, and eMudhra states "There were no end entity certificates issued out of the affected CA's." But the honest caveat is in the reporting: "Whether anyone exploited the flaw since the certificates were created is not known", and CT only covers certificates that were logged.

The 27 October cutoff, and what it breaks

Distrust is arriving in two waves, and the second one is the one that breaks working sites.

Program	Action	When
Chrome	CRLSet block of the six TLS intermediates	17 Oct, 19:45 UTC
Mozilla	OneCRL block, then emSign ECC Root CA - G3 removed in NSS 3.131.1	17 Oct, then 20 Oct
Apple	Blocked	19 Oct
Android	Google Play Services block	19 Oct, ~22:00 UTC
Microsoft	Blocked	20 Oct
Go	1.27.3 and 1.26.10 reject the eight keys (CVE-2026-111943)	20 Oct
Node.js	26.12.1, 24.22.1, 22.23.4 reject the eight keys	21 Oct
Chrome root store 43	Removes emSign ECC Root CA - G3 entirely	expected ~27 Oct

The first wave blocks eight specific intermediates, which by all accounts signed nothing in the wild. The second wave removes the root, and that is indiscriminate: as the reporting puts it about the distribution bundles doing the same thing, "That also cuts off every legitimate certificate that chains to those roots."

So the people with a problem this week are not victims of the compromise. They are customers holding perfectly good certificates under a hierarchy that is being withdrawn. Chrome's guidance, as reported, is direct: website operators with certificates chaining to that root "must install a certificate from another hierarchy before then to avoid breakage". Debian, Ubuntu, certifi 2026.10.19, Rust's webpki-roots 1.0.10 and Homebrew have already removed the same root, so non-browser clients are dropping it too.

Check your own chain now rather than trusting an inventory:

openssl s_client -connect your-host:443 -servername your-host \
  </dev/null 2>/dev/null | openssl crl2pkcs7 -nocrl -certfile /dev/stdin \
  | openssl pkcs7 -print_certs -noout

If emSign appears anywhere in that output, you are replacing a certificate this week. One nuance worth knowing: the RSA line is a separate question. Chrome is "reviewing the status of eMudhra's other root in its store, emSign Root CA - G1" with no decision date, and eMudhra says its "G1 RSA roots will continue to serve customers until this transition is complete".

What eMudhra says, and what it does not

eMudhra announced on 22 October that it is exiting the global SSL/TLS certificate business entirely. The stated reasoning is commercial: SSL/TLS contributes "about 1% of the global revenue", and "Due to increasing data sovereignty & compliance requirements, complexity and cost associated with this business is increasing." The Chairman adds that "the level of social media amplification around this incident has brought scrutiny that is out of proportion to SSL/TLS's place in our business."

The release is firm that "Its infrastructure was not compromised and no data was breached", and says the affected CAs were revoked "within 14 hours of discovery". It commits to keeping revocation and certificate status services running "until every issued certificate has expired or been replaced", and says eMudhra "will reach out to affected customers to replace any certificate free of cost from partners through the transition".

Two things it does not give you: a wind-down date, and any acknowledgement of the Chrome root-removal timeline. If you are a customer, the free replacement offer is real but the clock is Chrome's, not eMudhra's. Do not wait to be contacted.

For Indian readers, one clarification that is easy to miss and matters commercially: eMudhra states that the Indian DSC, eSign, emSigner and SecurePass services "are not affected and continue to operate as normal". This is a global TLS hierarchy problem, not a Digital Signature Certificate problem. If your compliance posture depends on evidencing a vendor's certificate hygiene — as it does under UAE frameworks where a vendor must evidence controls — that distinction is the one to put in writing.

Why Node.js blocked keys instead of removing the root

This is the part worth reading even if eMudhra never appears in your estate, because it documents a real limitation. The Node.js pull request that implemented the block states the problem plainly: "Node.js embeds the Mozilla root store but has no equivalent of the browsers' CRLSet/OneCRL and no default online revocation checking."

So Node had no mechanism to revoke an intermediate, and removing the root was rejected because it "would over-block, since other legitimate intermediates chain to them". The chosen fix is "a small compiled-in blocklist of SubjectPublicKeyInfo SHA-256 hashes, checked from a single SSL_CTX_set_cert_verify_callback hook on every SSL_CTX Node.js creates", with the eight hashes "byte-identical to Go's fix (CVE-2026-111943) and Electron's patch". A hit surfaces as X509_V_ERR_CERT_REVOKED, honours rejectUnauthorized, and appears as authorizationError on client and server sockets.

Read that back as a general fact about your stack: a runtime with no revocation checking cannot respond to a compromised intermediate without shipping a release. Which means the window between "the root programs blocked it in four hours" and "your fleet is protected" is however long your upgrade cadence is. That is the real lesson, and it is the same one certificate lifetimes disagreeing across issuers keeps teaching: certificate infrastructure fails on timelines your deploy pipeline was not designed for.

The gap that remains after you upgrade

One detail from the same pull request deserves to be in your runbook: "Sessions resumed from before the upgrade are not re-verified. This is standard TLS resumption behaviour and ends with the session timeout."

So upgrading Node does not immediately sever connections negotiated beforehand. For a long-lived service-to-service connection with generous session lifetimes, a resumed session keeps trusting a chain the new binary would reject. The exposure is small here — nothing was mis-issued — but the mechanism is general, and it is the argument for actually restarting services after a TLS-related upgrade rather than letting them drain.

What to do this week

Four actions, in order. First, check every public endpoint for an emSign chain using the command above, including the ones not in your inventory — load balancers, legacy subdomains, partner-facing APIs. Second, if you find one, order a replacement from a different hierarchy today and take eMudhra up on the free replacement rather than waiting for contact. Third, upgrade Node.js to 22.23.4, 24.22.1 or 26.12.1, and Go to 1.27.3 or 1.26.10, then restart rather than drain. Fourth, check whether any internal code-signing depends on the EM OV CS CA pair, which the TLS-focused coverage mostly skips.

Two caveats on timing, accurate as of 23 October 2026: the Chrome date is expected rather than guaranteed, reaching Canary and Beta earlier, and Red Hat had shipped no package update at the time of reporting — only bulletin RHSB-2026-012 with a workaround. Verify against your own distribution before you declare this closed.

If nobody in your organisation can currently answer "which CA issued the certificate on each of our endpoints" in under an hour, that is the finding worth acting on, and it will outlast this incident. It is usually the first inventory we build in DevOps and cloud engineering work, because every CA distrust event for the next decade will ask the same question on four days' notice.