eMudhra's Private Key Was 4: The TLS Risk Beyond Browsers

Imagine trusting a certificate authority to protect encrypted communications across the internet, only to discover that one of its private keys is the number 4.

Not a 384-bit secret beginning with 4. Just 4.

That is what security researchers uncovered in October 2026: eight intermediate certificate authority (CA) keys belonging to India’s eMudhra had extraordinarily weak private values. Six were intended for TLS signing and two for code signing. Google and Mozilla confirmed the compromise and urgently blocked the affected TLS intermediates in their browsers.

The bigger question is not whether elliptic-curve cryptography is broken. It is what happens when a mathematically valid CA certificate carries a private key anyone can recover, and some TLS clients do not consume the emergency browser protections.

Eight certificate authorities, eight tiny secrets

The affected intermediates used the P-384 elliptic curve. A correctly generated P-384 signing key is not supposed to be recoverable from its public key with feasible computational effort. These particular private scalars were all less than 256.

Security researcher Scott Helme independently recovered all eight and published their values:

In elliptic-curve notation, the public key is the point Q = d × G. The private value d must be unpredictable. If it is one of only 255 positive integers, an observer can simply calculate candidate public points and compare them with the certificate.

P-384 itself was not broken. The security of the key-generation output was. A public point computed from d = 4 can be structurally valid even though its private scalar is trivial to recover. The certificate’s format alone cannot establish that a strong random key was used.

Why an intermediate CA key is different from a website key

The compromise of one website’s private key usually exposes that website’s identity. A compromised intermediate CA signing key can be much more consequential because it can issue additional certificates beneath a trusted root, within the CA’s allowed certificate purposes and constraints.

An attacker who reconstructed one of these signing keys could potentially generate a certificate for a domain they do not control. But successful interception is not automatic. All of the following must also be true:

1. The target client accepts a certification path through an affected intermediate.
2. The attacker can intercept or redirect the relevant connection.
3. The client’s revocation, Certificate Transparency (CT), pinning, and other verification controls do not reject the attempted impersonation.

The two affected code-signing intermediates raise a distinct software-trust concern, subject to the code-signing verifier’s policies and trust anchors.

This is an exposure of a cryptographic signing capability, not proof of a broad compromise of encrypted traffic.

Browsers moved quickly. Backend clients are a different problem.

On October 17, 2026, the Chrome Root Program received the report at 18:05 UTC. It landed a CRLSet block for the affected TLS intermediate public keys at 19:45 UTC. Mozilla’s OneCRL block completed distribution to Firefox users with standard configurations later the same day.

Crucially, Google reported that no TLS certificates chaining to the six affected intermediates had been logged to CT before its block. Because Chrome normally enforces CT for publicly trusted TLS certificates, forged certificates from those intermediates could not have been trusted by default by Chrome during that pre-block period. Read Google’s technical account.

The distinction matters: an exploitable CA key is not evidence that Chrome users were successfully intercepted.

The lingering concern is software outside the major browsers:

• Java services using separate trust stores.
• Python and Node.js applications with their own TLS configurations.
• Containers shipping frozen CA bundles.
• OpenSSL-based agents and CLI tools.
• Package installers, service-to-service API clients, and embedded devices.
• Long-running applications that have not reloaded updated trust material.

Depending on library, platform and configuration, these clients may not enforce CT or check certificate revocation by default. Simply revoking the intermediate certificate is therefore not sufficient assurance that every client will reject a forged chain.

An HSM ceremony, two audit cycles, and a weak key

eMudhra’s October 22 statement says the keys were generated on FIPS 140-2 Level 3-certified hardware security modules during a key generation ceremony on April 30, 2025.

According to the company’s preliminary account, a key wrap/unwrap step created a second, weak set of key objects alongside correctly generated keys. The wrong objects were selected for certificate signing requests, and those public keys appeared in CA certificates.

The company says this survived roughly 18 months and two independent audit cycles. Its exact technical root-cause investigation was still incomplete as of this article’s date. The public Mozilla incident thread contains questions about the actual HSM operations and code path that created the weak scalars.

This incident does not establish that all HSM-generated P-384 keys are vulnerable, nor that P-384 itself is defective.

It illustrates a more operational failure: the organization can have certified hardware, formal procedures and audits while still publishing cryptographic objects that should never have passed key-quality verification.

The necessary controls must cover the entire chain: object generation, wrapping and unwrapping, label selection, CSR production, independent public-key review, and ceremony evidence.

Sectigo cross-signing makes chain review important

Each affected key appeared in a certificate issued within eMudhra’s hierarchy and in a cross-certificate issued by Sectigo’s AAA Certificate Services hierarchy. These certificates share the same subject public key.

This matters because a TLS client may be able to build alternate certification paths to roots it trusts.

Blocking only one serial number, or removing only one root, may not eliminate every possible path. Google blocked the affected Subject Public Key Info (SPKI) hashes, addressing the common key material rather than relying solely on a single certificate instance.

For enterprise incident response, inventory key identity and acceptable trust paths—not merely the issuer displayed in a browser certificate viewer.

Five checks for enterprise TLS owners

A targeted assessment need not involve live interception tests or unauthorized exploitation.

1. Inventory the real trust stores. Identify system stores, container images, Java `cacerts`, language-provided CA bundles, and any application-specific pinned or custom stores. A browser update says little about a backend service.

2. Verify actual CT and revocation behavior. Do not assume that the presence of OCSP or CRL distribution information in a certificate means your TLS client retrieves it. Review your runtime’s documented defaults and effective settings.

3. Review alternate certification chains. Account for the eMudhra and Sectigo cross-signs. Confirm which trust anchors and intermediate certificates remain accepted by each high-value application.

4. Check update and reload behavior. A refreshed CA package on disk may not affect a process that caches its trust material. Review container rebuilds, running JVMs, embedded devices and long-lived workers.

5. Test chain rejection under controlled conditions. Use a local trust-store copy and test chain, with the exact TLS implementation and policy used in production. Confirm that chains involving compromised keys are rejected. Avoid disabling verification as a workaround.

For orientation, these read-only local commands can identify relevant library and trust-store paths:

```bash openssl version -a python3 -c “import ssl; print(ssl.get_default_verify_paths())” java -XshowSettings:properties -version 2>&1 | grep -E ‘java.home|java.version’ ```

They do not establish vulnerability or safety on their own. A supported version number or CA-file path is not a successful chain-validation test.

Was anyone actually attacked?

Public primary disclosures reviewed through October 24, 2026 do not establish confirmed malicious exploitation of the weak intermediates.

eMudhra says none issued authorized end-entity certificates. According to the company, seven were never deployed in production and the one deployed intermediate issued no end-entity certificate. Google separately reported the absence of pre-block CT entries for TLS certificates chaining to the six affected intermediates.

That sharply limits conclusions about browser impact, but it cannot prove that an unknown attacker never generated a certificate for a non-CT-enforcing client.

India’s CERT-In advisory also distinguishes eMudhra’s international public-trust operation from its separately regulated domestic digital signature and eSign services, which it states were not affected.

Avoid two equally misleading conclusions: that the whole internet was compromised, or that there is no remaining work because the major browsers shipped blocks.

What happens next?

Google’s October 20 advisory said removal of the relevant emSign ECC Root CA - G3 from the Chrome Root Store was expected to reach supported stable users on October 27, 2026; at publication time, that date was still in the future. Other root-store operators and software distributors have different delivery mechanisms.

The outstanding technical questions include exactly how a wrap/unwrap workflow produced such small scalars, why key-object selection safeguards failed, and why audit and lifecycle controls did not identify the outcome earlier.

The lasting lesson is straightforward: trust is a process, not a certificate format.

Cryptographic algorithms, HSM certification and browser root programs protect different layers. The eMudhra incident showed what happens when key-lifecycle integrity fails—and why enterprise TLS security cannot stop at checking whether Chrome or Firefox has received an update.

A private key of 4 was enough to make that distinction impossible to ignore.

References

• Google Chrome and Android Security, October 20
• Mozilla Security Blog, October 20
• Mozilla incident investigation
• eMudhra’s official incident statement
• Scott Helme’s private-scalar analysis
• CERT-In security advisory, October 21

Evidence status: public-source analysis. No independent exploitation or production-client acceptance testing was performed for this article.