Let’s Build Something Great
Tell us about your goals and request a free project estimate.
What Went Wrong With eMudhra’s Certificates?
Key Takeaways
- Eight intermediate certificate authority certificates associated with eMudhra were found to have cryptographically weak private keys . Researchers were able to recover the keys, creating the potential for fraudulent digital certificates .
- Six affected authorities were associated with HTTPS website certificates, while two were associated with software code signing .
- The weakness originated during a key-generation process in April 2025 . The exact root cause remains under investigation, according to eMudhra.
- eMudhra stated that none of the eight affected intermediate authorities had issued certificates to websites or other end users . Public certificate transparency records also showed no certificates chaining to the six affected TLS intermediates before the blocking action.
- Major technology companies blocked the affected certificates. Some also removed trust in a related root certificate as an additional precaution, which can affect otherwise legitimate certificates issued under that hierarchy.
- The incident does not mean that all HTTPS connections are unsafe , nor does it establish that attackers stole data or exploited the weakness.
- Businesses should check their software, certificate trust stores, and application updates . Most ordinary users should keep their devices and software updated and avoid bypassing certificate warnings.
In October 2026, security researchers discovered that eight intermediate certificate authorities associated with eMudhra had cryptographically weak private keys. These keys were recoverable, potentially allowing someone to create fraudulent digital certificates that software might accept as legitimate.
The issue was reported to major technology companies on 17 October 2026. Mozilla, Google, Apple, and other organizations subsequently introduced measures to block the affected certificates or remove trust in the relevant certificate authorities.
The affected certificates served two different purposes:
- Six intermediate authorities were associated with TLS certificates, which help browsers verify website identities and establish secure HTTPS connections.
- Two intermediate authorities were associated with code signing, which helps operating systems and applications verify the identity of software publishers.
The incident therefore concerns two important parts of digital security: how websites establish their identities and how software establishes trust in signed programs.
Were the keys stolen in a cyberattack?
Not necessarily. The distinction is important. A compromised private key is a private key that an unauthorized party can recover or use. The term does not automatically mean that someone broke into a company’s servers and stole it.
In this case, researchers found that the private keys were weak enough to recover because of a problem with their generation. eMudhra stated that its infrastructure had not been compromised and that no data had been breached. It also reported that none of the affected intermediate authorities had issued certificates to websites or other end entities.
Those are the company’s statements about its investigation. They should be distinguished from the independently demonstrated weakness in the cryptographic keys. The incident shows that a security failure can undermine digital trust even without a conventional server intrusion.
What Are Digital Certificates and Certificate Authorities?
Digital certificates help computers establish trust in websites, services, and software publishers.
When you visit a website using HTTPS, your browser checks the site’s certificate to help verify that it is communicating with the intended website. This identity check works alongside encryption, which protects information exchanged over the connection.
Most publicly trusted website certificates are part of a hierarchy known as a certificate chain. The following simplified diagram shows how that hierarchy works.
Root certificate authority
The highest-level authority trusted by a device or application. Delegates certificate-issuing authority
Intermediate certificate authority
Issues certificates under the authority granted by its parent. Signs an end-entity certificate
Website or service certificate
Helps the client verify the identity of the website or service. A root certificate authority establishes the highest level of trust in this hierarchy. An intermediate authority receives permission to issue certificates under that root. Websites and services then use their own certificates when establishing secure connections.
This structure allows certificate authorities to issue large numbers of certificates without relying on their root private keys for every transaction.
The eMudhra incident affected the intermediate level. If someone obtains a compromised intermediate authority’s private key, that person may be able to issue fraudulent certificates that appear to belong to other websites or services.
The critical point is that a fraudulent certificate can undermine website identity verification even when the certificate appears to be valid.
How Did the Private Keys Become Compromised?
The weakness originated during a key-generation process on 30 April 2025. Cisco Talos reported that a problem in eMudhra’s key-generation procedure produced an additional set of weak cryptographic keys. Those keys were then used for eight intermediate certificate authorities.
Why were the keys weak?
Cryptographic private keys must contain sufficient randomness to make them practically impossible to guess or recover. The affected keys did not meet this requirement. Cisco Talos reported that several of the recovered private keys corresponded to extremely small numerical values, rather than values with the expected cryptographic strength.
This made the keys much easier to recover than properly generated keys. The difference is similar to the difference between a password with an enormous number of possible combinations and one that can be guessed from a very small set of possibilities. The cryptographic consequences are much more precise, but the principle is the same: reducing the number of possible private keys makes recovery far easier.
Why did the weakness go undetected?
eMudhra stated that the keys were generated using certified hardware security modules. These devices are designed to protect cryptographic keys and support secure key generation. The company said the problem occurred during a step in the broader key-generation procedure, rather than because the hardware security modules were absent. It also reported that the hierarchy had passed two independent audit cycles before the weakness was discovered.
This distinction matters. Using certified security hardware does not automatically guarantee that every surrounding software operation and procedural step is correct. According to eMudhra, the precise root cause remained under investigation as of its 22 October statement. The company said it intended to publish the investigation findings once they were confirmed.
The affected keys were created in April 2025, and the weakness became public in October 2026. This represents approximately 18 months during which the keys existed before disclosure.
What Could an Attacker Do With the Compromised Keys?
The main risk is fraudulent certificate issuance. An attacker who possesses an intermediate certificate authority’s private key can potentially create a certificate for a domain they do not control. If a target application still trusts that certificate chain, the fraudulent certificate may pass its identity checks.
Impersonate a website
Imagine that an attacker wants to impersonate a bank’s website. Normally, the attacker cannot simply create a certificate for the bank’s domain and expect a modern browser to accept it. The browser checks whether the certificate chains back to an authority it trusts and whether the certificate satisfies the applicable validation rules.
A compromised intermediate CA key can undermine that protection. The attacker may be able to sign a fraudulent certificate that appears to authenticate the bank’s domain. If the attacker can also intercept or redirect the victim’s connection, the attacker may be able to impersonate the website and potentially read or modify the traffic.
This is known as a man-in-the-middle attack. However, recovering a private key does not automatically provide access to every connection. The attacker needs an opportunity to intercept or redirect traffic, and the client must still accept the fraudulent certificate. Browser blocks, certificate transparency enforcement, and other validation controls can prevent or expose such an attack.
Potentially misuse software code-signing trust
Two of the affected authorities were associated with code signing. Code signing helps establish who published a program and whether its signed contents have been changed. If a compromised authority can issue a fraudulent code-signing certificate accepted by a particular platform, an attacker may be able to make malicious software appear to have a trusted publisher identity.
The exact consequences depend on how the operating system or application validates code signatures. Code-signing trust and website TLS trust are related parts of digital security, but they are not interchangeable.
Affect software beyond web browsers
Browsers are not the only programs that validate certificates. Applications that connect to APIs, remote servers, software repositories, or VPN gateways may also rely on certificate authorities to verify the identities of those services.
Some programs use the operating system’s trusted certificate list. Others rely on their own certificate bundles or validation mechanisms. Consequently, a browser may block a certificate while a separate application continues to trust it. This is why the response to the eMudhra incident involves application developers, operating-system vendors, and administrators, not just browser manufacturers.
Who and What Is Affected?
The practical impact depends on the certificate hierarchy, the software performing validation, and the updates available to that software.
| Area | Potential impact |
|---|---|
| Web browsers | Software that still trusts an affected certificate could potentially accept a fraudulent website certificate. |
| Operating systems | Some trust stores may need updated certificate data or security patches. |
| Applications and APIs | Applications with outdated or independently maintained certificate stores may require separate updates. |
| VPNs and network security tools | Devices and applications validating the affected certificate chains may need vendor-provided fixes. |
| Containers and servers | Older certificate bundles and runtimes may continue trusting affected authorities until updated. |
| Code-signing verification | Software platforms must block the affected signing authorities to prevent fraudulent signing certificates from being accepted. |
| Existing customer websites | Some legitimate certificates under a related root hierarchy may stop working where that root is no longer trusted. |
These potential consequences are documented in the technical advisories from Cisco Talos, Google, Apple, and Red Hat. The actual exposure depends on how each product validates certificates and processes updates.
Does this mean all eMudhra certificates are compromised?
No. The eight affected intermediate authorities should not be confused with every certificate issued by eMudhra or with the company’s entire digital security infrastructure.
eMudhra stated that seven of the eight affected intermediate authorities had never been used in production. The remaining authority had been deployed, but it had not issued any end-entity certificates. The company also said that its root private keys and other intermediate authorities were not affected by the identified weakness.
However, there is another important distinction: some technology companies subsequently removed trust in the related emSign ECC Root CA G3 certificate as an additional precaution.
The root certificate’s private key was not reported as compromised. The broader change concerned whether software should continue trusting that root certificate.
This decision can affect legitimate certificates that chain to the same root. Google, for example, stated that some legitimate certificates under the root would stop functioning in Chrome after it removed the root from its trust store. eMudhra said the resulting customer impact was limited to one US customer ecosystem, whose affected certificates were being replaced.
These are separate issues:
- The weak private keys created a risk of fraudulent certificate issuance.
- The subsequent removal of trust in a related root certificate can affect legitimate certificates issued under that hierarchy.
Neither issue means that every website certificate associated with eMudhra is necessarily compromised.
Is there evidence that attackers exploited the weakness?
The cited public technical disclosures do not establish widespread exploitation. Cisco Talos reported on 21 October 2026 that it had not observed malicious incidents involving the compromised certificates in its monitoring. Google also stated that no TLS certificates chaining to the six affected TLS intermediates appeared in Certificate Transparency logs before its blocking action. This prevented such certificates from being used against clients enforcing the relevant transparency requirements.
These findings are important, but they do not prove that no attacker ever attempted to exploit the weakness. They indicate that the cited investigations had not identified malicious incidents and that major platforms introduced protective measures.
How Have Technology Companies Responded?
Major software vendors have taken different steps because browsers, operating systems, and application runtimes do not all handle certificate validation in the same way.
Google Chrome and Android
Google reported that Chrome blocked the affected intermediate public-key hashes on 17 October 2026. The change protected Chrome users without requiring a browser update or restart.
Google also distributed an equivalent update to Android devices and Chromebooks through Google Play Services. In addition, Chrome removed the related emSign ECC Root CA G3 certificate from its trust store to protect software that does not receive the same intermediate-certificate blocking updates.
Mozilla Firefox
Mozilla blocked the affected certificates using OneCRL, its centralized certificate-blocking mechanism.
Mozilla reported that the update reached Firefox users with standard configurations in less than three hours after it received the disclosure on 17 October. Mozilla also announced Firefox security updates and changes to its certificate store to protect additional applications that use Mozilla’s trust infrastructure.
Apple devices
Apple began blocking the affected TLS intermediate certificates on 19 October 2026. The protection applies automatically to Safari, Mail, and applications using Apple’s networking and security frameworks.
Apple also identified an important exception for some Mac command-line tools, including certain uses of curl and git . Those tools may use a separate certificate bundle that does not immediately receive Apple’s certificate-blocking updates.
Apple subsequently began blocking the related emSign ECC Root CA G3 certificate on 23 October. Its support guidance explains that developers and system administrators may need to consider additional actions for tools using separate trust stores.
Linux and application runtimes
Systems that rely on independently maintained certificate bundles can require separate updates. Red Hat issued an advisory explaining that its products could continue trusting affected certificates until the relevant certificate trust data was updated. Its guidance covers the ca-certificates package and the systems that rely on it.
The Go programming language also issued security updates to reject certificate chains containing the affected intermediate keys. This matters for cloud applications and infrastructure tools that use Go’s certificate-validation implementation.
The broader lesson is that updating a browser or operating system does not guarantee that every program on the same device has received the same protection.
eMudhra’s response and planned business withdrawal
eMudhra stated that it revoked the eight affected intermediate authorities on 18 October 2026 and began cooperating with browser and root-store operators.
On 22 October, the company announced that its board had decided to voluntarily withdraw from the global SSL/TLS certificate business. Reuters independently reported the decision and the wider response from technology companies.
The announcement concerned eMudhra’s global website-certificate business. It should not be interpreted as confirmation that all of the company’s other products and services were affected. eMudhra stated that its other named digital signature and enterprise services operated on separate infrastructure and remained unaffected.
What Should Businesses and Developers Do?
Organizations should determine which software and trust stores are affected, apply the relevant vendor updates, and verify that the changes protect the applications that actually make network connections.
Review certificates and trust stores
Start by identifying the software that relies on the affected certificate authorities. Review public-facing websites, APIs, servers, VPNs, network gateways, and applications that validate remote TLS certificates. Check the trust stores used by those systems, including custom certificate bundles and application-specific validation mechanisms.
Use the fingerprints and certificate details published in the official advisories when checking whether a specific certificate is affected. Do not rely on the issuer’s name alone.
Apply the relevant software updates
Install the applicable security updates for operating systems, browsers, application runtimes, HTTP clients, VPNs, and other certificate-validating software.
Follow the guidance published by the vendor of the actual software you use. An application may rely on a runtime or certificate bundle that receives updates separately from the operating system.
Check containers and deployed applications
Organizations running applications in Docker or other container environments should review their base images and bundled certificate data.
A container built before the fix may retain an outdated trust store even after the host operating system has been updated. Rebuild and redeploy affected images according to the relevant vendor guidance.
Also review long-running background services and workers where a restart or redeployment may be needed before new trust settings take effect.
Test the actual certificate-validation path
A website opening successfully in a browser does not prove that every application on the same computer is protected.
Test the relevant connections through the application, runtime, or library that actually validates the certificate. Verify that the affected certificate chains are rejected where the applicable mitigation requires it.
Monitor application logs and connection errors after deploying the changes. If a legitimate service stops working because its certificate chain is no longer trusted, work with the service provider to confirm the correct replacement certificate or trust configuration.
Never disable certificate verification to bypass errors
Do not fix certificate-validation errors by accepting every certificate or turning off TLS verification. Those changes remove safeguards designed to prevent attackers from impersonating remote services. Investigate the certificate chain, update the software, or follow the provider’s remediation instructions instead.
Replace certificates only when necessary
The incident does not justify replacing every website certificate associated with eMudhra. Website owners should inspect the actual certificate chain and consult their certificate authority or hosting provider if the affected intermediates or the related distrusted root are relevant to their deployment.
Apply the required replacement or trust-store changes based on verified evidence and vendor guidance. If a certificate is part of an affected hierarchy, the appropriate action may involve issuing a replacement through an alternative trusted authority.
What Should Ordinary Internet Users Know?
Most people do not need to examine certificate fingerprints or configure trust stores manually.
The most useful steps are:
- Keep your browser, operating system, and applications updated.
- Install security updates when your device or software vendor provides them.
- Do not ignore HTTPS certificate warnings or install unfamiliar root certificates to make a website work.
- If you use specialist networking tools, developer utilities, older devices, or business software, check whether the vendor has issued a separate security update.
Modern browsers have implemented measures to block the affected TLS intermediates. However, some applications have their own certificate-validation mechanisms, so protection can differ between programs on the same device.
You do not need to assume that every HTTPS website is unsafe. The incident concerns specific certificate authorities and the trust relationships surrounding them, rather than a general failure of HTTPS encryption.
If you manage a business website or application, however, it is important to check whether your infrastructure depends on the affected certificate hierarchy and whether the relevant software fixes have been applied.
Conclusion
The eMudhra certificate compromise demonstrates how a failure in cryptographic key generation can undermine the trust that browsers and applications place in digital certificates.
Eight intermediate certificate authority private keys were found to be recoverable because they had been generated incorrectly. That weakness created the potential for fraudulent website certificates and misuse of code-signing trust. The incident also prompted changes to the trust assigned to a related root certificate, which can affect legitimate certificates in the same hierarchy.
The available public findings do not establish widespread exploitation. eMudhra stated that the affected intermediate authorities had not issued end-entity certificates, and major technology vendors implemented protective measures after the weakness was reported.
For businesses and developers, the priority is to verify certificate dependencies, update affected software, and check that each application uses the corrected trust configuration. For ordinary users, keeping software updated and respecting certificate warnings are the most practical steps.
Digital security depends on more than strong encryption. It also requires reliable cryptographic key generation, careful certificate issuance, correct validation, and a dependable process for distributing security updates.
Resources
- Cloudflare: 8 eMudhra certificates are compromised. Here’s what you need to know . Explains the incident and its implications for the wider internet.
- Mozilla Security Blog: Protecting Firefox users following the compromise of eMudhra intermediate certificates . Documents the report and Firefox’s response.
- Cisco Talos: Compromised eMudhra intermediate certificates . Provides the technical analysis of the weak keys and affected authorities.
- eMudhra: Statement on the recent certificate security incident . Describes the company’s findings, remediation, and assessment of customer impact.
- Google Security: Protecting Chrome and Android users from compromised eMudhra intermediate CA certificates . Explains Chrome’s certificate blocking and the additional trust-store changes.
- Apple Support: About the compromised eMudhra intermediate CAs . Covers Apple’s mitigation and relevant considerations for Mac command-line tools.
- Red Hat: RHSB-2026-012, certificate compromise involving eMudhra . Explains Linux certificate trust-store risks and applicable mitigation guidance.
- Reuters: India’s eMudhra exits website security business after flaws trigger global alarm . Provides independent reporting on the incident and the company’s announced withdrawal from the global SSL/TLS certificate business.
Playful Sparkle has engineered digital products since 2004. We build and maintain websites and digital products with a focus on reliable implementation and ongoing technical maintenance. Contact Playful Sparkle to discuss your website or application requirements.
Zsolt Oroszlány
More Insights
Facebook link limits and how businesses can find customers beyond Facebook
Facebook introduced link-sharing limits for selected Pages in 2026. Learn how the restrictions affect businesses and how your website, email subscribers, and other channels can help you find customers beyond Facebook.
Critical PHP Vulnerabilities Enable Unauthenticated Remote Code Execution
On October 21, 2026, two critical PHP vulnerabilities, CVE-2026-109618 and CVE-2026-109619, were disclosed, enabling potential unauthenticated remote code execution. Learn which PHP versions are affected, how the flaws impact WordPress and other websites, and how to secure your servers.
EU AI Act: Article 50 Transparency Rules Now Apply
The EU AI Act’s Article 50 transparency rules apply from 2 August 2026. Learn which AI systems are covered, what businesses must disclose, key deadlines, penalties, and the latest compliance requirements.