As reported by BleepingComputer, Mozilla, Google, and Apple have blocked eight eMudhra intermediate CA certificates after a researcher demonstrated that their P-384 private keys were so weak they could be recovered by brute force in milliseconds — one of them reportedly having a scalar value of just 4. This is not a subtle cryptographic attack. This is a catastrophic failure of key hygiene at the very top of the trust chain, and it deserves more scrutiny than a routine revocation notice.
What Actually Broke
eMudhra's own incident explanation — a script error that swapped properly generated keys for mislabeled weak ones — is plausible but also deeply uncomfortable. The P-384 curve requires private key scalars in a range of roughly 2^384. The keys in question had scalars under 256, meaning the entropy was off by approximately 376 bits. A single line of code reviewing the bit length of the generated scalar would have caught this before signing. It wasn't caught for roughly 18 months.
The web's trust model assumes CAs generate keys competently. Nothing in the CA/Browser Forum baseline requirements actively audits entropy quality of intermediate keys after issuance.
Why This Is Worse Than the Headline Implies
Vulnerability Summary
| Item | Detail |
|---|---|
| Vendor | eMudhra (India-based CA) |
| Affected | 8 intermediate CA certificates, G3 root hierarchy |
| Severity | Critical — enables rogue TLS certificate issuance |
| Root cause | Weak P-384 private key scalars (some < 256), script mislabeling |
| Exposure window | April 2025 — October 17, 2026 |
| Patch status | Certs revoked; browsers blocked via OneCRL/CT policy; Go patched in 1.27.3 / 1.26.10 |
| Active exploitation | None publicly confirmed, but untraceable if it occurred |
Shield53 Recommendations
- Hunt for issued certificates under the revoked intermediates. Query your CT log monitoring (or use crt.sh) for any certificates chaining to eMudhra's G3 intermediates between April 2025 and now. Pay particular attention to certificates for your owned domains, executives, and infrastructure hostnames you did not request.
- Audit internal trust stores. Identify systems that ship their own CA bundle (Python requests, Java cacerts, Go binaries built statically, IoT firmware, appliances). Push updates where available; otherwise manually remove the affected eMudhra intermediates.
- Validate TLS sessions, not just certificates. If you operate high-value services, supplement certificate validation with HPKP-style pinning for internal systems, or at minimum CT log monitoring for your domains. Relying solely on the CA chain is not sufficient when the chain itself can fail this badly.
- Re-examine your own PKI hygiene. If you operate an internal CA or issue code-signing certs, verify your key generation pipeline produces scalars at the expected bit length. A unit test asserting
k > 2^(n-1)for P-384 keys is trivial and would have caught this. - Watch for follow-on incidents. eMudhra has stated most affected intermediates were never used in production, but they could not rule out misissuance. Treat the next 60–90 days as the detection window for any forged certificates that may have been issued and used quietly.
The larger industry question is structural: the CA/Browser Forum baseline requirements audit CA practices on paper, but entropy quality of intermediate keys is not continuously validated. This incident should drive a serious conversation about mandatory cryptographic hygiene checks for all trusted intermediates — not just policy audits, but technical validation of generated keys. eMudhra is the latest example; it will not be the last.
