What happened in the eMudhra compromise?

A researcher named Wayne reported that the private keys for eight eMudhra intermediate certificates were compromised. He proved it by signing a message with each key. The keys were tiny values, including 4, and could be recovered by brute force.

How did eMudhra end up with such weak keys?

According to eMudhra's account on the Mozilla incident ticket, a bug in the key ceremony script created a second, weak key pair on the HSM. Because the key pairs had similar names, human error meant the weak keys were used to generate the certificate signing requests.

Why is it not reassuring that the intermediates were not used in production?

Weak keys can be recovered from the public key by anyone. An attacker could sign a leaf certificate for any domain using the genuine intermediate, so the question is whether anyone else used the keys, and that cannot be fully known.

Does removing the emSign roots fully fix the problem?

Not on its own. Scott Helme reports each of the eight keys appears in two certificates, one from eMudhra and one from Sectigo, so the same key can chain to a different root.

How did browsers and software respond?

Chrome began blocking the intermediates on 17 October. Mozilla, Apple and Chrome used OneCRL, CRLite and CRLSets, and Go shipped emergency releases that hardcode a distrust list for the eight public keys.

The Private Key Was 4: What the eMudhra Compromise Says About the Trust Stores We Forget We Own

21 Oct 2026 Cyber

eMudhra CA Compromise: The TLS Private Key Was the Number 4

By Andrew Baker · Group CIO, Capitec Bank · 21 October 2026

1. What actually happened

On Saturday 17 October a researcher who signs himself only as Wayne reported to Apple, Google, Microsoft, Mozilla and eMudhra that the private keys for eight eMudhra intermediate certificates were compromised. He proved it in the most unambiguous way possible: he signed the message “We have a problem here – Wayne” with the private key of each of the eight intermediates and sent the signatures to the root programs. You cannot argue with a valid signature.

The eight intermediates were six TLS issuing CAs (domain validated, organisation validated and extended validation, each in a G3B and G3C variant) and two code signing CAs. They chain to eMudhra’s emSign G3 roots: the six TLS intermediates to emSign ECC Root CA – G3, which sat in the Chrome and Apple stores and in Mozilla’s until 20 October, and the two code signing intermediates to emSign Root CS CA – G3, which is in Microsoft’s store. Between them those roots also reach a long list of downstream trust stores that copy from the big root programs. Ars Technica reported that the private key sizes ranged from 3 to 8 bits. Scott Helme pulled the certificates Mozilla attached to its announcement and recovered every key by brute force almost instantly; the values were 156, 230, 115, 56, 155, 4, 66 and 237.

The part of this story I keep coming back to is how it was found, because the answer is that we do not know. Wayne has not said how he spotted the weak keys; he simply proved he held them. What we do know is that he did not need to break into anything. The weakness was visible in the public keys embedded in the certificates themselves, and those certificates had been public since around April 2025, logged and inspectable by anyone with an interest in looking. Ian Carroll observed that the problem appears to have gone undetected since issuance. That means roughly eighteen months during which a trivial check on the key material of a publicly trusted intermediate would have revealed that its private key could be recovered by counting, and during which every root program, auditor, monitoring service and researcher in the ecosystem missed it. To be precise about what that does and does not mean: the keys were exposed for eighteen months, but there is no evidence that anyone discovered or exploited them in that time. Google has said that no website certificate chaining to the six TLS intermediates was ever logged in Certificate Transparency, so no forged certificate from them could have worked against clients that enforce CT, such as Chrome. Exposure and exploitation are different things, and this incident so far is a story about the first. We tend to assume that anything published to transparency logs is being watched closely; this incident suggests that what gets watched is what someone has thought to write a check for, and nobody had written one for a P-384 key whose private half fits in a single byte.

It is worth understanding why nothing tripped over these keys, because the reason is more subtle than carelessness. An elliptic curve public key is a point Q on the curve, computed as Q = d × G, where G is a fixed generator point everyone knows and d is the private key, a scalar that should be drawn uniformly at random from a range of roughly 2^384. Q does not reveal d directly: there is nothing in its size, format or encoding that flags a small scalar, although, as we will see, small candidates for d can be tested very efficiently. If d is 4, then Q is simply G added to itself four times, and the result is a perfectly valid point on the curve, with the right length and the right encoding, that passes every parsing, curve membership and key size check a certificate validator or linter performs. The key was not malformed; it was predictable. The only way to notice is to try the obvious small values of d and see whether one of them reproduces Q, which takes microseconds, but which no standard check does, because no properly generated key would ever fail it. Security that depends on randomness cannot be verified by inspecting the output for well formedness, and that is the gap these keys lived in.

flowchart TD
    subgraph Checks["What standard checks look at"]
        Q["Public key Q<br/>from the certificate"] --> C1["On the P-384 curve? ✅"]
        Q --> C2["Right length and encoding? ✅"]
        Q --> C3["Key size 384 bits? ✅"]
    end
    subgraph Attack["What an attacker does instead"]
        Q2["Same public key Q"] --> T1["Try d = 1<br/>1 × G, no match"]
        T1 --> T2["Try d = 2<br/>2 × G, no match"]
        T2 --> T3["Try d = 3<br/>3 × G, no match"]
        T3 --> T4["Try d = 4<br/>4 × G = Q, KEY FOUND"]
    end
    C2 -.->|passes every check| Q2
    classDef neutral fill:#334155,stroke:#cbd5e1,stroke-width:2px,color:#ffffff
    classDef good fill:#14532d,stroke:#86efac,stroke-width:2px,color:#ffffff
    classDef bad fill:#7f1d1d,stroke:#fca5a5,stroke-width:2px,color:#ffffff
    class Q,Q2,T1,T2,T3 neutral
    class C1,C2,C3 good
    class T4 bad
    style Checks fill:none,stroke:#94a3b8
    style Attack fill:none,stroke:#94a3b8

How does a certificate authority end up with single byte keys? According to the account eMudhra gave on the Mozilla incident ticket, as summarised by Helme, a bug in the script used during the key ceremony created a second, weak key pair on the HSM, and because the two key pairs had similar names, a human error meant the weak keys were used to generate the certificate signing requests. eMudhra has said most of the affected intermediates were never used in production and that it has found no evidence they were used to issue certificates to end users. That is probably true, and it also does not matter very much, for reasons that are worth spelling out.

2. Why “not used in production” is not reassuring

When a CA private key is stolen, the threat is bounded by who stole it. When a CA private key is weak, the threat is everyone. These keys were not exfiltrated from an HSM by a sophisticated attacker; they can be recovered from the public key, which is published in the certificate, by anyone with a laptop and a loop. Helme noted that a simple prompt to an AI agent was enough to recover them. So the question is not whether eMudhra issued bad certificates under these intermediates. The question is whether anyone else did, at any point since the keys were created around April 2025, and the honest answer is that we cannot fully know.

An attacker holding one of these keys does not need eMudhra at all. They take the genuine intermediate certificate, which chains correctly to a trusted root, and use the recovered key to sign a leaf certificate for any domain they like: your bank, your identity provider, your package registry. A client that still trusts a valid certification path through one of these intermediates, and does not enforce an effective revocation or distrust mechanism, may accept that leaf as genuine; whether a particular client does depends on its trust anchors, any name or usage constraints, its revocation policy, any explicit distrust rules and the chain the server presents. Certificate transparency helps here in principle, because publicly trusted certificates are expected to be logged, but a forged leaf used for targeted interception has every incentive to stay out of the logs. Clients that enforce CT, like Chrome, would reject an unlogged forgery; plenty of other clients never check.

There is one further wrinkle. Helme reports that each of the eight keys appears in two certificates, one issued by eMudhra and one by Sectigo. A cross signed copy of an intermediate means the same key can chain to a different root, so removing the emSign roots from a trust store is not, on its own, a complete fix. Chrome and Firefox stopped trusting Sectigo’s AAA Certificate Services root for websites in April 2025, so for those browsers the cross signed path was already closed, but plenty of non browser trust stores still carry that root. Some ecosystems have responded accordingly; Homebrew’s bundle, for example, excludes the emSign G3 roots and the Sectigo AAA Certificate Services root by public key.

flowchart TD
    R1["emSign ECC Root CA - G3<br/>(removed by Mozilla 20 Oct,<br/>Chrome 27 Oct)"] --> I1["EM OV TLS CA - G3C<br/>private key = 4"]
    R2["Sectigo AAA Certificate Services<br/>(not trusted for websites by Chrome<br/>or Firefox since April 2025,<br/>still in many other bundles)"] --> I2["Cross signed copy<br/>same weak key"]
    I1 --> L["Forged leaf certificate<br/>for any domain"]
    I2 --> L
    L --> C1["Browser with OneCRL / CRLSets / CRLite<br/>and CT enforcement<br/>REJECTED"]
    L --> C2["Static CA bundle that still trusts<br/>either root, no revocation or distrust rules<br/>MAY BE ACCEPTED until updated"]
    classDef neutral fill:#334155,stroke:#cbd5e1,stroke-width:2px,color:#ffffff
    classDef good fill:#14532d,stroke:#86efac,stroke-width:2px,color:#ffffff
    classDef bad fill:#7f1d1d,stroke:#fca5a5,stroke-width:2px,color:#ffffff
    classDef warn fill:#78350f,stroke:#fcd34d,stroke-width:2px,color:#ffffff
    class R1,R2 neutral
    class I1,I2,L bad
    class C1 good
    class C2 warn

3. The browsers were the easy part

The browser vendors moved fast. Chrome began blocking the eight intermediates on 17 October, the same day the report arrived, and Mozilla, Apple and Chrome have remediated for their users through the revocation mechanisms they already push to clients: OneCRL, CRLite and CRLSets. Go shipped emergency releases that hardcode a distrust list for the eight public keys into crypto/x509, which tells you how seriously the Go team rated it. curl, Alpine, Arch, Chainguard, Gentoo and Rust’s webpki-roots have all shipped updates.

Blocking the keys was the immediate step; removing the root is the follow up. Mozilla removed emSign ECC Root CA – G3 from NSS on 20 October, and Google has removed it from the Chrome Root Store, with the change expected to reach every device relying on that store on 27 October, specifically to protect consumers of the store that do not take CRLSet updates. That second step has a cost: legitimate websites still using certificates from that hierarchy will break in Chrome unless they move to another CA before then, and Google has told operators to do so immediately.

flowchart TD
    T1["<b>April 2025</b><br/>Key ceremony produces weak keys<br/>Intermediates issued, publicly visible"]
    T2["<b>17 October 2026</b><br/>18h05 UTC report reaches Chrome Root Program<br/>19h45 UTC Chrome blocks via CRLSet<br/>Firefox blocks the same day"]
    T3["<b>19 October</b><br/>Android update via Play Services<br/>Apple begins blocking"]
    T4["<b>20 October</b><br/>Mozilla removes the emSign root<br/>Microsoft blocks, Go ships fixes<br/>Public advisory published"]
    T5["<b>27 October</b><br/>Chrome Root Store removal reaches devices<br/>Legitimate sites on that root must have moved"]
    T1 -->|18 months unnoticed| T2 --> T3 --> T4 --> T5
    classDef past fill:#334155,stroke:#cbd5e1,stroke-width:2px,color:#ffffff
    classDef incident fill:#7f1d1d,stroke:#fca5a5,stroke-width:2px,color:#ffffff
    classDef response fill:#1e3a5f,stroke:#93c5fd,stroke-width:2px,color:#ffffff
    classDef upcoming fill:#78350f,stroke:#fcd34d,stroke-width:2px,color:#ffffff
    class T1 past
    class T2 incident
    class T3,T4 response
    class T5 upcoming

The problem is everything that is not a browser. As the original advisory puts it, many clients do not consume revocation information at all, and only a software update will stop them trusting the compromised intermediates. At the time of writing (midday on 21 October; this will change quickly, so check current status before acting on it), Debian and FreeBSD packages were still pending, and Node.js and Composer’s ca-bundle were reported as pending as well. Filippo Valsorda, who maintains Go’s cryptography libraries, told Ars this is a bigger cleanup job than Heartbleed, and pointed at the long tail: IoT devices, Docker containers, forgotten Linux machines and unmaintained command line tools that bundle their own root certificates. That long tail is where large enterprises actually live.

It is also worth separating the two code signing intermediates from the six TLS ones, because the risk and the remediation are different. A compromised code signing authority does not let anyone intercept traffic; it lets them make malicious software appear legitimately signed to any client that accepts a chain through that authority. That matters for software distribution, vendor update mechanisms, and any allow listing or endpoint policy that treats a valid signature as a reason to trust a binary. The code signing root, emSign Root CS CA – G3, appears only in Microsoft’s root store, and Chrome has said it did not need to block the two code signing intermediates because its TLS verifier would not accept them in a chain anyway. On Windows, code signing trust is governed by the Microsoft root program and the operating system’s disallowed certificate list rather than by a TLS CA bundle, so updating ca-certificates on your Linux fleet does nothing here. The questions to ask are whether anything in your estate was signed under those two intermediates, whether your endpoint and application control policies would accept a binary signed under them today, and how your signature verification treats timestamped signatures made before a revocation, because policies differ on whether a previously valid signature stays valid.

4. Where trust hides in an enterprise estate

If you run a bank, or any organisation of meaningful size, you do not have one trust store. You have hundreds, and most of them were frozen at the moment something was built. A container base image captures whatever ca-certificates package existed on the day it was built and keeps serving it until someone rebuilds. Every JDK ships its own cacerts file, and every application that was packaged with its own JRE carries a private copy of that file. Python applications typically trust certifi rather than the operating system. Node embeds its own root list in the binary unless told otherwise. Even WordPress ships its own bundle, at wp-includes/certificates/ca-bundle.crt, which it uses for outbound HTTPS such as update checks and API calls, and which only changes when WordPress core is updated. Vendor SDKs, appliances, payment terminals and monitoring agents frequently carry a bundled PEM file that has not been touched since the vendor last shipped a release. Developers who have spent time building custom network stacks, as I did for years on FPGAs in high frequency trading, know that a trust anchor compiled into firmware is about as far from a patch pipeline as it is possible to get.

None of these consume OneCRL or CRLSets. Where they still trust a certification path through the compromised intermediates and enforce no other revocation or distrust mechanism, they may continue accepting a certificate signed by a key whose value is 4 until their trust configuration or validation code is updated. So the useful question for an engineering leader this week is not “are we affected?” but “do we know where all of our trust stores are, how old they are, and how quickly we could replace every one of them?” If the honest answer involves the word “probably”, the eMudhra incident has done you a favour by asking it while no one appears to have exploited the keys yet.

5. A practical first pass

The script below walks a filesystem (a host, a mounted container image, or an extracted build artifact) and reports every PEM bundle and Java keystore that contains the emSign G3 roots, any of the eight compromised intermediates, or the Sectigo AAA Certificate Services root, along with the file’s last modified date. Be clear about what it is: a preliminary inventory aid, not an exposure detector. A clean result is not evidence that a system is safe. It can silently miss encrypted keystores, files with non standard names, files it cannot read, and certificates held outside conventional filesystem bundles, such as those compiled into binaries or firmware. It matches certificate subject names, whereas the property that actually matters is the public key and the certification paths a client will accept. A bundle that contains only the roots can still validate a chain through the compromised intermediates when a server presents them, so the absence of the intermediates from a file proves nothing. A modification date tells you where to look first, not whether a fix is present. And the script cannot tell you whether a given client would actually accept a forged chain. Treat the output as the start of a conversation with whoever owns each file.

cat > find-emudhra-trust.sh << 'EOF'
#!/usr/bin/env bash
# Inventory CA bundles and Java keystores that could still trust the
# compromised eMudhra G3 intermediates (directly or via cross signing).
# Usage: ./find-emudhra-trust.sh [root_dir]   (defaults to /)
set -uo pipefail

ROOT="${1:-/}"
PATTERN='emSign (ECC )?Root (TLS |CS )?CA - G3|EM (DV|OV|EV) TLS CA - G3[BC]|EM OV CS CA - G3[BC]|AAA Certificate Services'
STOREPASS="${STOREPASS:-changeit}"

echo "Scanning ${ROOT} for trust stores ..."

# 1. PEM / CRT bundles (OS stores, certifi, curl, vendor bundles)
find "$ROOT" -xdev -type f -size -10M \
  \( -name '*.pem' -o -name '*.crt' -o -name '*.cer' -o -name 'ca-bundle*' \
     -o -name 'cacert*' -o -name 'ca-certificates*' \) 2>/dev/null |
while read -r f; do
  grep -q 'BEGIN CERTIFICATE' "$f" 2>/dev/null || continue
  hits=$(openssl crl2pkcs7 -nocrl -certfile "$f" 2>/dev/null \
         | openssl pkcs7 -print_certs -noout 2>/dev/null \
         | grep -E "^subject=.*(${PATTERN})")
  if [ -n "$hits" ]; then
    echo "PEM   $(date -r "$f" +%F)  $f"
    echo "$hits" | sed 's/^/        /'
  fi
done

# 2. Java keystores (JDK cacerts, bundled JREs, application keystores)
if command -v keytool >/dev/null 2>&1; then
  find "$ROOT" -xdev -type f \
    \( -name 'cacerts' -o -name '*.jks' -o -name '*.p12' -o -name '*.pfx' \) 2>/dev/null |
  while read -r f; do
    hits=$(keytool -list -v -keystore "$f" -storepass "$STOREPASS" 2>/dev/null \
           | grep -E "^Owner:.*(${PATTERN})")
    if [ -n "$hits" ]; then
      echo "JKS   $(date -r "$f" +%F)  $f"
      echo "$hits" | sed 's/^/        /'
    fi
  done
else
  echo "keytool not found; skipping Java keystores"
fi

echo "Done. Anything last modified before 2026-10-20 deserves a closer look."
EOF
chmod +x find-emudhra-trust.sh

A few practical caveats. The -xdev flag stops find crossing into other filesystems, so run the script once per mount point, volume or extracted image rather than once at the root. Keystores with non default passwords will be skipped silently unless you set STOREPASS, and some formats will not open with keytool at all. A more robust check matches on SPKI hashes rather than names, using the published distrust lists (Go’s crypto/x509 change for this incident lists the eight public keys, for example), and the definitive test is a chain validation test run from each client type that matters to you, ideally using test material supplied by your security vendor or root program rather than anything you mint yourself.

Run it against a handful of your most common base images first, because that is where a single fix propagates furthest. If your images flow through an artifact repository, the fix is a rebuild of the base layer followed by a rebuild of everything downstream, and the rebuild is the easy part; knowing what is downstream is the hard part. Java estates deserve particular attention, because a JDK update fixes the system cacerts file but does nothing for an application that ships its own. For Node services, check your runtime version against the Node advisory once it lands, or run with the operating system store via the --use-openssl-ca flag once that store is patched. For appliances and vendor products, the only route is the vendor, so the useful action this week is sending the question rather than waiting for the bulletin.

6. A certificate is not a dependency until you know who trusts it

The inventory above is necessary, but it answers the wrong question on its own. Knowing that a root sits in a bundle is not the same as knowing which systems will accept a certification path through it, and the gap between those two things is where incidents like this one get expensive. Having a certificate in a file is a fact about storage; accepting a chain through it is a fact about behaviour, and it is behaviour that determines exposure.

An enterprise that wants to respond to the next eMudhra in hours rather than weeks should be able to answer four questions. Which trust anchors exist anywhere in our estate? Which applications and runtimes consume each of those trust stores? Which certification paths can those clients actually validate, given their constraints, revocation behaviour and any distrust rules? And how quickly can we revoke or distrust a compromised authority across all of them? Very few organisations can answer the second and third questions today, because the information is scattered across base images, build pipelines, vendor products and runtime defaults that nobody ever recorded.

This is where the software bill of materials idea needs to grow. A conventional SBOM tells you which software components you have. What incidents like this demand is a trust dependency graph: which external cryptographic authorities those components rely on, through which stores, for which purposes. Built properly, that graph turns “are we affected?” from an archaeology exercise into a query, and it makes cryptographic trust something that can be discovered, attributed, continuously assessed and governed centrally rather than inherited by accident. I suspect that idea will outlast the memory of this particular incident.

To make that concrete enough to build, each edge in the graph should record five things: the trusted public key (by SPKI hash, not by name), the consuming application, the validation mechanism it uses (operating system store, bundled file, compiled in list, pinned key), the responsible owner, and the time it takes to remove that trust. The last field is the one most organisations have never measured, and it is the one that decides how a week like this goes.

flowchart TD
    subgraph Anchors["Trusted authorities, by SPKI hash"]
        K1["emSign ECC Root CA - G3"]
        K2["Sectigo AAA Certificate Services"]
    end
    subgraph Stores["Trust stores"]
        S1["Base image<br/>ca-certificates"]
        S2["Bundled JRE<br/>cacerts"]
        S3["Python<br/>certifi"]
        S4["WordPress<br/>ca-bundle.crt"]
        S5["Terminal<br/>firmware"]
    end
    subgraph Apps["Applications: owner, time to remove"]
        A1["Payments API<br/>Payments team<br/>hours"]
        A2["Vendor tool<br/>Vendor<br/>weeks"]
        A3["Data pipeline<br/>Data team<br/>hours"]
        A4["Marketing site<br/>Marketing tech<br/>minutes"]
        A5["Branch devices<br/>Vendor and Infra<br/>months"]
    end
    K1 --> S1 & S3 & S4
    K2 --> S1 & S2 & S5
    S1 --> A1
    S2 --> A2
    S3 --> A3
    S4 --> A4
    S5 --> A5
    classDef bad fill:#7f1d1d,stroke:#fca5a5,stroke-width:2px,color:#ffffff
    classDef store fill:#1e3a5f,stroke:#93c5fd,stroke-width:2px,color:#ffffff
    classDef fast fill:#14532d,stroke:#86efac,stroke-width:2px,color:#ffffff
    classDef slow fill:#78350f,stroke:#fcd34d,stroke-width:2px,color:#ffffff
    class K1,K2 bad
    class S1,S2,S3,S4,S5 store
    class A1,A3,A4 fast
    class A2,A5 slow
    style Anchors fill:none,stroke:#94a3b8
    style Stores fill:none,stroke:#94a3b8
    style Apps fill:none,stroke:#94a3b8

The example is illustrative rather than a description of any real estate, but the shape is the point: the same compromised authority fans out through several stores into applications whose time to remediate ranges from minutes to months, and without the graph you discover that range during the incident rather than before it.

7. The bigger lesson

It is tempting to treat this as a story about one careless certificate authority, and there will be a proper discussion in the root programs about whether eMudhra should remain trusted at all. That discussion is overdue in some people’s view; Mozilla had only posted a notice of intent to approve an eMudhra root inclusion request on 2 October, and at least one participant in that thread said he had not been impressed by eMudhra’s handling of earlier incidents. But the more durable lesson is about our side of the chain. The Web PKI is only as strong as its weakest CA, and an organisation’s ability to respond to a compromised CA is constrained by the trust decisions it cannot discover or change. Browsers solved revocation for themselves years ago by building their own distribution channels. The rest of us are still relying on someone remembering to rebuild a container.

So the takeaway I would offer to any engineering team is a simple one. Trust stores are dependencies, and they deserve the same inventory, ownership and patch discipline as any library in your software bill of materials. The next weak key, stolen key or hijacked registry is a matter of when, not if, and the organisations that cope well will be the ones that can answer “where do we trust this root?” in minutes rather than weeks. Our engineer’s facepalm this morning was entirely justified; the useful response is to make sure the next one is followed by a short, boring rebuild rather than a long, anxious hunt.

References

Ars Technica, Dan Goodin, “The Internet goes on high alert after discovery of 8 compromised TLS certs”, 20 October 2026
eMudhra Intermediate CA Compromise advisory: https://emudhra.we-have-a-problem.com/
Scott Helme, “Eight Bits of Trust; eMudhra’s CA keys cracked in milliseconds”: https://scotthelme.co.uk/eight-bits-of-trust-emudhras-ca-keys-cracked-in-milliseconds/
Google Security Blog, “Protecting Chrome and Android Users from Compromised eMudhra Intermediate CA Certificates”: https://blog.google/security/protecting-chrome-and-android-users-from-compromised-emudhra-intermediate-ca-certificates/
Cloudflare, “8 eMudhra certificates are compromised. Here’s what you need to know”: https://blog.cloudflare.com/emudhra-certificate-compromise/
BleepingComputer, “Mozilla, Google, Apple block compromised eMudhra CA certificates”: https://www.bleepingcomputer.com/news/security/mozilla-google-apple-block-compromised-emudhra-ca-certificates/
The Hacker News, “Eight eMudhra CA Keys Compromised”: https://thehackernews.com/2026/10/eight-emudhra-ca-keys-compromised.html