The eMudhra CA Incident: Why Browsers Were Protected and Where TLS Trust Still Breaks¶

Executive summary

On October 17, 2026, a researcher disclosed that the private keys of eight eMudhra intermediate certificate authorities could be recovered from their public certificates. Six intermediates could issue TLS certificates; two were for code signing. In principle, someone holding a compromised TLS-issuing intermediate key could create convincing certificates for domains they do not control.

Modern browsers had important defenses: Certificate Transparency (CT) requirements made an unlogged forged certificate unsuitable for ordinary public-web connections, while emergency issuer blocklists rapidly disabled the compromised authorities. The more uncomfortable lesson concerns non-browser applications, where CT enforcement and timely revocation updates are far from universal.

NOB.center's Certificate Deployment Monitoring brings two of these signals into operational alerting: missing SCT evidence on deployed public certificates, and intermediate CAs blocked through Mozilla OneCRL. It checks what endpoints actually present, rather than just what has appeared in CT logs.

A compromise without a stolen CA server¶

An intermediate certificate authority sits between a publicly trusted root CA and the certificates issued to websites and other services. The root delegates signing authority to the intermediate, which can then sign end-entity certificates. This separation ordinarily limits exposure of the root's private key.

But a compromised intermediate is powerful. If an attacker obtains its private key, they can potentially sign a certificate for login.victim.com without controlling that domain. If a victim's TLS client accepts the resulting certificate chain and the attacker can intercept or redirect the connection, the victim might connect to an impersonating server.

In the eMudhra case, the issue was not a reported breach of an HSM or theft of a CA backup. A faulty key-generation procedure produced cryptographically weak private keys. The affected P-384 keys reportedly had values smaller than 256, making recovery from the corresponding public keys trivial. The certificates originated in an April 2025 key ceremony; the problem was reported on October 17, 2026. [1][2]

According to eMudhra, the affected intermediates had not issued publicly trusted end-entity certificates, and its infrastructure and customer data were not compromised. The company revoked the eight intermediates on October 18. Investigators have not established that forged certificates were used in the wild. [1]

Timeline: response moved quickly

17 October: Researcher reports the recoverable keys to browser root programs; Mozilla and Chrome validate the report and deploy emergency blocks.
18 October: eMudhra revokes the affected intermediates.
20–22 October: Browser vendors publish further explanations and protection updates; Firefox publishes releases for configurations that may not have received the automatic blocklist.
26–27 October: Microsoft describes additional trust-list removals; root-program and downstream trust-store changes continue. [1][2][3][4]

Why an attacker could sign a certificate but not simply make it browser-trusted¶

A certificate is essentially a digitally signed assertion: this public key belongs to this DNS name. A compromised intermediate key can supply that CA signature. But public-web browsers also require evidence that the certificate has been submitted to public Certificate Transparency logs.

The evidence is a Signed Certificate Timestamp (SCT): a receipt issued by a CT log, signed using that log's own private key. The CA signing key and the CT log signing key are different keys, controlled by different parties.

Consequently, recovering an eMudhra intermediate key would not let an attacker forge SCTs. Copying receipts from another certificate wouldn't work either: properly validating SCTs binds them to a particular certificate or precertificate.

flowchart TD
    A[Attacker recovers weak intermediate CA key] --> B[Signs forged certificate for victim domain]
    B --> C{CT-compliant SCT evidence?}
    C -->|No| D[CT-enforcing browser rejects certificate]
    C -->|Valid SCTs| E[Certificate becomes publicly auditable]
    E --> F{CA chain still trusted?}
    F -->|Blocked intermediate or root| G[Browser rejects certificate]
    F -->|Trusted and other checks pass| H[Potential risk; CT monitors can spot misissuance]

Could the attacker obtain genuine SCTs instead?¶

In general, yes: CT is an accountability mechanism, not a replacement for domain validation. A compromised issuing CA could attempt to submit a fraudulent certificate to CT logs, obtain authentic SCTs, and expose the certificate for public scrutiny. If the log accepted it and the browser's CT policy was satisfied, CT alone would not prove that the requester controlled the domain. The hope is that monitoring makes fraudulent issuance discoverable and actionable. [5][6]

This incident was more restrictive. The incident researchers reported no entries for the affected intermediates in the public CT logs, limiting the feasibility of obtaining acceptable logging evidence for forged certificates under them. That contributed to the protection already provided by CT-enforcing browsers, even before issuer-level blocks landed. This does not mean every browser, embedded webview, managed client, or private PKI deployment enforces identical CT rules. [5][7]

What CT actually guarantees

For compliant browsers, SCTs provide verifiable evidence of a log's commitment to publish a certificate. They do not attest that the domain owner authorized issuance. A log normally must incorporate a receipt-bearing certificate within a defined Maximum Merge Delay. This makes misissuance visible, not impossible. [6]

The second line of defense: rapid distrust¶

When the compromised keys became known, browser vendors did not wait for individual website certificates to expire. They blocked the compromised issuer keys.

Mozilla distributed an OneCRL update in under three hours after receiving the report, protecting standard Firefox installations without a browser restart. Chrome deployed a CRLSet update blocking the Subject Public Key Info hashes of the six TLS intermediates. Blocking the key mattered because some intermediates had also been cross-signed by Sectigo: a differently signed intermediate certificate could still carry the same compromised public key. Microsoft and other vendors published further trust changes. [2][3][4]

This highlights how far the browser ecosystem has come. Today, a combination of CT enforcement, rapid blocklist distribution, and root-program coordination can significantly limit the impact of a compromised CA, even when the CA's underlying mistake is serious.

But these protections are not interchangeable:

Security signal	What it answers	What it does not guarantee
Certificate chain validation	Is the certificate signed along an accepted trust path?	That the issuing key has not been compromised
Certificate Transparency	Is there acceptable public logging evidence?	That issuance was authorized by the domain owner
Issuer blocklists / revocation	Has an authority been marked unsafe?	That every TLS client has received or enforced the update
Deployment monitoring	What certificate and chain is a real endpoint serving now?	What an attacker might present in a separate, unmonitored interception path

The overlooked exposure: non-browser TLS clients¶

A browser and a server-to-server HTTP client might connect to the same hostname and arrive at different trust decisions.

Modern browsers implement substantial PKI policy above ordinary certificate-chain verification. Many service clients do not enforce public CT at all. Revocation behavior also varies greatly: some clients consult OS-managed trust data, others use libraries with optional CRL or OCSP checking, and others rely on CA bundles or container images updated only during software releases.

For concrete examples, Go's crypto/x509.Certificate.Verify explicitly does not perform revocation checking, while Python's ssl documentation says that OpenSSL does not check CRLs by default; CRL validation must be configured and supplied with appropriate lists. These are examples, not proof that all software built with either language is vulnerable. Applications may add their own checks, and patched trust stores can remove affected authorities. [8][9]

The operational risk is therefore not simply a static certificate bundle. It is the broader absence of a reliable mechanism for fresh issuer distrust information at verification time.

Imagine an internal application connecting to a third-party API. It verifies the hostname and signature chain but neither checks CT compliance nor receives updated issuer blocks. An attacker with a compromised intermediate key and an interception position could potentially present a forged chain that passes the application's outdated trust logic, even though a current browser would reject it.

A valid signature is not the same as current trust

Certificate revocation is not automatically enforced just because a CA publishes a CRL. A client must obtain and evaluate appropriate revocation or distrust information, or receive a trust-store update that removes the affected authority. For long-lived services, containers, appliances and embedded devices, this distinction is especially important.

Putting these trust signals to work with NOB.center¶

NOB.center's Certificate Deployment Monitoring checks the certificate currently served by monitored TLS endpoints. It combines certificate-chain assessment with SCT evidence and Mozilla's issuer blocklist, then evaluates scan results against alert rules. That is a different perspective from CT-log monitoring, which observes certificate issuance rather than deployment.

Signal 1: a deployed public certificate without SCT evidence¶

A forged certificate created with a compromised intermediate key might have a syntactically valid chain but lack SCTs. NOB.center's certificate trust assessment looks for SCT evidence presented in the certificate or connection. When a complete check finds no SCT evidence for a publicly trusted certificate, the default rule raises a high-severity alert.

That could flag an unexpectedly changed certificate on a monitored public endpoint, whether caused by configuration drift, a faulty issuance process, or malicious replacement. It is a strong reason to investigate, not proof of an attack.

Default high-severity rule

security.schema_version == 1 &&
security.browser_trust.aggregate != "not_applicable" &&
security.ct.status == "missing" &&
!certificate.dns_names.exists(d, in_list(d, lists["blocked_domains"]))

The documented default respects the organization's blocked_domains matching convention.

Important SCT limitation

NOB.center currently checks presence and format of SCT evidence; it does not independently verify SCT signatures or confirm inclusion in public logs. An observed SCT therefore isn't equivalent to proving full browser CT compliance. Conversely, missing evidence on a complete scan is a useful high-severity signal. [10]

Signal 2: an intermediate CA appears on Mozilla OneCRL¶

The second detection path directly fits the eMudhra incident. NOB.center compares the authorities in the deployed certificate chain with Mozilla OneCRL, the issuer blocklist used by Firefox. When it identifies a blocked issuer, the default rule creates a critical-severity alert, even if other parts of certificate validation encountered errors.

Default critical-severity rule

security.schema_version == 1 &&
(security.browser_trust.firefox.status == "distrusted" || security.browser_trust.chrome.status == "distrusted")

Unlike a general-purpose CRL checker, this signal specifically reflects Mozilla's blocked issuers. A result of not_listed is not comprehensive proof of non-revocation; individual end-entity certificate revocation is outside this issuer check. [10]

NOB.center checks for updated trust data approximately every 15 minutes when scans run, retains the source confirmation time, and normally scans monitored endpoints daily. Detection of a newly blocked issuer therefore depends on the next scan and available feed data; it is not an instantaneous notification at the moment Mozilla publishes an update. [10]

Why combining the two is valuable¶

A certificate deployment can change without a new certificate ever appearing in your CT alerts, for instance, when an attacker presents an unlogged fraudulent certificate to a monitored endpoint, or a server starts serving a different chain. Conversely, an existing certificate can become unacceptable without changing at all when the issuer is blocked.

By examining both the certificate deployed now and the current public trust signals associated with its chain, security teams can catch two very different failure modes:

Unexpected certificate deployment: the endpoint presents a publicly trusted certificate with no observed SCT evidence.
Trust changes underneath an existing deployment: an intermediate CA in the served chain appears on Mozilla's issuer blocklist.

These alerts support investigation and response. They do not establish that a man-in-the-middle attack occurred, nor do endpoint scans see a forged certificate shown only to another victim over a different network path.

What security teams should do after an incident like this¶

The immediate priority is to determine which clients actually enforce updated trust decisions, not merely whether browsers have received emergency protections.

Inventory dependent TLS clients. Include backend services, automation runners, containers, monitoring agents, embedded clients and vendor appliances, not only employee browsers.
Update affected trust stores and runtimes. Confirm that current roots and issuer blocks reach running processes, especially systems with pinned or bundled CA stores.
Check both sides of TLS. Monitor deployed server certificates and examine client-side certificate validation, including CT policy and revocation behavior where applicable.
Alert on changed trust signals. Treat missing logging evidence or a newly blocked issuer as reasons for prompt review, alongside expiry and ordinary chain failures.
Test fail-closed behavior. Validate that a revoked or explicitly distrusted issuer actually causes your critical client connections to fail in a controlled environment.

The larger lesson¶

The eMudhra incident exposed an unsettling defect: eight intermediate CA keys were recoverable from public information. Yet the modern browser ecosystem responded with multiple defenses, some already in place before public disclosure and others distributed within hours.

That is a genuine success for Certificate Transparency and coordinated trust management. The remaining risk is concentrated where those protections are absent, incomplete or stale, in automated service clients and other software that makes TLS trust decisions beyond the browser.

NOB.center helps make this distinction operational: monitor the certificate that is actually deployed, identify missing SCT evidence, and alert when an issuer in its chain is blocked. The objective is not merely to know when a certificate expires, but to know when a certificate that looks valid is no longer one your organization should trust.

Explore NOB.center Certificate Deployment Monitoring or visit NOB.center.