When Trust Controls Fail: The Governance Questions Raised by eMudhra’s Certificate Incidents

Key facts

What: Seven Bugzilla reports, from April 2025 to October 2026, document operational and policy failures at eMudhra, an India-based digital-trust company that operated publicly trusted certificate authorities under its emSign brand, and on related issuing infrastructure.
Most serious: On 17 October 2026 a researcher reported that the private keys of eight intermediate CA certificates could be recovered. Mozilla independently recovered them. The reported private values were below 256.
What it was not: a break of the P-384 algorithm. It was a failure to generate or select strong key material.
Response: eMudhra revoked the eight intermediates on 18 October. Sectigo took steps to revoke affected cross-signed certificates. Mozilla and Chrome announced protective measures, and on 24 October Oracle removed eMudhra’s G1, G2 and G3 roots from the default Java truststore.
Latest: a public comment reported certificates signed with some of the compromised keys and logged by others after disclosure. Treat it as a report to reconcile, not an established count.
Not established: a single cause across the reports; that every eMudhra product or key is affected; a complete root cause. eMudhra’s explanation is preliminary.

Publicly trusted certificates help browsers and applications verify websites, services and software publishers. That trust depends on more than strong cryptography. Certificate authorities (CAs) must enforce their own policies, check their own work and respond openly when something goes wrong. These reports test all three.

What should enterprises do now?

Treat this as a certificate-assurance issue and a business-continuity risk.

1. Inventory dependencies. Find the systems that rely on certificate chains under eMudhra’s G1, G2 and G3 roots, including certificates from other providers that chain to them. Chrome’s analysis, cited in the Bug 2083449 discussion, counted about 30,800 unexpired precertificates chaining to the G3 root as of 21 October, almost all from two InCommon intermediates. That is a root-wide count, not a count of certificates issued by the eight compromised intermediates.
2. Check Java and other truststores. Test before applying the JDK update, or follow Oracle’s manual-removal guidance.
3. Test replacement chains and renewals. Confirm that automated renewal will replace affected certificates outside the normal renewal window.
4. Ask your provider for evidence. The questions are below.
5. Monitor the primary records. Bug 2083449 and the company’s statements change quickly. The update log records what changed here.

What happened, and when?

Date	Event
30 April 2025	eMudhra generated 24 issuing CA certificates in a key-generation ceremony. The eight intermediates implicated in the 2026 weak-key incident were generated in this ceremony.
7–10 May 2025	The publication deadline for the new issuing CAs passed on 7 May. Publication took place on 10 May (Bug 1965559). The full report gives 10 May; its summary says 9 May.
29 May–6 June 2025	Six CRLs were published with invalid signatures, reported by Sectigo and corrected on 6 June (Bug 1970728).
19–26 June 2025	An RSA key-size policy discrepancy was reported, and 449 unexpired certificates were revoked, according to the related incident records (Bug 1973341 and Bug 1974435).
14 April–18 September 2026	An InCommon issuing CA accepted key sizes that its published policy did not permit. Issuance stopped on 18 September (Bug 2073581).
14 October 2026	A separate was reported in the discussion of Bug 2083449. Its link, if any, to the weak-key incident is not established.
15 October 2026	A certificate validity discrepancy was reported concerning a certificate whose validity period was one second over the stated maximum Bug 2082408.
17 October 2026	A researcher reported eight recoverable intermediate CA private keys. Mozilla independently recovered them that day.
18 October 2026	eMudhra revoked the eight intermediates. Sectigo took steps to revoke affected cross-signed certificates.
21–22 October 2026	eMudhra published a statement and press release, then announced its exit from global SSL/TLS certificate issuance.
20–24 October 2026	Mozilla and Chrome announced protective measures. On 24 October, Oracle’s JDK update removed eMudhra’s G1, G2 and G3 roots from the default Java truststore.
20–25 October 2026	Public discussion raised questions about migration, the April 2025 ceremony and certificates signed with the compromised keys after disclosure.

The weak-key incident: what is established?

On 17 October 2026, a researcher reported that eight eMudhra intermediate CA private keys could be recovered. Mozilla independently recovered the keys without knowing the researcher’s method. The affected certificates covered TLS and code signing.

The keys were elliptic-curve keys using P-384. The algorithm is strong when used correctly, but the reported private values were all below 256. A properly generated P-384 private key is a number chosen from an enormous range. A value below 256 can be found by testing a few hundred candidates.

eMudhra said the keys originated in the ceremony of 30 April 2025 (incident statement). Its preliminary explanation described an approved deviation to test key wrap and unwrap, a code flaw, similar key labels and human error, which led to weaker keys being selected for the certificate requests. It said it revoked all eight intermediates the following day.

The exact root cause was still under investigation in the public material reviewed here. The company’s explanation is a preliminary account, not an independently verified reconstruction.

Certificates signed after disclosure

A comment posted on 25 October reported that 107,107 certificates signed with six of the compromised keys were logged by others in Certificate Transparency logs between 20 and 21 October, including 106,050 proof-of-concept certificates with google.com as a name. That is one participant’s report. This article has not independently confirmed the counts.

If it holds, it complicates any simple claim that no certificates were created with the affected keys. The distinction matters. eMudhra said it issued no end-entity certificates from the eight intermediates. The later report concerns certificates signed by others after the keys became recoverable. A complete account should say who created each artefact, whether any were final certificates, and whether any were usable in practice.

Does Oracle’s JDK update affect Java applications?

Oracle’s response is significant because it went beyond the G3 root associated with the compromised intermediates. On 24 October 2026, Oracle’s JDK 21.0.13.0.3 release notes documented the removal of three eMudhra roots from the default cacerts truststore:

• emSign Root CA - G1
• emSign Root CA - G2
• emSign ECC Root CA - G3

Oracle also removed AAA Certificate Services, a separate Comodo and Sectigo root, in the same update. Oracle’s guidance gives manual-removal steps for systems that cannot yet install the patch. See the Oracle JDK release notes.

This is not proof that every certificate under every eMudhra root was compromised. It is evidence that Oracle judged removal from its default truststore to be an appropriate protective step. For customers, a CA incident can become an application-availability problem the moment trust anchors are removed. Organisations need certificate inventories, tested replacement paths and a way to see which software depends on which chain. Chrome’s own response is described in the Google Security Blog.

The CRL incident deserves a second look

A certificate revocation list (CRL) is a signed list of certificates that should no longer be trusted. It works only if systems can verify its signature against the right issuer key.

In Bug 1970728, six CRLs for newly created TLS intermediates were published on 29 May 2025 with invalid signatures. The closure report says a manual workflow selected the wrong key configuration. The signing step raised no error, and verification after signing was not enforced for that onboarding. Sectigo reported the problem on 3 June, but its email was quarantined. A follow-up on 5 June prompted an investigation, and corrected CRLs were published on 6 June. eMudhra later reported automating CRL generation, adding post-signing cryptographic verification and monitoring quarantined email. The bug was closed as fixed.

Those were sensible corrections. The October 2026 discussion shows why “fixed” needs a second look.

• The failure involved keys, certificates and the machinery that connects them. That is the same territory as the 2026 compromise. The public record does not establish a link, but a thorough investigation should rule one in or out.
• The timing may be earlier than reported. A later comment cites an archived snapshot suggesting that some CRLs may have been failing verification before 29 May. That would need confirming from source records.
• Questions about scope remain. Was the problem confined to the six CRLs? Were there earlier instances? If a signing certificate changed between CRL issuances, what triggered the change, and who was told?
• One participant went further. A commenter alleged that other CRLs had been signed with certificates generated the same day, and that the signing certificate had been changed on a later issuance without being reported. That is an unverified observation by one person. This article does not treat it as established.
• A new invalid CRL was reported. The 14 October CRL for emSign Root TLS CA - G1 had an invalid signature. Its cause has not been established, and it should not be assumed to share a cause with either earlier event.

The governance question is not whether an incident is labelled fixed. It is whether the failure was bounded, its cause established, and the replacement control tested against the failure that actually occurred.

What do the other earlier reports show?

Policy mismatches. Bug 1973341 involved a certificate with an RSA 4048-bit key where policy wording referred to RSA 2048. That was an ambiguity between documentation and issuance, not weak cryptography. Bug 2073581 was different: certificates from InCommon RSA IGTF Server CA 4 did not meet its stated RSA 4096 requirement. The report listed 460 affected certificates, some using elliptic-curve algorithms. Together they show why policy wording must be clear and why issuance systems must enforce what the policy actually says.

Deadlines and limits. Bug 1965559 concerned the late publication of issuing CA certificates, caused by a manual review with no enforced deadline. Bug 2082408 concerned a validity period one second over the stated maximum. Neither compares to a private-key compromise. Both test whether limits are enforced by the system or left to manual checks.

These reports differ sharply in severity and cause. They do not prove a common root cause. They do raise the same control questions each time: was the requirement precise, enforced by the system, verified before publication and proven to work after the fix?

Did AI break the keys? The claim needs careful qualification

eMudhra’s 21 October press release said an independent researcher found that the weak keys could be reverse-engineered “possibly with AI-assisted techniques”. The wording is cautious, but it risks pointing readers away from the central failure.

The public evidence is simple. The reported private values were below 256, which makes the key space tiny. Mozilla recovered the keys independently, without being told the researcher’s method. Nothing in the record shows that AI was necessary, and the algorithm was not defeated. AI tools may help someone write scripts or analyse logs, but the weakness did the work.

The press release also said the infrastructure was not compromised and no data was breached. That may be true in the narrow sense of no network intrusion. It does not answer the central trust question, because a CA’s private key can be compromised cryptographically without anyone breaking into a server. A clean intrusion report is not evidence that keys were generated correctly.

Will AI-based tooling fix the problem?

eMudhra’s press release shared with BSE and NSE states that it intends to use AI-based tooling alongside conventional controls. AI can help search logs, compare policy with configuration and find anomalies. It cannot replace deterministic validation. The controls that matter are rejecting weak or unexpected key material, mapping each hardware-held key to its certificate, enforcing approved ceremony steps and verifying CRL signatures before publication. Any AI-assisted conclusion that other keys are unaffected should state its scope, its limits and whether an independent party reproduced it.

“Adopt AI” is a technology intention. “Reject the wrong key before publication and keep an independently verifiable record” is a control.

Does the weak-key requirement in the CP/CPS apply to the intermediate CAs?

Section 6.1.6 of eMudhra’s Code Signing CP/CPS (version 1.02) says: “Any known weak keys shall be tested for and rejected at the point of submission.” This is echoed in their CP/CPS documents for SSL/TLS v1.09, Trusted PKI v1.25, etc. It appears they are acutely aware of the seriousness of issuing weak keys. This begs the question how did eight weak intermediate keys get through?

The answer is not simple, and the clause does not settle it. The documents say CA keys are generated on FIPS-qualified hardware, but they do not explicitly show an equivalent weak-key test for them.

Why no such check stopped these keys is not established. eMudhra’s explanation (an approved deviation, a code flaw, similar key labels and human error) describes weaker keys produced and selected inside the ceremony. That suggests they never took a path with a “point of submission” check at all. That is an interpretation, not a finding.

The questions to put to the company and its auditors are specific:

• Which document governed CA key generation and public-key quality checks for these intermediates?
• Was any independent test of the public key’s properties performed before the root signed each request?
• Did any party in the chain, including those asked to cross-sign, test the public key?
• If the check existed, why did it not detect a private value below 256? If it did not, why was an equivalent control absent for CA keys?

Code-signing intermediates also deserve attention for their own sake. eMudhra said these two were not put into production and issued no certificates. That limits the reported use, but not the importance of the finding. A trusted code-signing CA key can be used to sign software that users and systems may trust.

Are audit logs sufficient to reconstruct the incident?

eMudhra’s Code Signing CP/CPS (section 5.4.7) says automated audit data is recorded at the application, network and operating-system levels, with integrity and availability protections. That is a useful baseline. It is not the same as having the evidence this incident needs.

Application, network and operating-system logs can show what ran, when and what failed. They do not necessarily show which key was generated, wrapped, unwrapped, selected or used to sign a particular certificate or CRL. A reconstruction would typically need:

• the exact ceremony script and version, and the approved deviation with its authorisation
• hardware security module (HSM) records and configuration, including which operations created or selected each key object
• key identifiers that map each key to its request, certificate and any cross-signed certificate
• ceremony and witness records with timestamps
• evidence that the logs are complete, protected against alteration and retained long enough

The public record does not show that these records are missing, and it would be wrong to infer that. The distinction is between having logs and having evidence that can answer the specific forensic question. A log that says a key operation succeeded may not show whether the right key was later used. A ceremony report that records approval does not prove the approved process was the one that ran.

Leaving TLS while keeping other PKI services: contradiction or trust question?

On 22 October, eMudhra announced that it would withdraw from global SSL/TLS certificate issuance and offered Sectigo-issued certificates to affected customers. It also says its Indian digital-signature and eSign services run on separate infrastructure and are unaffected.

It is not a contradiction, but it does raise a trust question. A company can leave one line of business and keep others. Publicly trusted TLS is governed by browser and root-store programmes. Indian digital-signature and eSign services operate under different frameworks and may use different infrastructure, trust anchors and controls.

The trust question. Exiting TLS reduces future exposure in that market. It does not explain the April 2025 ceremony, the 2025 CRL failure or the audit scope, and it does not show that the controls behind continuing services are sound. “Separate infrastructure” is a claim that evidence should support. Which key-generation software, ceremony scripts, HSM configurations, staff and change-management processes do the services share? Which checks, if any, were run to establish the separation?

The press release also said the hierarchy had passed two independent audit cycles. That is relevant, but it does not say which ceremonies were sampled, whether the April 2025 deviation was in scope, or whether the 2025 CRL failure was disclosed to the auditors. For customers of any eMudhra service, the right step is neither assuming everything is affected nor assuming nothing is. It is to ask for product-specific evidence of separation, key-generation assurance and incident handling.

What does the 2024 Entrust incident show about response?

The Entrust incident involved roughly 26,668 EV TLS certificates missing a required certificate-policy URI. Entrust initially argued that the requirements were inconsistent, that the omission posed no security risk and that revocation would disrupt customers. Entrust later acknowledged it should have stopped non-compliant issuance first. Chrome and Mozilla each stopped trusting newly issued Entrust certificates after cut-off dates set out in their announcements. The sources are Mozilla’s Entrust summary and Bug 1883843.

The incidents are not technically equivalent. The governance lesson is the same: a publicly trusted CA owes duties to everyone who relies on its certificates, not only to its own customers, and arguing about impact can deepen a trust crisis.

In October 2026, eMudhra said that social-media scrutiny and investor and customer analysis had made meaningful investigation “pretty much impossible”. Chrome’s representative rejected that as an explanation for delaying answers. Mozilla said it had sent questions on 20 October and, as of 23 October, had not received the requested initial response despite granting extra time. Scrutiny is a predictable consequence of a serious trust failure. Containment, evidence preservation, preliminary answers and customer communication should run in parallel, not wait for attention to fade.

What should enterprises ask their certificate provider?

1. Scope: Which roots, intermediate CAs, certificates and cross-certificates are affected, and what is the status of each?
2. Migration: How many active certificates remain to be replaced, and how will renewal be triggered?
3. Key assurance: How were the affected keys created and selected, and what independent check now proves the certified public key matches the intended strong private key?
4. Shared controls: Which other roots, products, scripts, hardware security modules and procedures were reviewed, and what supports the conclusion that they are unaffected?
5. Revocation lists: Is every signature verified before publication, and who is alerted if a check fails or an external warning is missed?
6. Reconstruction: Can the provider reconstruct the key ceremony and show which key object was used for each certificate?
7. Incident response: How quickly does the provider constrain issuance and give a preliminary account after a credible report?
8. Independent assurance: What has an independent party tested, and what remains the provider’s own assertion?

What does this mean for AI agent workflows?

Nothing in this story is about AI agents. Everything in it is about problems agents will have.

• A deadline that depends on a manual review is an approval nothing enforces. Agent approval gates need time limits, escalation and a default of “no” when nobody responds.
• A revocation list signed with the wrong key, with no check to reject it, is agent output trusted because nothing independent verifies it. Put a deterministic check between the agent and anything that acts on its output.
• A rule written in a policy but not enforced by the system is a prompt that says “never do X” while the tool allows it. Enforce rules in the tool or policy layer, not in the model.
• Logs that show activity but not which key signed what are agent logs that record outputs but not the permission that authorised the action. Log the request and the grant.
• “Fixed” should mean the new control was tested against the failure that actually occurred.

The same discipline applies wherever software acts on your behalf: assume it will be attacked, assume it will be wrong, and design so that neither becomes an incident. If you run agents that call tools or read external input, our Workflow Assessment applies this approach to one workflow.

Conclusion: trust depends on evidence, not assurances

Seven reports document different technical and policy failures. They do not prove one common cause, and they do not show that every eMudhra product is affected. The weak-key incident is the most serious because it challenges the integrity of CA keys on which certificate trust depends. Oracle’s removal of all three roots from the default Java truststore shows how far the consequences can reach into enterprise software, even though it is a broad precaution and not proof that every removed root was compromised.

For enterprise customers, the right response is neither automatic dismissal nor automatic reassurance. It is to ask for a clear account of scope, independently verifiable remediation, tested migration plans and evidence that the same failure cannot recur through another path.

Trust is not a claim that nothing will go wrong. It is the demonstrated ability to prevent failures, detect them promptly, explain them accurately and correct them in a way others can verify.

Glossary

Certificate authority (CA): an organisation that issues digital certificates and protects the keys behind them. Root CA and truststore: a root CA is a certificate that software trusts directly; a truststore is the list of roots a system trusts, such as the Java cacerts file. Intermediate CA: a CA certificate issued by a root, which in turn issues certificates to websites, services or software publishers. Certificate revocation list (CRL): a signed list of certificates that should no longer be trusted. Hardware security module (HSM): a tamper-resistant device that generates and uses cryptographic keys. Key ceremony: a controlled, documented procedure for generating CA keys. Certificate Transparency and precertificate: public logs of issued certificates; a precertificate is a record logged before the final certificate is issued, and is not proof that a final certificate exists. Cross-signing: one CA signing another CA’s certificate so that it can be trusted through a second hierarchy. CP/CPS: the Certificate Policy and Certification Practice Statement, the documents that set out a CA’s rules and practices. P-384: a standard elliptic-curve algorithm. Its security depends on private keys being chosen from an enormous range.