What Happened to eMudhra? The TLS Certificate Compromise Explained

The digital trust provider eMudhra announced its withdrawal from the global SSL/TLS certificate business after an error was discovered in its cryptographic key generation. The decision comes amid broader commercial and operational challenges and has raised concerns about how secure the systems are that help websites and applications establish and maintain trusted connections.

A security researcher had run a check against the Common DA Database (CCADB) and found that private keys belonging to eight eMudhra intermediate certificate authorities were so weak that they could be recovered from publicly available certificates.

These weak keys could potentially allow attackers to create fraudulent certificates, impersonate legitimate websites and intercept or modify communications (under certain circumstances).

eMudhra has acknowledged the findings and attributed the weakness to a script error. The company says the affected intermediates didn’t issue certificates to end users, its infrastructure wasn’t breached and its other digital trust services remain operational.

Even though the affected intermediates have been revoked and browser and operating-system providers have introduced the appropriate protective measures, the incident highlights the challenges of securing the systems that underlie digital trust.

What Is eMudhra?

The company at the centre of this security incident is an India-based digital trust and cybersecurity firm. eMudhra provides digital identity, authentication, electronic signatures and public key infrastructure (PKI) services.

The company also operated in the global SSL/TLS certificate market, supplying certificates used to secure website connections through HTTPS.

eMudhra has a significant presence in India's digital-signature market. In its FY2026 investor presentation, it reported an approximately 38 per cent market share by value in that market, citing a 2024 Frost & Sullivan report.

The presentation also identified eMudhra as one of 24 licensed certificate authorities in India, although only 10 were actively issuing digital-signature certificates at the time.

Why Is eMudhra Leaving the Global SSL/TLS Certificate Business?

On 22 October 2026, eMudhra announced that its board had decided to withdraw from the global SSL/TLS certificate business. The company cited rising compliance costs, operational complexity and competition from providers offering free certificates. It also said the business contributed approximately 1 per cent of its total revenue.

The withdrawal follows the October certificate security incident, in which researchers recovered weak private keys associated with eight intermediate certificate authorities. However, eMudhra's announcement also pointed to the broader challenges of operating in the global certificate market.

The company said it would work with browser programmes and customers during the transition, including replacing affected customer certificates where necessary and maintaining certificate revocation and status services until certificates had expired or been replaced. It also stated that its G1 RSA roots would continue serving customers during the transition.

The decision applies to eMudhra's global SSL/TLS certificate business, not the company as a whole. eMudhra says its digital-signature, eSign, enterprise PKI, identity and authentication services remain operational.

What Happened in the eMudhra Certificate Compromise?

In October 2026, private keys linked to eight intermediate certificate authorities of eMudhra were found to be cryptographically weak. This means that the keys were supposed to be extremely difficult to guess or calculate. But, the flaw made them weak enough to be recovered, opening up the possibility for it to allow someone to create fake digital certificates that appeared legitimate.

The flaw was found by a security researcher, only known by the moniker Wayne. To prove the compromise, the researcher left a message, “We have a problem here - Wayne” and then alerted Google, Apple, Microsoft, Mozilla, and eMudhra.

In a statement about the incident, eMudhra attributed the incident to a script error during a key-generation process in April 2025. The error resulted in weak cryptographic keys being generated alongside the secure keys that were intended during the process.

The affected group included six TLS intermediates and two code-signing intermediates. TLS certificates help secure website connections, while code-signing certificates help verify software publishers and the integrity of signed software.

Researchers (aside from the aforementioned Wayne) recovered the weak private keys from publicly available certificates. eMudhra revoked all eight affected intermediates on 18 October, and browser and operating-system providers introduced measures to distrust the affected certificate hierarchy.

The incident raises questions about how the weak keys passed through eMudhra's existing security controls and remained undetected. It’s unclear whether the company knew of the problem before the researcher reported it.

However, the apparent process gap between key generation and detection highlights the importance of independent validation, continuous monitoring and controls that can identify cryptographic weaknesses before they become a wider risk.

Why Are Weak Certificate Keys Dangerous?

Public key infrastructure is often illustrated as a pyramid of trusted authorities.

At the top is a root certificate authority (CA), with intermediate CAs issuing certificates to websites and other entities stacked below it. When someone visits an HTTPS website, their browser checks its security certificate, using it to verify on their behalf that it indeed links back to an authority the browser trusts.

Those private keys of intermediate CAs are a critical security asset. If someone can recover it behind the scenes, someone with bad intentions may be able to issue fraudulent certificates that appear to come from a trusted authority.

According to Cloudflare's technical analysis of this compromise, the recovered eMudhra keys could be used to generate certificates for any domain. This could lead to a number of risks such as:

• Website impersonation: Cyber attackers may create fake certificates for legitimate domains to make fraudulent websites appear legitimate.
• Intercepted communications: In some cases, an attacker can use fraudulent certificates to intercept or modify traffic between users and websites.
• Software impersonation: The affected code-signing keys, which are key pairs that verify who published a piece of software and whether it’s been altered, could potentially be used to make malicious software appear to have been signed by a legitimate publisher.

These are all potential attack scenarios and shouldn’t be seen as evidence that the keys were indeed used maliciously. eMudhra says the affected intermediates didn’t issue certificates to end users, and the company has reported no infrastructure compromise or data breach.

Which Certificates and Services Were Affected?

The incident involved eight intermediate CAs in eMudhra's global TLS and code-signing infrastructure. Browser trust programmes also introduced measures affecting the associated root certificate hierarchy.

According to FairSSL's analysis, approximately 30,000 TLS certificates were associated with the affected root hierarchy. This figure refers to the wider hierarchy, not certificates issued by the eight intermediaries with weak private keys.

In the latest incident update, published on 28 October, eMudhra clarified that approximately 30,800 certificates issued under the affected G3 hierarchies belong to a single customer ecosystem in the United States.

The company said this customer is now using an alternative certificate issuance pathway through eMudhra’s G1 RSA root while transitioning to another trusted hierarchy. The transition is intended to minimise disruption to the institutions within that ecosystem.

The distinction is important: the eight affected intermediates didn’t issue end-user certificates, according to eMudhra. The customer impact stems from the subsequent distrust of the associated certificate hierarchy, rather than evidence that 30,800 certificates had their private keys compromised.

Organisations should establish whether their systems use the affected certificates or trust hierarchies rather than assuming they’re unaffected. Applications may validate certificates through operating systems, software libraries, containers or custom trust configurations, so checks should cover these dependencies as well.

What Did Browser and Operating-System Providers Do?

The disclosure led browser and operating-system vendors to take steps to distrust the affected certificate hierarchy. Cloudflare also implemented mitigations across its services and updated software that relied on the affected trust infrastructure.

However, these protections may not reach every application or device at the same time. Some applications have their own certificate stores rather than relying on the operating system, while older devices may not receive regular updates.

Organisations should therefore assess how individual applications validate certificates, particularly in environments with legacy software, containers and connected devices.

Security and infrastructure teams should check whether their systems rely on any of the affected certificates or trust hierarchy and follow the relevant vendors’ guidance on remediation steps.

1. Identify the impacted and dependent certificates

Review certificate inventories, certificate management tools and software dependencies that may use eMudhra certificates used by websites, internal services, APIs, mutual TLS connections and code-signing systems.

Automation discovery can also help identify embedded certificates in applications, containers and connected devices that may be missed doing manual inventory.

2. Set up the necessary controls

Install security patches provided by the browser and operating system vendors. Check if apps with separate cert stores need to do anything else.

Look for updates for legacy applications and embedded/integrated devices’ patches and firmware. Identify any devices that can’t be updated, and whether they can be safely reconfigured, or if they must be isolated or simply replaced.

3. Replace affected certificates as necessary

Review vendor guidance for information about certificates or certificate chains that need to be renewed.

Make sure that replacement certificates are chained to a trusted authority at this time and servers are showing the right chain of certificates. Work with owners of applications and service providers to minimise disruption caused by change.

4. Code signing process audit

Check whether the software verification systems rely on the two affected intermediates for code signing.

Review software inventories, security tools and build pipelines to identify potentially affected signatures. Check software signatures against current trust information.

Evaluate software provenance to ensure signed software came from a trusted source and has not been altered.

5. Check for certificate errors

After remediation, look for application logs, TLS connection failures, and certificate validation errors.

Unexpected failures may mean that the application is still using a certificate chain that is no longer trusted. Find out why instead of turning off certificate validation (and removing an important security control).

What Does the eMudhra Certificate Compromise Mean for Enterprise Security?

The incident illustrates the constraints of depending only on written procedures and audits. The certificate authorities are supposed to have tight controls on key generation, safeguarding the private keys and issuing certificates. But, unfortunately, this weakness went undetected for around 18 months.

A proper root cause report should explain how the weak keys were created, why they were used, and why the previous checks failed to detect the problem.

Cryptographic keys must be tested to ensure they meet security standards. It helps to make sure that the right keys are used in published certificates, and that systems don’t accidentally pick weak keys.

The incident additionally emphasises the need for certificate management to reach beyond the central IT department. Providers can do things to protect themselves, but applications and devices with separate or obsolete trust configurations may require more attention.

Organisations need to know exactly which certificates they have, have clear processes for fixing any problems and be able to check that any changes have been made on all of the systems involved.

Digital Trust Protection Is More Than Just Encryption

The eMudhra certificate breach is a reminder that digital trust is more than encryption or HTTPS in the browser address bar. It also relies on secure key generation, trusted certificate authorities, and software that correctly validates digital identities.

Enterprise security teams need to initiate action to identify certificate dependencies, apply necessary patches and confirm all impacted systems have been remediated.

eMudhra’s exit from the global SSL/TLS certificate business signifies a major shift in that segment of the digital trust market. But the bigger problem is still the same: organisations need to know which systems they trust, and be able to revoke that trust where appropriate.

As enterprises become more interconnected, proper certificate management is critical to protecting digital identities and securing communications.

Stay on top of what you need to do to keep your website and internal applications secure from compromises like these by following EM360Tech’s reporting on cybersecurity and infrastructure management.