eMudhra Exits the SSL/TLS Certificate Business After Eight Weak CA Keys Are Recovered

Website owners and IT administrators using affected eMudhra SSL/TLS certificates face an urgent replacement exercise after a researcher recovered the private keys of eight intermediate certificate authority certificates.

On Thursday, October 22, 2026, Indian certificate authority eMudhra announced that it would withdraw from the global SSL/TLS certificate business following the discovery.

The issue is serious because the recovered private keys should have been enormous, unpredictable random numbers. Instead, all eight keys were below 256 and could reportedly be worked out almost instantaneously.

The discovery prompted rapid action from major browser vendors. Chrome and Firefox blocked six intermediate certificate authorities used for website certificates within hours of receiving the report.

Mozilla subsequently decided to stop trusting the root certificate above those intermediates, known as emSign ECC Root CA – G3. Chrome’s removal was expected to affect users on the morning of October 27, Pacific time.

For website operators, this means that having a certificate that was previously valid does not necessarily guarantee that browsers will continue trusting it. Once a certificate authority is distrusted, legitimate certificates issued beneath the affected root can also become unusable in browsers that enforce the change.

How the Weak eMudhra Certificate Keys Were Discovered

The researcher reported the problem to Apple, Google, Microsoft, Mozilla and eMudhra on October 17, 2026.

The eight affected private keys were associated with intermediate certificate authority certificates. These intermediates sit within the certificate trust hierarchy used to issue and validate digital certificates.

In a properly secured public-key infrastructure, private keys must be generated with sufficient randomness and protected against unauthorised recovery. If a private key can be calculated easily, an attacker may be able to misuse the corresponding certificate authority’s signing capabilities.

That creates a serious trust problem. Browsers and operating systems rely on certificate authorities to help establish whether a website’s digital certificate can be trusted.

According to the supplied reporting, eMudhra said the eight keys had never been used to issue certificates to websites or users and that its systems had not been breached.

Google also said that no website certificate from the six blocked intermediates had appeared in Certificate Transparency logs before its block. As a result, there was no evidence in those logs that the intermediates had been used to issue website certificates against Chrome’s certificate transparency requirements.

These statements are important, but they do not eliminate the need to replace affected certificates and follow browser vendor instructions.

Why Chrome and Firefox Are Removing Trust

Digital certificates are used to establish secure connections between websites and visitors. SSL/TLS certificates help browsers authenticate websites and establish encrypted connections.

The trust system is hierarchical. A root certificate can establish trust in intermediate certificate authorities, which may then issue certificates to individual websites.

This arrangement means that distrust at the root level can have consequences far beyond the certificates directly associated with a particular weak key.

Mozilla decided on October 20 to stop trusting emSign ECC Root CA – G3. Chrome’s planned removal was expected to take effect on October 27, Pacific time.

Chrome’s figures showed that approximately 30,800 unexpired certificates were chained to the affected root as of October 21. Around 99.9% had been issued through InCommon, a service built for higher education.

InCommon moved onto eMudhra’s CertiNext platform between April and July, making the certificate distrust decision particularly significant for organisations relying on its certificate infrastructure.

The key lesson for website administrators is that certificate trust depends on more than the expiration date displayed in a browser. A certificate may still be within its validity period and yet stop being trusted because of a change in the certificate authority hierarchy.

Which Website Owners Are Affected?

The immediate concern is for organisations using affected eMudhra or InCommon ECC certificates chained to the distrusted root.

Google instructed affected website operators to obtain replacement certificates from another hierarchy in the Chrome Root Store immediately.

eMudhra estimated that approximately 30,000 certificates would need to be replaced, with about 97% issued through ACME automation.

ACME is commonly used to automate certificate issuance and renewal. However, automation does not guarantee that every affected certificate will be replaced automatically when a certificate authority is distrusted.

Chrome warned that standard ACME clients may not be able to replace certificates outside their normal renewal windows unless they support ACME Renewal Information or an administrator intervenes manually.

That distinction matters because organisations may believe their certificates are covered by automatic renewal when the software is not configured to respond to this particular situation.

Higher education institutions, hosting teams, application owners and administrators responsible for multiple domains should identify affected certificates and check their renewal processes instead of waiting for the next scheduled renewal.

What to Do Before October 27

If you hold an affected eMudhra or InCommon ECC certificate, treat replacement as an urgent task.

1. Identify affected certificates

Review your certificate inventory and determine whether any active website certificates chain to emSign ECC Root CA – G3 or the affected intermediates.

Check certificates across production websites, subdomains, APIs, load balancers and other services where applicable.

2. Obtain a replacement certificate

Google advised affected operators to obtain a new certificate from another hierarchy in the Chrome Root Store.

Cornell advised certificate holders to request RSA certificates instead of ECC certificates because RSA sits under a separate, unaffected root, according to the supplied reporting.

The University of Michigan also directed users towards Let’s Encrypt as a fallback.

Choose a replacement that is supported by your server environment and trusted by the relevant browser and operating-system trust stores.

3. Do not rely blindly on automatic renewal

Review the ACME client and certificate management platform used by your organisation.

Determine whether it can replace an affected certificate outside its usual renewal window. If it cannot, arrange a manual replacement or another supported renewal process.

4. Install and test the replacement

After obtaining the replacement certificate, deploy it to the appropriate service and verify that the complete certificate chain is correct.

Test the website from relevant browsers and environments. Confirm that users can establish secure connections without certificate trust errors.

5. Check every service using the affected hierarchy

A certificate inventory should include more than the main website. Check other domains, applications and endpoints that may use the same certificate authority.

For organisations with many certificates, prioritise public-facing services and any systems whose failure would interrupt essential operations.

What About eMudhra’s RSA Root?

Questions also remain about the RSA side of eMudhra’s certificate infrastructure.

A revocation list published on October 14 for one RSA-side certificate authority reportedly failed signature verification. A participant in Mozilla’s public bug report suggested that the problem might involve the wrong signing key rather than another weak key.

Chrome also posted 12 questions to eMudhra, and the supplied reporting said there were no public answers as of Thursday afternoon.

These unresolved questions should be distinguished from the established need to replace certificates affected by the ECC root distrust decision. Website owners should follow current browser vendor guidance rather than assume that every eMudhra certificate is affected in exactly the same way.

Why the eMudhra Certificate Incident Matters

The incident demonstrates how weaknesses in certificate authority infrastructure can create widespread operational problems even when there is no reported breach of the certificate authority’s systems.

The browser trust model depends on strong key generation, careful certificate management and confidence in the organisations issuing certificates. When that confidence is undermined, browser vendors may remove trust to protect users.

For website owners, the practical challenge is replacing certificates quickly without interrupting online services. Organisations that rely on automated certificate management should also make sure their processes can handle emergency distrust events, not just routine expiration.