Eight Bits of Trust; eMudhra's CA keys cracked in milliseconds

eMudhra issued eight intermediate certificate authorities with disastrously weak P-384 private keys. Instead of random 384-bit numbers, each key had 47 zero bytes followed by one byte. That made the keys publicly recoverable from their certificates, even though the certificates passed every normal structural check. The compromise affected six TLS issuing CAs and two code-signing CAs, created in April 2025.

A security researcher reported the issue to Apple, Google, Microsoft, Mozilla, and eMudhra on 17th October. Chrome blocked the intermediates through a CRLSet update that evening. Mozilla used OneCRL, then announced the problem and removed the eMudhra root in an NSS update. Chrome also confirmed the root would be removed from Chrome Root Store v43.

The danger cannot be contained like a normal theft. Anyone who had seen a certificate since April 2025 could calculate its private key. Updated browsers are protected, but many other TLS clients do not check revocation or Certificate Transparency by default.

A certificate authority private key is the secret number used to prove that a CA issued a certificate. A CA signs certificates for websites, services, or software. Clients use the CA’s public information to verify those signatures. If someone obtains the private key, they can create new certificates that appear to come from that trusted authority.

For example, an attacker could generate a certificate for a target website and sign it with a compromised issuing key. A client that trusts the relevant CA might accept the certificate as legitimate. The same principle applied to eMudhra’s two code-signing CAs, which could issue certificates for software. The article notes that the affected keys covered TLS and code signing.

The eMudhra keys were not stolen in a traceable event. They were effectively public from creation because their values were tiny. The article says every certificate those CAs could ever issue rested on only eight bits, making the authority’s signing capability broadly recoverable.

Each affected P-384 private key had one meaningful byte after 47 bytes of zeros. A byte has 256 possible values, so the key space was only 256 candidates. This is radically smaller than the roughly 10¹¹⁵ possibilities expected from a properly random 384-bit private key.

The public key in a certificate is calculated as d × G, where d is the private number and G is a fixed point on the curve. An attacker can calculate 1 × G, 2 × G, 3 × G, and so on, comparing each result with the certificate’s public key. The correct value appears after no more than 255 trials when the possible values are 1 through 255.

The researcher recovered all eight keys by brute force. The operation took less than a second on a laptop and was described as instantaneous. The article says the six TLS values and two code-signing keys were all equally weak.

The affected certificates represented eight eMudhra intermediate authorities. Six issued TLS certificates across domain validation, organization validation, and extended validation, with two generations of each. The remaining two were code-signing CAs. All eight were created in April 2025 and cross-signed by Sectigo’s AAA Certificate Services root in May 2025.

The risk extended to any client that trusted these authorities and accepted their certificates. The article specifically lists curl, Python, Node, Go, Java, git, package managers, scripts, and daemons. These clients commonly rely on a CA bundle stored on disk, do not check revocation by default, and do not check Certificate Transparency.

Mainstream, updated browsers were in a stronger position. Chrome and Firefox blocked the intermediates directly and required Certificate Transparency, while Safari also required it. Revocation alone did not protect other clients because many would not retrieve or enforce the revocation information.

Using one of these keys, an attacker could issue certificates as though they came from eMudhra’s trusted certificate authorities. For a website or API, that could create a certificate naming the target service and potentially support an impersonation attempt. The article also identifies two affected code-signing authorities, so forged software certificates were another concern.

The key mechanism is straightforward. A certificate contains a public key and a CA signature binding that key to a name. Anyone with the CA’s private key can generate and sign another certificate. A client that trusts the CA may see a valid signature and accept the certificate. The article says no certificates chaining to these CAs appeared in Certificate Transparency logs.

That absence reassured Chrome because Chrome enforces Certificate Transparency, but CT detects mis-issuance rather than preventing it. Many non-browser clients do not check CT or revocation by default. Their trust could therefore remain until their CA bundles or trust stores were updated.

Browser protections work at several points. Chrome pushed a CRLSet update blocking the eight intermediates, and Firefox used OneCRL before removing the eMudhra root through an NSS update. Chrome also planned to remove the root from Chrome Root Store v43. Safari, Chrome, and Firefox require Certificate Transparency, which exposes publicly trusted mis-issuance through logs.

These measures reduce the chance that a forged certificate will be accepted silently. Chrome noted that no TLS certificates chaining to the affected CAs appeared in CT, so forged certificates could not have been trusted by default in Chrome. However, CT detects mis-issuance; it does not prevent someone from creating a certificate.

Many other clients behave differently. curl, Python, Node, Go, Java, git, package managers, scripts, and daemons generally trust a CA bundle on disk. They do not check revocation or CT by default. Embedded devices and other non-browser clients can therefore remain exposed until their trust stores or software are updated.

In the article’s elliptic-curve model, the private key is a number called d. The public key is d × G, where G is a fixed curve point shared by everyone. Computing the public key from d is easy. Recovering d from the public key is supposed to be impractical, which allows the public key to appear in every certificate without revealing the secret.

That protection depends on d being enormous and unpredictable. A proper P-384 private key is a random 384-bit number, giving 2³⁸⁴ possible values, or roughly 10¹¹⁵. By contrast, eMudhra’s keys contained 47 zero bytes followed by a single byte. An attacker could calculate successive multiples of G until one matched the certificate.

The faulty design reduced the search to at most 255 trials. Every structural check still passed because the resulting public points were valid and correctly encoded. The failure was randomness, not the curve or certificate format, so only trying to recover the key revealed the weakness.