eMudhra exits the TLS certificate market after 8 intermediate CA keys are found trivially guessable
On October 22, 2026, Indian certificate authority eMudhra announced it will withdraw from the global SSL/TLS certificate business, five days after a researcher recovered the private keys of eight intermediate CA certificates — every one of them below 256. If your organization issues certificates under the emSign ECC Root CA - G3 root, you have until October 27 to move to another hierarchy.
October 17, 2026. A researcher reports to Apple, Google, Microsoft, Mozilla and eMudhra that they have recovered the private keys of eight intermediate certificates belonging to the Indian certificate authority. October 22, 2026. eMudhra’s board decides to withdraw from the global SSL/TLS certificate business. October 27, 2026. Chrome will stop trusting the emSign ECC Root CA - G3 root above those intermediates. Why it matters: a certificate authority does not fall to a zero-day — it falls to its own keys, and the trust of an entire ecosystem falls with it.
Eight private keys guessable in an instant
A private key for an intermediate certificate is supposed to be an astronomically large random number. All eight recovered keys were below 256. Anyone could work them out almost instantly, with no factoring and no computation to speak of — a simple enumeration of a few hundred values. It is the cryptographic equivalent of a safe whose combination is set to “000”.
Six of the eight were TLS intermediates meant to issue website certificates. The other two served different purposes. The researcher reported the weak keys on October 17; Chrome and Firefox blocked the six TLS intermediates “within hours”. No website certificate issued by them had appeared in public Certificate Transparency logs before the block, which means none could have been used against Chrome or against software that requires CT logging.
eMudhra says its systems were not breached and that it never used those eight keys to issue certificates to websites or users. So the problem is not an intrusion — it is structural. A certificate authority that generates keys below 256 has a randomness-generation defect, not a firewall problem.
The root that drags 30,800 certificates with it
Removing a root from a browser also cuts off the legitimate certificates issued beneath it. By Chrome’s count in the CT logs, about 30,800 unexpired certificates chained to that root as of October 21. The more striking number is this: 99.9% of those certificates were issued through InCommon, the certificate service Internet2 built for the higher-education community.
InCommon moved its service onto eMudhra’s CertiNext platform between April and July 2026. In other words, North American universities and research institutions — Cornell, Stanford and the University of Michigan are all named in the public exchanges — now find themselves dragged into an exit they never chose. Cornell alone counts more than 300 affected certificates and is now advising its holders to request RSA certificates instead of ECC ones, because “RSA certificates use eMudhra’s unaffected root and should work”.
Google was blunt with affected operators: they must “immediately acquire and install a new TLS certificate from another PKI hierarchy included in the Chrome Root Store”. The deadline is short — the morning of October 27, Pacific time — and it is not negotiable.
A migration trapped by automation
eMudhra estimates that about 30,000 certificates need to be moved, and that about 97% of them were issued via ACME, the protocol most servers use to request and renew certificates automatically. That is where the exit becomes a trap.
Chrome warned eMudhra that standard ACME clients do not replace a certificate outside its renewal window unless they support ACME Renewal Information (ARI) or someone intervenes by hand. Moving from the ECC hierarchy to the RSA one may also require changes to client configuration. The conclusion is brutal for an administrator: the automation that saved you time these past years will not save you this time — in many cases you will have to get your hands into the configuration.
eMudhra’s exit plan remains unclear on several points. The company will keep its revocation and status services running until every SSL/TLS certificate it issued has expired or been replaced. Its RSA G1 roots continue to serve, but Chrome has not yet decided whether to keep eMudhra’s remaining certificates in its root store. The announcement does not mention InCommon, nor whether the company will keep issuing new certificates under G1 until it exits.
The 2025 precedent that makes it worse
This is not the first warning sign. In 2025, eMudhra published invalid CRLs for six of those same intermediates. Its incident report at the time claimed they were fixed by “regenerating the CRLs using the appropriate private key associated with each Intermediate CA”.
On October 19, 2026, eMudhra told Mozilla that those lists were first signed with the intended keys, then, when that produced invalid signatures, “resigned with flawed keys” — precisely the weak keys found this month. On October 14, the company had published a CRL for emSign Root TLS CA - G1 whose signature does not verify against that CA’s key; a participant in the thread estimated on October 22 that it appeared to be signed with an OCSP certificate’s key — “a case of using the wrong signing key, rather than evidence of another weak key”.
Chrome raised these inconsistencies in twelve questions posted on October 21, including why the 2025 report did not mention that two key pairs existed for each of those CAs. “This raises serious concerns regarding eMudhra’s transparency and incident handling,” Chrome wrote. As of October 22 at 13:31 UTC, eMudhra had not answered any of them publicly.
Key generation is the crown of a certificate authority
It is worth separating two scenarios that get conflated too often. A certificate authority that is breached by an intrusion keeps, in principle, strong keys: the attacker stole a solid secret, and remediation means revoking and reissuing. An authority that generates weak keys is a far worse case: the defect is in the very process that creates the cryptographic material, and nothing guarantees the eight recovered keys are the only ones affected.
That is what makes the question Chrome posed — “do you hold more than one key pair for this CA, or for any of your roots?” — so dangerous. If a broken generation process produced eight keys below 256, it may have produced others, on other hierarchies, including G1, which Chrome has not yet decided to keep. eMudhra’s lack of a public answer to that question is not a communications detail: it is precisely the information a CISO must demand before reissuing certificates under a root from the same vendor.
The lesson goes beyond eMudhra. Public TLS rests on a small number of authorities whose randomness-generation quality is only auditable from the outside, through CT logs and browser checks. When that quality fails, the sanction is binary — removal from the root store — and collective: 30,800 legitimate certificates fall with the faulty root. That is exactly the distributed enforcement mechanism we described in our analysis of Cloudflare’s public roots, applied here to a vendor that, this time, had not planned its exit.
Verdict
If you issue or hold certificates chained under emSign ECC Root CA - G3, you have until October 27. Check your chain immediately — openssl s_client -connect your-domain:443 -showcerts — and move to another hierarchy, preferably Let’s Encrypt if your estate allows, as the University of Michigan already recommends. If you are an InCommon institution, the safest path is the RSA G1 hierarchy in the short term and an exit from eMudhra in the medium term: Chrome has not promised to keep G1, and trust is not rebuilt in a quarter. If you are not affected, keep the structural lesson anyway: the TLS trust chain rests entirely on the key-generation quality of a handful of authorities, and a browser can take down an entire hierarchy overnight. That is the underlying theme of our analysis of Cloudflare’s public roots: revocation power is now distributed, but the responsibility for a weak key remains fully centralized.