eMudhra to Exit Global SSL/TLS Business After 8 Intermediate CA Keys Found Easily Guessable

eMudhra is leaving global SSL/TLS certificates because the business is relatively small but increasingly difficult and costly to operate. The company said data-sovereignty and compliance rules add complexity, while some large providers give certificates away free. It also said social-media attention created scrutiny out of proportion to SSL/TLS’s role in its business.

The immediate trigger was a researcher’s October 17 report. The researcher recovered the private keys of eight eMudhra intermediate CA certificates because each key was below 256 and could be worked out almost instantly. Six affected intermediates were used for website TLS certificates. Chrome and Firefox then blocked those intermediates and moved against the ECC root above them.

The board decided to withdraw five days after the report. eMudhra will replace affected customer certificates with free partner certificates, but it has not named the partners or set an exit date. It will keep revocation and status services running until issued certificates expire or are replaced, while continuing other businesses.

An intermediate certificate authority is a CA beneath a root CA in a trust hierarchy. It can sign or issue certificates for websites without exposing the root CA’s private key. This structure limits direct use of the root and lets certificate providers manage separate issuing systems.

The private key is the critical secret behind that authority. A CA uses it to sign certificates, proving that the intermediate approved them. If an attacker can obtain or calculate the key, the attacker may be able to produce certificates that appear to come from that trusted CA. The article says all eight reported eMudhra keys were below 256 and could be worked out almost instantly.

The danger prompted Chrome and Firefox to block the six TLS intermediates within hours. Google said no website certificate from them had appeared in public CT logs before the block, so none could have been used against software requiring CT logging. eMudhra also said its systems were not breached and the intermediates were never used for websites or users.

Chrome counted about 30,800 unexpired certificates chained to eMudhra’s emSign ECC Root CA - G3 in public Certificate Transparency logs on October 21. These certificates were potentially affected because Chrome planned to stop trusting that root, and Mozilla had already decided to stop trusting it in Firefox.

The overwhelming majority came through InCommon. Chrome’s count showed that 99.9% of the certificates were issued through the service created by Internet2 for the higher-education community. InCommon moved its service onto eMudhra’s CertiNext platform between April and July this year.

The practical impact is broader than simply counting certificates. Browsers removing the root also remove trust from legitimate certificates issued beneath it. eMudhra estimated that about 30,000 certificates need to be moved. About 97% were issued using ACME, but ordinary ACME clients may not replace them before their normal renewal window unless they support ARI or operators intervene manually.

Browsers trust a website’s TLS certificate only when its chain leads to a root CA that remains in the browser’s trusted store. If Chrome or Firefox removes that root, certificates issued beneath it lose that foundation, even when they were legitimate and have not expired.

For example, Chrome planned to stop trusting eMudhra’s emSign ECC Root CA - G3, while Mozilla had already made the same decision for Firefox. About 30,800 unexpired certificates were chained to that root on October 21. A browser encountering one of those certificates can no longer validate the chain as trusted and will show a security warning rather than a normal trusted connection.

Website operators must acquire and install a new TLS certificate from another hierarchy included in Chrome’s Root Store, Google said. eMudhra plans free replacements through partners. Some operators may use eMudhra’s separate RSA hierarchy, though Chrome was still considering whether to retain its remaining CA certificates, so replacement and configuration changes may still be necessary.

An intermediate CA private key is meant to be an unpredictable secret. The researcher found that each of eMudhra’s eight keys was below 256, making the keys easy to calculate. Possession of such a key could let someone create certificates that appear to have been issued by a trusted intermediate CA.

That possibility matters because browsers normally rely on the CA hierarchy to recognize legitimate website certificates. A fraudulent certificate signed by a trusted intermediate might be used to impersonate a website or interfere with a connection. The article does not report that this happened. It says eMudhra never used the eight intermediates to issue certificates to websites or users.

Several safeguards narrowed the known risk. Chrome and Firefox blocked the six TLS intermediates within hours. Google said no certificate from them had appeared in CT logs before the block, so none could have been used against Chrome or other software requiring CT logging. E m udhra also said its systems were not breached, but browsers still removed trust because the keys were unsafe.

Certificate holders have several possible routes. eMudhra said it would provide free replacement certificates through partners. Cornell advised requesting RSA certificates because they use eMudhra’s unaffected root, while the University of Michigan identified Let’s Encrypt as its main alternative. Operators can also obtain a certificate from another PKI hierarchy included in Chrome’s Root Store.

ACME automates certificate requests and renewals, and about 97% of the affected certificates used it. However, Chrome told eMudhra that standard ACME clients do not replace certificates outside their renewal window. They need support for ACME Renewal Information, or ARI, to trigger an earlier replacement automatically.

That limitation creates hands-on work. Someone may need to start the replacement manually, install the new certificate, and change client settings when moving from ECC to RSA. Operators also need to confirm that the new chain is trusted. eMudhra estimated about 30,000 certificates require movement, so automation support and careful configuration will determine how smoothly the transition proceeds.

Public-key infrastructure, or PKI, gives a browser a way to judge a website certificate without knowing the site personally. The website presents a certificate, usually with intermediate certificates. Those certificates form a chain of signatures leading to a root CA that the browser already trusts. This explanation uses general PKI knowledge; the article mainly illustrates it through eMudhra’s roots and intermediates.

In eMudhra’s case, six TLS intermediates sat beneath the emSign ECC Root CA - G3. The intermediates could issue website certificates, while the root anchored the chain in browsers. The browser checks that the signatures connect correctly and that the certificate is still valid. CAs also provide revocation and status services, which eMudhra said it will keep running.

Trust can still fail if the root or an intermediate is distrusted. Chrome and Mozilla planned to remove trust in the ECC root, cutting off legitimate certificates beneath it. Website operators therefore need a replacement certificate whose chain leads to another hierarchy included in the browser’s trusted root store.