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

A digital certificate is one of the quiet foundations of the modern internet. When users visit secure websites, sign in to online services or exchange sensitive information with applications, Transport Layer Security (TLS) helps encrypt connections and verify service identity. That trust depends on certificate authorities (CAs), cryptographic keys, and certificate chains working as expected.

That trust model came under scrutiny in October 2026 after an independent security researcher reported that the private keys associated with eight intermediate certificate authorities operated by Indian digital trust company eMudhra could be recovered because they were cryptographically weak. The affected set comprised six TLS intermediates and two code-signing intermediates. The discovery prompted certificate revocations and trust-store actions by major browser and technology vendors.

The Hacker News reported the Board’s decision in its article, eMudhra to Exit Global SSL/TLS Business After 8 Intermediate CA Keys Found Easily Guessable. The story is significant not only because of the business decision, but because it highlights how a flaw in certificate generation can affect trust across websites, software and connected services.

For organizations, the incident is a reminder that cybersecurity and compliance do not stop at firewalls or endpoint protection. They also depend on the security practices of certificate providers, technology partners, and other external trust services.

What Happened in the eMudhra Intermediate CA Key Security Incident?

According to eMudhra’s public incident updates, the affected intermediate CAs were created during a Key Generation Ceremony on April 30, 2025. A flaw in the key-generation workflow caused a second set of weak keys to be produced during a wrap/unwrap step. Those weak keys, rather than the intended strong keys, were published in the certificate hierarchy.

In its October 21 statement, eMudhra said the affected keys were generated using FIPS 140-2 Level 3 certified Hardware Security Modules (HSMs). The company said it was investigating how the process produced the weak key set. In a leadership update published on October 26, eMudhra acknowledged that a script error resulted in issuing CAs with weak keys and apologized to customers and the wider WebPKI community.

The company’s official security incident statement and updates provide the primary account of the event, containment steps and customer transition. Its separate October 21 press release explains the affected certificate hierarchy.

Why Were the Eight Intermediate CA Private Keys Considered Weak?

A certificate authority’s private key must be generated with strong cryptographic randomness. For an elliptic-curve key, the private value should be selected from an extremely large mathematical range. If the value is predictable or drawn from a very small range, an attacker may be able to calculate the private key from publicly available certificate information.

The technical details documented in Mozilla’s public security discussion indicate that the eight affected P-384 private-key values were below 256. That made the keys practically recoverable rather than computationally infeasible to guess. The researcher demonstrated control of the keys through proof that could be verified by the receiving parties. Mozilla also reported independently recovering the keys.

The public Mozilla Bugzilla incident record contains technical discussion, certificate identifiers, proof-of-key-control references, and stakeholder comments. It is useful evidence because it documents the response process rather than relying only on secondary reporting.

"This was a cryptographic key-generation failure. It should not be described as a conventional network intrusion or as proof that an attacker breached eMudhra’s internal systems. The risk came from the possibility that someone could derive the affected private keys and create unauthorized certificates that might be accepted by systems trusting the relevant certificate chain."

— Cryptographic Architecture Analysis

Which SSL/TLS and Code-Signing Certificates Were Affected?

The incident involved eight intermediate certificate authorities under eMudhra’s G3 certificate hierarchy:

• Six TLS intermediates: Domain Validation (DV), Organization Validation (OV) and Extended Validation (EV) certificate authorities across the G3B and G3C series.
• Two code-signing intermediates: OV Code Signing (CS) authorities in the G3B and G3C series.

TLS certificates help authenticate websites and secure network connections. Code-signing certificates help operating systems and users verify the publisher and integrity of software. A compromised TLS intermediate could potentially be used to issue fraudulent website certificates; a compromised code-signing intermediate could potentially make malicious software appear to have a trusted publisher.

The technical breakdown is also available in the Kudelski Security Research Center advisory, which lists the eight affected intermediates.

How Could Weak Certificate Authority Keys Put Websites and Software at Risk?

A certificate authority is part of the trust infrastructure that browsers, operating systems and applications use to decide whether a digital certificate should be accepted. If an attacker obtains an intermediate CA private key, they may be able to sign unauthorized certificates beneath that authority. Depending on certificate usage and whether client systems still trust the chain, this can create several risks:

• Website impersonation: A fraudulent certificate could make an attacker-controlled website appear to have a trusted identity.
• Man-in-the-middle (MitM) exposure: In certain circumstances, attackers could attempt to intercept or manipulate encrypted communications by presenting a trusted-looking certificate.
• Software publisher impersonation: A compromised code-signing key could be abused to sign malicious software or files, so they appear to originate from a trusted publisher.
• Legacy trust-store exposure: Systems that do not receive updated revocation or trust-store information may continue to rely on an affected certificate chain.

These are potential capabilities associated with compromised CA private keys. They do not establish that the keys were used in real-world attacks. eMudhra said that no end-entity certificates had been issued from the affected intermediates and that it had found no infrastructure compromise or customer data breach.

What Did eMudhra Confirm About the Incident and Its Business Exit?

eMudhra said it revoked all eight affected intermediate CAs on October 18, 2026, after receiving the report on October 17. The company stated that the affected intermediates had not issued publicly trusted end-entity certificates. It also said its infrastructure had not been compromised and no customer data was breached.

On October 22, eMudhra announced that its Board had decided to voluntarily withdraw from the global SSL/TLS certificate business. The company said this business contributed approximately 1% of global revenue and had become more complex and costly because of data-sovereignty and compliance requirements, alongside competitive pressure from providers offering certificates at no charge.

The business decision is documented in eMudhra’s official announcement to exit the global SSL/TLS certificate business. The company said it would support affected customers with replacement certificates and continue relevant revocation and status services during the transition.

The exit announcement should not be interpreted as eMudhra shutting down all its digital trust operations. The company stated that its India digital signature certificate (DSC) and eSign services, as well as enterprise products including emSigner, CertiNext, SecurePass and PrivaTrust, were not affected. CERT-In’s advisory also distinguishes the browser-trusted global certificate business from India-regulated DSC and eSign services.

What Did CERT-In, Mozilla, Google and Microsoft Do After the Incident?

The incident became a coordinated WebPKI response involving the certificate authority, independent researchers, browser root programs and technology vendors. Their public records provide evidence of how the issue was assessed and contained:

• CERT-In official advisory — Identifies the affected intermediate CAs, explains potential fraudulent TLS certificates and MitM risks, and clarifies that India’s regulated DSC and eSign services were not impacted.
• Mozilla public security discussion — Records the initial report, proof-of-key-control validation and Firefox blocking actions through OneCRL.
• Google Chrome Root Program response — Describes Chrome’s corroboration and CRLSet update to block the six TLS-issuing intermediate public-key hashes.
• Microsoft Security Response Center — Explains the six TLS and two code-signing keys and details Windows and Edge trust protections. Microsoft clarified the incident originated in eMudhra’s hierarchy, not Microsoft systems.
• NHS England Digital – Cyber Alert CC-4880 — Provides an operational summary, threat severity and remediation advice for organizations.
• Palo Alto Networks Unit 42 — Explains technical impact and recommends auditing PKI assets, trust stores, code repositories, certificate lifecycles, identity logs and Certificate Transparency monitoring.
• ICRA rating update published by eMudhra — Records the incident and Board decision to exit global TLS while retaining stated credit ratings.
• The Indian Express independent news coverage — Provides additional Indian news reporting on the business exit and security implications.

Why the eMudhra Incident Is a Third-Party Risk Management and Compliance Issue

For enterprises, the incident illustrates a wider point: a trusted certificate authority is a critical external dependency. Organisations may rely on third-party CAs for public-facing websites, APIs, cloud services, VPN gateways, software distribution, device identity and internal application security. If a supplier’s key-generation process or certificate governance fails, the impact can extend beyond the supplier to customers and downstream relying parties.

This makes certificate authority security relevant to third-party risk management (TPRM). A vendor assessment should not stop at a supplier’s security questionnaire or a general statement that it follows industry standards. It should examine how the supplier generates, stores, rotates, revokes and monitors cryptographic keys, and how it communicates incidents that may affect the organization's trust dependencies.

The incident also shows why audit evidence and operational validation matter. eMudhra said the relevant hierarchy had undergone independent audit cycles and had been present in browser trust lists before the weakness was discovered. The event therefore raises governance questions about whether key-generation controls, independent verification, audit scope, and continuous monitoring were sufficient to detect the flaw earlier. The full root-cause review is the appropriate place to establish exactly which controls failed and why.

Organisations can map these issues to relevant control objectives in ISO/IEC 27001, SOC 2 and the NIST Cybersecurity Framework. These frameworks do not automatically certify a CA or guarantee that a particular cryptographic implementation is safe; organizations still need evidence that controls are appropriately designed, implemented and monitored.

What Should Organizations Do to Manage SSL/TLS Certificate and PKI Risks?

Organizations that use public or internal certificates should treat the incident as a prompt to review certificate inventories and trust dependencies. Practical actions include:

• Build a complete certificate inventory: Identify public-facing websites, APIs, VPNs, load balancers, cloud workloads, mobile apps, containers, internal services and devices that rely on third-party or internal CAs.
• Check certificate chains and issuers: Identify certificates that chain to affected eMudhra G3 intermediates or roots and verify current status using trusted vendor guidance and certificate-management tooling.
• Replace affected certificates where required: Obtain replacement certificates through a currently trusted CA hierarchy and validate deployment across production, staging, disaster-recovery and partner-connected environments.
• Update trust stores and software: Apply browser, operating system, runtime, application and vendor updates. Pay particular attention to disconnected devices, embedded systems, containers, and applications that maintain custom trust stores.
• Review certificate revocation behavior: Confirm applications check revocation status correctly and do not continue trusting blocked certificates through stale or locally overridden trust settings.
• Strengthen certificate lifecycle management: Track issuance, expiry, renewal, revocation, ownership and dependencies through a centralized certificate lifecycle management process.
• Assess CA and cryptographic suppliers: Review vendor due diligence, key-generation procedures, HSM governance, separation of duties, independent testing, incident notification commitments, and business-continuity arrangements.
• Maintain audit-ready evidence: Preserve certificate inventories, change records, revocation checks, supplier assessments, exception approvals, remediation tickets, and control-testing evidence.
• Monitor unusual certificate activity: Use Certificate Transparency monitoring, issuance alerts and network/security telemetry to detect unexpected certificates or trust-chain changes.

How Continuous Third-Party Risk Monitoring Can Help Prevent Similar Governance Gaps

The eMudhra incident demonstrates why third-party risk cannot be treated as a one-time onboarding exercise. A supplier may pass an assessment at the start of a relationship, but its security posture, technology dependencies, cryptographic processes and regulatory exposure can change over time. Continuous monitoring helps organizations identify material developments and reassess the risk posed by critical providers.

For certificate and PKI dependencies, this means tracking vendor security advisories, certificate authority changes, revocation events, trust-store updates, audit findings, service continuity and remediation commitments. Risk teams should connect these signals to business services so that a certificate issue affecting a critical API or customer portal is prioritized according to operational impact.

Telemetria helps organizations strengthen third-party risk management through structured vendor assessments, risk intelligence, continuous monitoring, risk scoring, compliance mapping, and audit-ready reporting. By bringing supplier information and risk signals into a consistent process, teams can improve visibility into external dependencies, document decisions, and follow remediation actions.

How the eMudhra SSL/TLS Incident Connects to ISO 27001, SOC 2 and NIST Compliance

The incident offers practical control themes that organizations can map to their compliance programmes:

• Supplier and third-party security: Assess critical service providers, document security requirements and review assurance evidence relevant to the service.
• Cryptographic controls: Define approved cryptographic practices, key-generation requirements, key custody, protection, rotation and revocation processes.
• Access and change governance: Restrict privileged access to key-generation systems and maintain traceable approvals and logs for sensitive operational changes.
• Monitoring and incident management: Establish detection, escalation, communication and remediation processes for certificate or trust-store events.
• Business continuity: Maintain alternative certificate providers or a tested migration route for critical services dependent on a single CA.
• Evidence and accountability: Retain risk assessments, supplier reviews, exception approvals, audit results, incident records and closure evidence.

What This Incident Teaches Organizations About Digital Trust

The eMudhra case shows that digital trust depends on more than the presence of a valid-looking certificate. It depends on secure key generation, strong cryptographic randomness, reliable operational procedures, effective independent review, and timely coordination across the ecosystem. A weakness in one intermediate CA can create consequences for browsers, software publishers, website operators and organizations that depend on those trust chains.

The company’s decision to exit global publicly trusted SSL/TLS issuance is a major business response, while the customer transition and independent review remain important parts of the remediation story. Organisations should use the incident to reassess their certificate dependencies, vendor assurance processes and ability to respond when a trusted supplier’s security posture changes.

For Telemetria, the broader lesson is clear: third-party risk management must extend to the technology and trust services that keep digital operations running. Continuous visibility, evidence-based assessments and accountable remediation help organizations move from periodic vendor checks to more resilient risk governance.

About Telemetria and ShielderSoft

Telemetria is an AI-powered third-party risk management and risk intelligence platform designed to help organizations assess vendors, monitor emerging risks, map supplier controls to compliance requirements and maintain audit-ready visibility. Learn more at Telemetria.

Telemetria is a product of ShielderSoft, a cybersecurity company focused on helping businesses strengthen their security and technology risk posture.

Frequently Asked Questions About the eMudhra SSL/TLS Incident