The Certificate Chain That Hid an Eight-Bit Secret

A 384-bit cryptographic key sounds like the sort of thing that would outlive every computer on Earth. Yet eight eMudhra certificate authority keys turned out to be numbers such as 4, 56, and 115. Recovering them from public certificates required no stolen server, privileged access, or exotic hardware—only a tiny search space.

On October 17, 2026, a researcher reported the problem to major browser and root-store operators. By October 21, Mozilla had decided to remove trust in eMudhra’s emSign ECC Root CA - G3, Chrome had committed to a similar response, and eMudhra said it had stopped issuing from intermediates connected to that root. The company estimated that roughly 30,000 certificates might need migration to another chain. (bugzilla.mozilla.org)

Start with the certificate chain

Public key infrastructure, usually called PKI, is the system that lets software decide which digital certificates to trust. A certificate authority, or CA, signs certificates that connect a website name to a public key. A root CA sits at the top of the trust hierarchy, while an intermediate CA acts as a delegated issuer beneath it.

When you visit a secure website, your browser checks a chain: the website certificate was signed by an intermediate CA, and that intermediate was authorized by a trusted root. If an attacker controls the private key of an intermediate CA, they may be able to create a convincing certificate for any domain that intermediate is allowed to issue for.

The incident involved six intermediates intended for Transport Layer Security, or TLS—the protocol that protects HTTPS connections—and two intended for code signing. Some of the certificates were also cross-signed by Sectigo, meaning the same intermediate public key appeared inside certificates issued under two different trust paths.

Why P-384 should have been unbreakable

The affected keys used elliptic-curve cryptography, a family of cryptographic systems built around arithmetic on specially defined curves. The particular curve, P-384, is designed around a number roughly 384 bits in size.

The private key is a secret number, usually written as d. The public key is created by multiplying that number by a fixed curve point called G:

d = secret number
Q = d × G

Here, multiplication does not mean ordinary multiplication. It means repeatedly applying the curve’s point-addition operation. Going from d to Q is fast. Going backward—from the public point to the private number—is supposed to be infeasible when d is chosen randomly from the full range.

So how can a certificate that advertises P-384 hide an eight-bit secret? The affected keys were effectively shaped like this:

d = 0x000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000004

Nearly every byte was zero. Only the final byte carried useful information. Because one byte has 256 possible values, recovering the key meant trying the first 255 candidates until the derived public point matched the one in the certificate:

for d in range(1, 256):
 if multiply_generator(d) == public_key_from_certificate:
 print(d)
 break

That is pseudocode rather than a complete attack tool, but it captures the entire failure. The normal hard problem had collapsed into a short loop.

The certificates still looked perfectly valid

This is the part that makes the incident especially instructive. Nothing in the certificate format announces that its private key was chosen badly. The public key is still a valid point on the P-384 curve. The certificate can have the correct issuer, signature format, validity dates, and usage restrictions.

A certificate validator checks whether the public key and its signatures are mathematically valid. It does not receive the private number, so it cannot tell whether that number was selected from an enormous random range or typed as 4.

eMudhra’s explanation points to a flaw in its April 30, 2025 key-generation ceremony. The company says a wrap-and-unwrap step produced a second set of weak keys alongside the intended strong keys, and that the weak keys were the ones published in the trusted certificates. The investigation is still focused on the exact script, process controls, and human checks involved. (emudhra.com)

The lesson is uncomfortable: a hardware security module can protect key material from theft, but it cannot repair a broken process that selects or records the wrong key. Strong hardware and a strong algorithm do not compensate for weak randomness.

Revocation helped browsers first

Browser vendors reacted quickly. Chrome blocked the public-key hashes of the six TLS intermediates through CRLSet, its rapidly distributed revocation mechanism. Mozilla used OneCRL, a similar Firefox blocklist, and later moved to remove the upstream eMudhra ECC root from its trust store. Blocking the public-key information also covered the Sectigo cross-signed versions that reused the same keys. (groups.google.com)

Certificate Transparency, or CT, provided another layer of protection. CT is a system of public logs where newly issued TLS certificates are expected to appear. Chrome said that no certificates chaining to the affected TLS intermediates had been logged before its block, which meant a default Chrome installation would not normally trust a forged certificate through that route.

That protection is valuable, but it is not universal. CT is mainly a browser ecosystem defense. It does not automatically protect every command-line tool, server process, build runner, or embedded device that opens a TLS connection.

The wider client ecosystem is messier

Many non-browser programs trust a CA bundle stored on disk or shipped inside the application. They often do not check revocation by default, and they generally do not enforce Certificate Transparency. That includes familiar tools such as curl, Python, Node.js, Java applications, Git clients, package managers, and cloud automation.

For those clients, a certificate may continue to look acceptable until the local trust store changes. The same problem reaches further into container images, continuous integration runners, API clients, routers, appliances, and embedded devices whose firmware may not receive a new CA bundle for years.

The two code-signing intermediates create a separate concern. They are not used to establish ordinary HTTPS connections, but software-signing trust is another place where a weak CA private key could matter. A browser’s TLS block does not automatically solve every operating system’s code-signing validation path.

What needs attention now

For systems that can be updated, the practical response is a trust-store refresh rather than a certificate-by-certificate guess:

• Update operating-system CA packages and language-specific bundles such as those used by Python, Java, and Node.js.
• Rebuild container images and refresh long-lived base images used by CI/CD systems.
• Check proxies, firewalls, appliances, and private runtimes that maintain their own certificate stores.
• Audit certificates chaining to the affected eMudhra intermediates or the emSign ECC Root CA - G3, then migrate to an approved replacement chain.
• Review code-signing validation and revocation behavior on Windows systems.

The emergency root removal creates an availability problem for legitimate certificates as well as a security fix. That is why eMudhra’s estimate of approximately 30,000 certificates requiring migration matters: the weak eight intermediates may not have issued confirmed end-entity certificates, while other certificates using the same upstream root can still need replacement. This distinction is an inference from the separate incident reports, but it explains why the response is broader than blocking eight names.

The real failure was smaller than the curve

P-384 did not fail. The certificate format did not fail. The public-key mathematics did not fail. The secret number feeding that mathematics was too small, and ordinary validation had no way to see the mistake.

That is the enduring warning from the eMudhra incident: cryptographic strength is not printed on the outside of a key. It depends on randomness, careful ceremonies, independent verification, and a client ecosystem capable of receiving emergency changes. A 384-bit lock cannot protect anything when its private key is only eight bits of uncertainty.