Black October: Investigating Certificate Trust — eMudhra
Part 5 — eMudhra: When a Trusted Seal Can Be Forged
In the previous parts of this series, we explored memory-safety failures, a compromised software release, and vulnerabilities in application components.
This time, the starting point is trust.
An application connects to a service and receives a certificate. Before sending sensitive information, it must decide whether that certificate provides an acceptable identity for the other end of the connection.
What happens when an authority trusted to approve those identities has recoverable private keys?
For incident responders, the question becomes:
Which clients still trusted the affected certificates, and is there evidence that this trust was abused?
What Happened?
In October 2026, private keys associated with eight eMudhra intermediate Certificate Authority certificates were reported compromised.
Google confirmed that the keys had been generated with insufficient randomness. This weakness made it possible to forge HTTPS certificates that vulnerable clients could accept.
This does not mean that private keys can normally be calculated from public certificates. The problem was the flawed generation of these particular keys.
First, Imagine an Office Receptionist
Imagine an office where visitors present identity cards.
The receptionist does not personally know every visitor. Instead, they trust cards approved by an authorized issuing office.
The central organization delegates approval authority to a regional office. That regional office uses an official seal to validate the cards it issues.
In this analogy:
- The receptionist represents the client application.
- The identity card represents the server certificate.
- The regional issuing office represents an intermediate CA.
- The trusted central organization represents the root CA.
- The secret needed to produce the seal represents the private key.
Now imagine that someone can reproduce the regional office’s seal.
They can prepare a card claiming to represent a legitimate service and add an apparently valid approval.
The receptionist may accept the false identity because the approval traces back to an organization they trust.
The Seal Does Not Redirect the Visitor
Possessing a forged identity does not automatically place an attacker inside every connection.
The attacker still needs a way to make the client communicate with their endpoint or intercept the intended connection.
Mozilla describes the risk in these terms: an attacker able to intercept a connection could use fraudulent certificates to impersonate websites and potentially read or modify traffic.
In the office example, copying the seal is one step. Getting the receptionist to meet the impersonator is another.
That distinction helps separate a serious exposure from evidence of an actual incident.
Why Your Own Certificate Provider Is Not the Whole Question
An organization might ask:
“Our website uses a different certificate provider. Are we affected?”
That addresses the server side of the problem. The client side needs its own assessment.
A workstation, API client, or build tool may trust many authorities beyond the one used by the organization’s own website.
The relevant question is whether that client would accept an attacker’s certificate for the service it intended to reach.
A legitimate certificate on the real server does not determine what every client will accept from an impersonating endpoint.
Why a Protected Browser Does Not Prove a Protected Device
Google distributed a block based on the affected keys’ SPKI hashes. Mozilla distributed protection through OneCRL and also updated NSS trust information.
These mechanisms matter, but their coverage is product-specific. Mozilla explicitly distinguishes Firefox protection from other applications using related trust stores without receiving OneCRL updates.
Applications may use operating-system trust, bundled CA files, runtime-specific stores, or custom configuration.
The researcher’s advisory also highlights clients that require their own updates, including applications carrying separate certificate bundles. Updating a browser or operating system may therefore be insufficient.
In the office analogy, notifying one receptionist does not update every employee’s list of accepted seals.
How I Would Approach an Incident Investigation
The following workflow describes an assessment method. It does not claim that a particular organization experienced interception or credential theft.
I would separate three questions:
- Could an affected client accept the compromised trust chain?
- Did it encounter a certificate using that chain?
- Is there evidence of impersonation, interception, or unauthorized effects?
1. Map Where Trust Is Actually Evaluated
Inventory the clients that establish sensitive connections.
Include browsers, operating systems, application runtimes, container images, CI runners, command-line tools, and network security devices.
For each important client, identify its effective trust source and update mechanism.
A successful browser test should not stand in for a test of a backend service on the same host. Likewise, updating a host does not establish that an existing container’s bundled CA file changed.
Prioritize clients carrying credentials, consuming build artifacts, or communicating with administrative services.
2. Identify Certificates and Keys Precisely
Use the published affected-certificate inventory.
Get Saniye Nur’s stories in your inbox
Join Medium for free to get updates from this writer.
Record certificate fingerprints, SPKI hashes, issuers, and serial numbers rather than relying only on display names.
A certificate fingerprint identifies a particular certificate. An SPKI hash identifies its public-key information. Different certificates can contain the same public key, including cross-signed variants.
The researcher’s published inventory includes both certificate and SPKI identifiers for the affected intermediates and their cross-signs.
This distinction matters when validating whether an alternate chain remains acceptable.
Do not interpret an issuer name appearing in the incident as evidence that every certificate belonging to that organization is compromised.
3. Establish the Exposure Timeline
Record when each client received an effective trust update.
Distinguish a planned deployment from an installed update, and an installed update from confirmed behavior.
Where applications retain trust information in memory, determine whether restart or replacement is required.
Preserve the previous configuration where practical so the investigation can explain what the client would have accepted during the review period.
4. Validate Rejection with the Relevant Client
Use approved validation methods to establish that the affected chain is rejected.
Record the actual reason for failure.
A timeout, DNS failure, or blocked network route does not prove certificate rejection. The researcher’s checker specifically warns that a failed connection can look like a successful security block.
Where a proxy provides protection, establish whether the proxy blocked the certificate or the endpoint rejected it independently.
Keep certificate validation enabled throughout the test.
5. Search for Presented and Accepted Chains
Determine whether available proxy, TLS, or network telemetry retains certificate information.
Search using the relevant certificate or key identifiers, then correlate with hostname, destination, client process, time, and validation result.
Separate blocked connections from accepted connections.
Also distinguish assessment traffic from unexpected activity. A connection to a published test endpoint is not automatically an attacker indicator.
If certificate-chain telemetry was not collected, record that limitation. A search against ordinary connection logs cannot reconstruct information they never retained.
6. Investigate Candidate Connections
For unexpected accepted chains, preserve the available certificate material and surrounding records.
Review DNS changes, proxy configuration, routing context, destination history, and the identity of the client process.
Then investigate what crossed the connection:
- Authentication material or active sessions.
- Sensitive API requests and responses.
- Downloaded packages or executable content.
- Configuration or application updates.
These are investigation scenarios, not claims that such abuse occurred in this incident.
Correlate subsequent identity activity and artifact use before concluding that a suspicious connection caused compromise.
7. Respond According to the Evidence
A stale trust configuration calls for remediation and validation. It does not, by itself, establish credential theft.
Where interception is suspected, contain the relevant connection path and preserve evidence.
Where sensitive information may have been exposed, revoke affected sessions and rotate the relevant credentials from a known-clean environment.
If downloaded content may have been modified, verify its independent signatures and provenance before trusting it.
Scope these actions to the evidence and the access available to the affected client.
8. Manage Availability During Distrust
Trust removal can also break legitimate services.
Google warned that removing the affected root would cause some legitimate certificates chaining to it to stop working.
Identify those dependencies and migrate them to an acceptable hierarchy.
Do not restore service by disabling TLS verification. That removes the identity check the response is intended to strengthen.
9. Close with a Clear Evidence Boundary
Record which clients were assessed, which trust sources were updated, and how rejection was verified.
Separate remediation status from investigation findings.
A scoped conclusion might be:
The assessed clients reject the affected chains. No evidence of unauthorized use was identified in the available telemetry for the specified period.
Document missing certificate telemetry and unassessed clients alongside that conclusion.
What This Changes for Responders
Certificate incidents require following trust across products, runtimes, and applications.
Removing an entry is one operational step. Establishing that the relevant clients stopped accepting the compromised identity is another.
The investigation then asks whether that identity was presented, accepted, and used to produce unauthorized effects.
The seal may be compromised. The responder’s task is to establish who still accepted it — and what happened when they did.
References
- Google: Protecting Chrome and Android Users from Compromised eMudhra Intermediate CA Certificates
- Mozilla: Protecting Firefox Users Following the Compromise of eMudhra Intermediate Certificates
- Researcher Advisory: eMudhra Intermediate CA Compromise
- Affected Intermediate Certificates and Identifiers
