eMudhra Certificate Incident Explained: How Weak Cryptographic Keys Put Internet Trust at Risk

On October 17, 2026, security researchers reported a serious certificate security incident involving eMudhra, an Indian digital trust services provider whose certificates are used within the global public key infrastructure (PKI).

The investigation revealed that private keys associated with eight eMudhra intermediate certificate authorities had been generated with insufficient cryptographic randomness. The resulting private keys were so predictable that researchers could recover them from the corresponding public keys.

This was not a case in which an attacker necessarily had to breach a server, steal a hardware security module, or infiltrate a certification authority's internal network. The problem was more fundamental: the mathematical secrets that established trust in the affected certificates were weak from the moment they were generated.

The consequences were significant. Anyone who recovered an affected private key could potentially create fraudulent certificates for websites or software publishers. If a client continued trusting those certificates, an attacker positioned to intercept network traffic could impersonate legitimate services.

Browser vendors responded by blocking the affected certificates, and eMudhra revoked them. Subsequent trust-store changes introduced a wider compatibility challenge for legitimate certificates issued under the affected trust hierarchy.

This report examines what happened, how the cryptographic failure worked, why it matters, how the industry responded, and what website owners, developers, and system administrators should do.

Incident at a glance

Sources: Mozilla Security Blog, Google Security Blog, and CERT-In advisory.

1. Understanding the Incident

To understand the seriousness of the incident, it helps to distinguish between a website certificate and a certificate authority.

When someone visits an HTTPS website, their browser needs to verify that the server presenting the certificate is authorised to represent the requested domain. This verification is based on a chain of trust.

At the top of that chain is a trusted root certificate authority. The root can authorise an intermediate certificate authority, which can then issue certificates to websites or other entities within the permissions granted to it.

The chain allows browsers to trust certificates issued by organisations they have never directly interacted with.

eMudhra operates in this ecosystem through its global TLS certificate business. The affected intermediate certificates were associated with the company's public trust infrastructure.

The incident involved eight intermediate CA certificates whose corresponding private keys could be recovered because they were generated with insufficient entropy.

According to Mozilla's investigation, the certificates originated from a batch created on April 30, 2025. They remained within the broader browser trust ecosystem until the weakness was reported in October 2026.

The issue was therefore not simply that a certificate had expired or that a website had configured HTTPS incorrectly. It concerned the integrity of cryptographic keys used to establish trust between systems.

For more details, see Mozilla's incident investigation.

2. What Is a Certificate Authority?

A certificate authority, commonly abbreviated CA, is an organization authorized to issue digital certificates under a defined trust framework.

Digital certificates are used for more than HTTPS websites. Depending on the certificate type and issuing authority, they can support software signing, device authentication, secure communications, and other identity-related functions.

A simplified public TLS trust hierarchy looks like this:

Root certificate authority

↓

Intermediate certificate authority

↓

Website TLS certificate

↓

Browser validates the certificate chain

A root certificate is generally distributed through a browser, operating system, or application trust store. Intermediate certificates allow the root authority to delegate certificate issuance without using its root signing key for every operation.

This separation is an important security measure. Root private keys are highly sensitive, while intermediate authorities provide operational flexibility for issuing certificates.

However, an intermediate CA is itself powerful. If an attacker obtains its private key, the attacker may be able to sign certificates for domains that the attacker does not control, subject to the certificate's constraints and the trust policies enforced by clients.

That is why an intermediate certificate's private key must be protected with the same seriousness as any other critical trust infrastructure secret.

3. The Root Cause: Predictable Private Keys

The central technical finding was a failure in cryptographic key generation.

eMudhra's public statement describes a key generation ceremony conducted on April 30, 2025. The company said a flaw in a wrapping and unwrapping step produced a second set of weak keys alongside the intended strong keys. The weak keys were subsequently used in the affected certificates.

The company stated that the ceremony used hardware security modules and that its investigation was continuing to establish the complete root cause.

Mozilla independently confirmed that the private keys associated with the affected intermediate certificates could be recovered. Its investigation found that the affected P-384 private key values were smaller than 256.

This is the critical detail.

A cryptographic algorithm can be mathematically strong while a particular implementation uses it insecurely. In this case, the weakness was not a demonstrated break of the P-384 elliptic-curve algorithm itself. It was a failure to generate private keys with the required unpredictability.

What should a private key look like?

Cryptographic private keys must be selected from an appropriately large mathematical space using a secure random generation process.

For P-384, the private key is an integer selected from a range determined by the elliptic curve's order. The possible valid values form an enormous space, making recovery from the public key computationally infeasible when the key is generated correctly.

The public key is derived from the private key through an elliptic-curve operation. That operation is designed to be straightforward in one direction but computationally infeasible to reverse when the private key is properly chosen.

The incident violated the assumptions behind that protection.

Instead of values drawn securely from the intended range, the affected keys were extremely small integers. Mozilla reported that the private values were below 256, making recovery trivial compared with the intended cryptographic security level.

The weakness can be summarized as follows:

• Expected behavior: Generate a private key using a cryptographically secure process and the full permitted key space.
• Observed weakness: Generate private key values from a tiny subset of that space.
• Consequence: An observer with the public key can recover the private key through a small search rather than solving the intended cryptographic problem.

This is a failure of key generation, not proof that all elliptic-curve cryptography is broken.

Why hardware security modules were not enough

Hardware security modules, or HSMs, are specialized devices used to generate, store, and perform operations with cryptographic keys. They can provide strong protection against key extraction and unauthorized signing.

However, an HSM does not make every surrounding process automatically correct.

The incident illustrates why secure key management requires more than deploying certified hardware. The generation software, key selection, export procedures, labels, verification steps, and operational controls must all preserve the intended security properties.

If an incorrect key is selected and then used to create a publicly trusted certificate, the HSM's physical security does not restore the missing cryptographic entropy.

eMudhra's investigation identified a flaw involving a wrapping and unwrapping step and a second set of weak keys. The company also acknowledged that the incident involved human errors across multiple stages of its key lifecycle process in its response to Mozilla.

Sources: eMudhra's statement and Mozilla's technical investigation.

4. How Weak Keys Could Be Recovered

Under normal circumstances, recovering a correctly generated elliptic-curve private key from its public key is considered computationally infeasible with conventional computing resources.

The incident changed the problem dramatically because the private values were extremely small.

An attacker does not need to search the entire theoretical key space if the secret was selected from a tiny subset. The attacker can instead test candidate values and compare the derived public keys with the public key published in the certificate.

The search becomes small enough to complete almost instantly.

Mozilla reported independently recovering the affected keys during its investigation. Security researchers also publicly described reproducing the recovery.

This demonstrates a crucial principle in cryptography:

The security of a cryptographic algorithm depends on how it is implemented and how its keys are generated, not just on the algorithm's name or nominal key length.

A certificate may advertise a modern cryptographic algorithm and still be insecure if its private key is predictable.

Does this mean P-384 is broken?

No. The publicly documented findings identify weak private key generation as the cause, not a general weakness in the P-384 algorithm.

A correctly generated P-384 key remains a different security proposition from one whose private value can be recovered by searching a few hundred candidates.

The distinction matters because replacing a cryptographic algorithm without correcting the generation process would not necessarily solve the underlying operational problem.

The correct response includes verifying key generation, checking that the correct keys are associated with the correct certificates, and validating the complete certificate lifecycle.

5. Why Intermediate CA Keys Are So Sensitive

An ordinary website certificate generally identifies a specific domain or set of names. An intermediate CA certificate can have much broader authority to issue other certificates.

If a trusted intermediate CA's private key is compromised, an attacker may be able to sign a certificate that appears to authenticate a domain the attacker does not own.

Consider a hypothetical example.

A user visits a legitimate banking website. The browser normally verifies that the certificate presented by the server chains to a trusted certificate authority and is valid for the requested domain.

If an attacker has a usable private key belonging to a trusted intermediate CA, the attacker could potentially create a fraudulent certificate for that banking domain.

If the attacker can also intercept or redirect the user's network connection, and the user's software continues trusting the fraudulent certificate, the attacker may be able to impersonate the site.

This does not mean every visitor to every affected website was automatically exposed. Successful exploitation would depend on the certificate chain remaining trusted by the client and the attacker's ability to place themselves in a position to intercept or redirect traffic.

Nevertheless, the ability to create trusted fraudulent certificates is a serious threat because it attacks the identity verification mechanism on which HTTPS depends.

6. The Potential Impact on HTTPS and Code Signing

The eight affected intermediate certificates were not all used for the same purpose.

The public investigations identify six TLS intermediates and two code-signing intermediates.

TLS certificate forgery

TLS certificates establish the identity of servers and help protect communications against interception.

If an attacker can use a compromised intermediate CA key to issue a fraudulent certificate, the attacker may attempt to impersonate a website or service.

Potential consequences include:

• Credential theft through a convincing impersonation of a legitimate service.
• Exposure of sensitive information in connections intercepted by an attacker.
• Manipulation of responses or downloaded content.
• Attacks against APIs or other TLS-protected services.
• Loss of confidence in the affected certificate trust hierarchy.

A fraudulent certificate does not, by itself, decrypt an existing TLS session. An attacker must also be able to establish the relevant network position or otherwise intercept traffic, and the client must accept the certificate.

Code-signing certificate forgery

Code-signing certificates serve a different purpose. They allow software publishers to sign code so that supported operating systems and applications can verify the publisher's identity and detect unauthorized changes to the signed content.

A compromised code-signing intermediate could potentially allow an attacker to issue fraudulent code-signing certificates under the affected trust chain.

Depending on the platform and its policy, this could make malicious software appear to have a trusted publisher identity.

Code signing is not a guarantee that software is safe. It is a mechanism for establishing identity and integrity under a particular trust policy.

This is why certificate revocation and trust-store updates matter beyond web browsers. Software distribution systems, developer tools, operating systems, and endpoint protection products may also rely on certificate trust.

CERT-In's advisory discusses the potential impact on both TLS and code-signing trust. See the official CERT-In advisory.

7. Did Attackers Actually Exploit the Certificates?

This question requires a distinction between a demonstrated capability and confirmed malicious activity.

The publicly available disclosures establish that the private keys were recoverable and that they could be used to create fraudulent certificates. That makes the incident a serious trust failure regardless of whether a criminal used the keys before they were blocked.

However, the available public disclosures as of October 22, 2026, do not establish confirmed malicious exploitation of the affected keys.

Google reported that no TLS certificates chaining to the six affected TLS intermediates had appeared in Certificate Transparency logs before its blocking action. eMudhra also stated that the affected intermediates had not issued end-entity certificates.

These are important findings, but they should not be interpreted as proof that every possible form of abuse was impossible.

Certificate Transparency logs record publicly trusted TLS certificate issuance covered by the relevant logging requirements. They do not record every possible event involving private keys, and they are not a universal audit log for code signing or every private certificate ecosystem.

The responsible conclusion is therefore that the weakness was confirmed, the keys were recoverable, and the potential for fraudulent issuance was real. Confirmed malicious use was not established in the cited public disclosures at the time of writing.

This distinction is important in security reporting. A serious vulnerability should not be understated, but a demonstrated exploit capability should not be presented as proof that a particular victim was attacked.

8. Timeline of the Incident

The public record identifies the following major events.

April 30, 2025: Key generation ceremony

eMudhra generated the batch of intermediate CA keys involved in the incident. According to the company's statement, a problem during the key generation process produced a second set of weak keys.

The affected certificates subsequently entered the global certificate trust ecosystem.

May 2025: Earlier certificate-related warning signs

Mozilla's investigation referenced an earlier issue involving certificate revocation list signatures associated with the affected intermediates.

In the public discussion, eMudhra explained that the correct keys had produced invalid signatures for those lists and that the lists were subsequently signed using the flawed keys.

This earlier event became relevant to the later investigation because it raised questions about the integrity checks and operational processes surrounding the same intermediate certificates.

October 17, 2026: The weakness was reported

Mozilla received a report concerning the private keys associated with eight eMudhra intermediate certificates. The report included evidence of key recovery.

Mozilla independently reproduced the finding and began blocking the affected certificates in Firefox.

Google's Chrome Root Program also investigated and confirmed the issue.

October 18, 2026: eMudhra revoked the affected certificates

According to CERT-In's advisory and eMudhra's public communications, the affected intermediate certificates were revoked as the response progressed.

October 19 to 20, 2026: Broader browser and trust-store response

Google expanded its protective measures for Chrome and Android. Mozilla published its security response and distributed protections through Firefox's OneCRL mechanism.

Apple and Microsoft were also notified and took part in the broader response through their respective trust programs.

Mozilla announced additional trust-store changes to protect software that might not receive intermediate-certificate blocking updates.

October 21, 2026: CERT-In published its advisory

CERT-In issued an advisory describing the incident, its potential impact, and recommended defensive actions. eMudhra also published further information about the affected global TLS business and the distinction between that business and its Indian digital signature and eSign services.

October 22, 2026: Remediation continues

The incident remains relevant to website operators, software vendors, system administrators, and developers because certificate trust is implemented across a wide range of browsers, operating systems, runtimes, containers, and applications.

The response therefore extends beyond revoking eight certificates. It also requires ensuring that affected clients no longer trust the compromised keys and that legitimate services migrate away from trust paths being removed.

Sources: Mozilla, Google, CERT-In, and eMudhra.

9. How Browser Vendors Responded

Revoking a certificate at the issuing authority is important, but clients must also receive and enforce the information that the certificate is no longer trusted.

Browser vendors maintain their own trust stores and revocation mechanisms. They can use these systems to block certificates or certificate authorities that are no longer considered safe.

Google Chrome and Android

Google reported receiving the incident report on October 17, 2026.

Chrome's response included an update to CRLSet that blocked the Subject Public Key Information, or SPKI, hashes of the affected intermediate CA keys.

SPKI identifies the public-key information contained in a certificate. Blocking by the affected public keys allows clients to reject certificates using those keys, rather than relying exclusively on the certificate's serial number or waiting for every individual certificate to be replaced.

Google also deployed equivalent protections to supported Android devices through Google Play services.

Google subsequently announced removal of the emSign ECC Root CA - G3 certificate from the Chrome Root Store. That change is expected to affect some legitimate certificates chaining to the root, and Google advised affected website operators to migrate to an unaffected trust hierarchy.

According to Google's October 22 announcement, the root-store removal was expected to reach devices relying on the Chrome Root Store on October 27, 2026, with earlier availability on prerelease channels.

This scheduled change is distinct from the initial blocking of the affected intermediate public keys.

Source: Google Security Blog.

Mozilla Firefox

Mozilla reported receiving the incident information on October 17, 2026.

The Firefox team blocked the affected intermediates through OneCRL, Mozilla's centralised certificate-blocking mechanism. Mozilla reported that the update reached users with standard configurations in less than three hours.

Mozilla also released Firefox 158.0.1 for desktop and Android, Firefox ESR 115.43.1, and Firefox ESR 153.5.1 to extend protection to users whose configurations might prevent them from receiving OneCRL updates.

In addition, Mozilla updated its Network Security Services certificate trust list to remove the root certificate that signed the affected intermediates. This helps protect applications that use Mozilla-derived trust stores but do not receive Firefox's OneCRL updates.

Source: Mozilla Security Blog.

Apple and Microsoft

The affected root programs were notified as part of the incident response. Their certificate trust policies and updates are relevant to users of Apple operating systems, Microsoft Windows, and software that relies on their trust stores.

Administrators should apply the current security and trust-store updates provided by the relevant vendors rather than assuming that one browser's protection automatically applies to every application on the device.

The broader lesson is that certificate revocation is an ecosystem-wide process. The issuing authority, browsers, operating systems, application runtimes, and software vendors all have different responsibilities.

10. Why Revocation Alone Is Not Enough

Certificate revocation is a mechanism for communicating that a certificate should no longer be trusted.

In practice, revocation does not guarantee that every client will reject the certificate immediately.

Different clients use different methods to check certificate status. Some receive centralised browser updates. Others rely on certificate revocation lists, Online Certificate Status Protocol responses, cached data, bundled trust stores, or vendor-specific policies.

Some applications do not consistently retrieve or enforce revocation information. Others bundle their own certificate authorities rather than relying on the operating system's trust store.

This creates a difficult situation during a major CA incident. Even after a certificate has been revoked, some software may continue to trust it until its local trust information is updated or its validation policy changes.

The response must therefore include several layers:

• Revoke the affected certificates.
• Block the affected keys or certificates in client trust systems.
• Remove or distrust affected trust anchors where necessary.
• Update software and certificate bundles that depend on those trust systems.
• Replace legitimate certificates that are no longer trusted under the revised hierarchy.

This is also why simply renewing a website certificate under the same affected trust hierarchy may not be sufficient. The replacement must chain to an unaffected and trusted authority.

11. The Broader Impact of Removing a Root Certificate

One of the most important developments in the incident is the decision to remove emSign ECC Root CA - G3 from certain trust stores.

A root certificate is a trust anchor. When a browser or application removes a root from its trusted set, certificates that depend on that root may cease to validate, even if the individual website certificates were legitimately issued and their private keys were not compromised.

This can create compatibility problems for websites and services that rely on the affected hierarchy.

Google explicitly warned that some legitimate certificates chaining to the root would stop working in Chrome following the planned removal.

Website operators should not wait for their certificates to begin failing. They should inventory their certificate chains and obtain replacements from an unaffected public CA hierarchy where necessary.

The same principle applies to API clients, internal services, network appliances, and software that maintains a separate CA bundle.

For operators of embedded devices or older software, the challenge can be greater because trust-store updates may depend on firmware releases or vendor support.

The correct response is to verify the chain used by the actual application and plan the migration before the applicable trust-store change reaches the production environment.

12. Does This Affect India's Digital Signature Certificates and eSign Services?

This is an important distinction for Indian users.

eMudhra operates in two different areas relevant to this incident:

1. Indian Digital Signature Certificate and eSign services regulated under India's domestic framework.
2. Global public TLS certificate services used to secure websites and other online communications.

CERT-In's advisory states that the reported incident concerns the second area and that eMudhra's Indian DSC and eSign services are not impacted.

eMudhra has also stated that the global TLS infrastructure is separate from its Indian DSC and eSign infrastructure, with different keys and operational arrangements.

The incident should therefore not be described as a compromise of every eMudhra service or as evidence that all Indian digital signature certificates are affected.

The documented issue concerns a specific set of intermediate certificates within the global public trust infrastructure.

That distinction matters for organizations using Indian digital signature services for government filings, business processes, or document signing. They should follow the applicable official advisories rather than infer that those services are affected simply because they share the same corporate name.

Sources: CERT-In advisory and eMudhra's statement.

13. What Website Owners Should Do

Website owners should determine whether their current TLS certificate chain depends on the affected intermediates or the root scheduled for removal.

Inspect the certificate chain

Review the certificate presented by the production website and identify its issuing intermediate and root hierarchy.

A basic OpenSSL inspection can help display the certificate chain presented by a server:

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

Replace example.com with your own domain.

This command displays certificates presented during the TLS handshake. It does not, by itself, prove that every client trusts the chain or that every affected certificate has been identified. Check the chain against current vendor guidance and the actual trust store used by your clients.

Replace affected certificates

If a website's certificate depends on the affected trust hierarchy, contact the certificate provider and obtain a replacement certificate chaining to an unaffected, trusted CA.

Install the replacement certificate and any required intermediate certificates. Then test the complete chain using the relevant browsers and application clients.

Do not simply install another certificate that still depends on a trust anchor being removed.

Monitor for trust errors

Following a certificate or trust-store change, monitor:

• Browser certificate warnings.
• TLS handshake failures.
• API connection errors.
• Certificate validation errors in application logs.
• Failures in monitoring probes and external integrations.

A successful test in one browser does not prove that every client, mobile application, container, or API consumer will behave identically.

14. What Developers and System Administrators Should Do

The incident is not limited to websites. Any software that validates TLS certificates or uses code-signing trust may depend on the affected trust hierarchy.

Developers and administrators should review their complete software stack.

Update operating systems and certificate bundles

Apply security updates and current certificate trust-store packages supplied by the operating-system vendor.

Red Hat, for example, published guidance for updating its ca-certificates package to address the affected trust relationships. Other distributions and vendors may distribute their own updates.

Reference: Red Hat security advisory.

Review programming-language runtimes

Applications may obtain trusted certificates from the operating system, a runtime, a TLS library, or a bundled CA file.

Examples include applications built with Go, Java, Python, Node.js, PHP, and other languages. Their behavior depends on the relevant runtime, library, application configuration, and platform.

Do not assume that upgrading an application dependency automatically updates every certificate trust source used by the application.

Inspect the actual certificate-validation path and update the relevant packages or bundles.

Rebuild containers and redeploy services

Container images may include a snapshot of the operating system's CA certificates. Updating the host does not necessarily update those files inside an already-built image.

Rebuild affected images, redeploy the relevant services, and restart processes where necessary to ensure that updated trust information is loaded.

Review code-signing trust

Organizations that distribute software should also assess whether their verification process depends on the affected code-signing intermediates.

Use current vendor updates, verify certificate chains and revocation status, and review software provenance where appropriate.

Never disable certificate verification

If an application begins reporting certificate errors after a trust-store update, do not resolve the problem by turning off TLS verification or accepting arbitrary certificates.

That would remove an essential protection against impersonation and could make the application vulnerable to exactly the class of attack that the trust-store changes are designed to prevent.

Instead, identify the failed trust path and migrate to a valid certificate chain.

15. What the Incident Teaches Us About Cryptographic Engineering

The eMudhra incident is an example of why cryptographic security must be evaluated across the entire lifecycle of a key.

A strong algorithm and a certified hardware device are important, but they are only parts of a larger system.

A secure certificate authority must also ensure that:

• Private keys are generated using approved cryptographically secure procedures.
• Key-generation software and scripts behave as intended.
• The correct private key is associated with the corresponding public key and certificate.
• Key labels and identifiers cannot lead to accidental substitution.
• Independent verification detects unexpected or weak key parameters.
• Certificate signing and revocation-list signing are tested correctly.
• Operational procedures enforce separation of duties and meaningful checks.
• Incident response can rapidly revoke affected certificates and coordinate with trust-store operators.

The incident also demonstrates the value of external review. The public key was sufficient to reveal that the underlying private key did not meet the expected security properties.

For certificate authorities, validating the cryptographic properties of generated keys should be a fundamental requirement rather than a final optional check.

For software developers, the broader lesson is that cryptography is only as reliable as the key generation, storage, handling, and validation surrounding it.

16. What Happens Next?

The immediate response focused on blocking the affected keys, revoking the intermediate certificates, and updating trust stores.

The longer-term work includes determining the full root cause, reviewing key-generation procedures, assessing related certificates, and migrating legitimate services away from affected trust paths.

eMudhra has stated that it is investigating the failure in its key generation process and reviewing its controls. Mozilla's investigation also raised questions about earlier certificate-related errors involving the same intermediates.

The incident may therefore have implications beyond the eight affected certificates. A central question for the industry is how to establish confidence that other keys generated through related procedures were not affected by the same failure.

This does not mean that all of eMudhra's certificates are compromised. The public findings identify a specific set of affected intermediates, and the company has stated that its other services and certificate infrastructure are separate.

However, certificate authorities and trust-store operators must base trust decisions on verifiable evidence. The security of the wider ecosystem depends on confidence that keys are generated correctly, certificates are properly controlled, and failures can be identified before they undermine public trust.

Conclusion

The eMudhra certificate incident is a serious reminder that the security of HTTPS depends on much more than strong encryption algorithms.

Eight intermediate CA certificates were affected because their private keys had been generated with insufficient cryptographic randomness. Researchers were able to recover the keys, creating the potential for fraudulent TLS and code-signing certificates.

The response involved certificate revocation, browser-level blocking, operating-system and trust-store changes, and plans to migrate legitimate certificates away from affected trust paths.

The incident does not establish that every eMudhra service was compromised, nor does the available public record establish confirmed malicious exploitation of the affected keys. eMudhra's Indian DSC and eSign services were reported unaffected.

For website operators and developers, the practical priorities are clear: update trust stores, inspect certificate chains, replace affected certificates, and verify the behavior of the actual applications that rely on those certificates.

For the broader industry, the lesson is deeper. Trust infrastructure depends on correct implementation, strong operational controls, and independent verification. A certificate authority must not only protect its keys from theft. It must ensure that those keys are cryptographically sound from the moment they are created.

When a trusted private key can be recovered from its public counterpart, the failure is not merely a server security problem. It is a failure in the foundation used to establish digital identity.