eMudhra's TLS Exit: What Weak CA Keys Mean for Your Website

Your SSL certificate can have months left before it expires and still stop being trusted.

That is the operational lesson from the eMudhra certificate incident. On October 22, 2026, the company announced its withdrawal from the global SSL/TLS certificate business following the discovery of weak private keys associated with eight intermediate certificate authorities. Its announcement also promised replacement certificates through partners and continued certificate-status services during the transition. [1]

For website operators, the immediate question is practical: does your deployed certificate chain depend on the affected trust hierarchy?

Reporting checked on October 26, 2026. Browser responses and migration arrangements may change; consult the linked incident records for updates.

What Happened to eMudhra's CA Keys?#

According to India's CERT-In, the affected P-384 elliptic-curve private keys had numerical values below 256. They could be recovered almost instantly from the corresponding public keys. The eight affected intermediate certificates comprised six TLS intermediates and two code-signing intermediates. Calling them eight website certificates would miss the significance: these were CA credentials used to sign other certificates. [2]

A properly generated private key should be computationally infeasible to derive from its public key. Here, the tiny range of possible values made recovery practical. The problem was key generation, rather than a general break of elliptic-curve cryptography.

In the public Mozilla incident discussion, eMudhra attributed the problem to an April 30, 2025 key-generation ceremony. It said a deviation involving a key wrap/unwrap test produced a weaker second set of keys, which were mistakenly selected for certificate requests because their labels were similar to those of the intended keys. That is the company's account; the incident record remains the place to follow further investigation. [3]

Why an Intermediate CA Compromise Matters#

An ordinary website certificate identifies a particular service. An intermediate CA certificate gives its holder authority to sign certificates within the constraints imposed by its chain.

Recovering an intermediate's private key can therefore let an attacker create fraudulent certificates for domains they do not own. Mozilla explicitly identified website impersonation as a risk in its public disclosure. [4]

An attacker would still need a way to bring a victim's connection to infrastructure they control, and the client would need to accept the fraudulent chain. Possessing a CA key does not automatically redirect internet traffic or reveal every historical HTTPS session. But it undermines a central promise of HTTPS: that the certificate authenticating a website was issued through a trustworthy process.

How the Trust Ecosystem Responded#

Mozilla received the report on October 17 and blocked the affected TLS intermediates in Firefox through OneCRL that evening. Its disclosure explains that this protection could reach Firefox users without an update or restart. [4]

CERT-In records that eMudhra revoked the eight intermediate certificates on October 18. It also describes Google's Chrome CRLSet blocking and removal of the emSign ECC Root CA - G3 certificate from Mozilla's NSS trust list. [2]

These actions address different layers of the problem:

The result is that the migration scope can be wider than the eight weak keys. A legitimate website may need a replacement because its chain depends on a root being removed.

Does This Affect Every eMudhra Customer?#

A provider's name alone is not enough to determine exposure. Inspect the actual chain and the trust decisions of the clients that use your service.

eMudhra's exit announcement says its G1 RSA roots will serve customers during the transition, and that its other signing and enterprise services operate separately. CERT-In likewise distinguishes this incident from India's regulated digital-signature certificate and eSign services. [1][2]

The company has said the affected intermediates had issued no end-entity certificates and that its infrastructure and customer data were not breached. Those are company statements, not a reason to dismiss the recoverable-key risk. A party holding a compromised signing key could issue certificates outside the CA's normal systems. [1]

What Website Owners Should Do Now#

1. Inventory the Chain Your Servers Actually Present#

Check production hostnames, API endpoints, load balancers, CDN custom domains, and TLS-enabled mail services. Record the leaf certificate, intermediate certificates, and the root paths accepted by your important clients.

For an HTTPS endpoint, this command shows the certificates sent by the server:

openssl s_client -connect example.com:443 -servername example.com -showcerts </dev/null

Replace both instances of example.com with your hostname. Servers normally omit the root certificate, so this output is a starting point for chain inspection, not a complete browser-trust verdict. Also, s_client can continue after verification errors; a completed connection alone does not prove the certificate is trusted.

2. Arrange Replacement Before Users See Errors#

If your chain relies on the affected hierarchy, contact your certificate provider or reseller for migration instructions. Ask which replacement CA will issue the certificate, what chain to install, and whether your automation needs a different account or issuance endpoint.

Do not wait for the certificate's printed expiration date. A trust-store change can make that date irrelevant to availability.

3. Deploy and Verify Every TLS Termination Point#

Install the replacement certificate and correct intermediate bundle wherever TLS terminates. Reload the relevant service, then test the public endpoint from outside your infrastructure.

Check representative browsers and application clients. A successful test on one machine may reflect a different trust store, cached intermediate, or alternate chain from the clients your customers use.

4. Keep Browsers, Operating Systems, and Trust Stores Updated#

Trust protections reach clients through different channels. Include container images, language runtimes, appliances, and long-lived application servers in your review. Updating a desktop browser does not update an unrelated Java trust store or a container's CA bundle.

5. Prepare a Repeatable CA Migration Procedure#

Keep domain-validation access, certificate ownership, deployment steps, and service reload instructions documented. Test that you can obtain and deploy a certificate from another publicly trusted provider when necessary.

Automation helps with routine renewal, but an incident-driven migration may require intervention before the normal renewal window.

Expiry Monitoring Is One Part of Certificate Reliability#

An expiry alert answers an essential question: when does this certificate run out? It does not, by itself, establish that every browser still trusts the issuing hierarchy.

Pair expiry monitoring with chain validation, provider security notices, trust-store updates, and external checks after certificate changes. Treat the certificate served to users as the result that matters, rather than assuming a successful issuance or renewal completes the job.

For ongoing certificate checks, visit ExpiryHawk. For the consequences of missing a renewal, read What Happens When Your SSL Certificate Expires?.

Sources#

1. 1eMudhra: announcement of its withdrawal from global SSL/TLS, October 22, 2026
2. 2CERT-In: Compromise of eMudhra Intermediate CA Certificates, October 21, 2026
3. 3Mozilla Bugzilla: eMudhra private-key compromise investigation, Bug 2083449
4. 4Mozilla: public disclosure of the compromised eMudhra intermediate certificates