eMudhra, an Indian certificate authority trusted by every major browser and operating system, issued eight intermediate certificates in April 2025 whose elliptic-curve private keys were single-byte numbers. The strongest key was 237. A P-384 private key should be a random 384-bit number with roughly 10¹¹⁵ possibilities. These keys had at most 256. Recovering them requires computing d × G for d = 1, 2, 3 ... and stopping when the result matches the certificate's public key — at most 255 scalar multiplications, done in under a second on a laptop. A security researcher reported the vulnerability on Saturday 17 October 2026. Chrome pushed a CRLSet block that evening; Firefox followed via OneCRL hours later. By Tuesday 20 October, Mozilla had shipped an NSS update removing the eMudhra root entirely and Chrome confirmed the root would be purged in Chrome Root Store v43. The response was fast by browser standards — but browsers are only one part of the trust ecosystem. The deeper problem is the 17-month window between key creation in April 2025 and discovery in October 2026 during which anyone who examined these certificates could have silently recovered the private keys. Unlike a stolen key, there is no intrusion log, no access record, no forensic trail. Certificate Transparency ensures no forged TLS certificates were logged in CT-enforcing browsers like Chrome, but CT detects mis-issuance — it does not prevent it, and most non-browser software does not check CT at all. The blast radius beyond browsers is enormous. curl, Python, Node, Go, Java, git, package managers, CI/CD runners, IoT devices, industrial controllers, payment terminals, and Windows code signing all trust CA bundles on disk, do not check revocation by default, and do not enforce CT. The author demonstrated this by forging a certificate for api.stripe.com and having curl report "SSL certificate verify ok," Python complete the handshake, and Node return "authorized: true" on every Linux and macOS machine tested. Windows CryptoAPI accepted the chain unless revocation checking was manually enabled. Six of the eight compromised intermediates were TLS issuing CAs (DV, OV, and EV, two generations each) and two were code-signing CAs. All were cross-signed by Sectigo's AAA Certificate Services root in May 2025, widening the trust chain. The code-signing keys are particularly dangerous: Windows trusts the eMudhra CS root directly, meaning malware signed with these keys looks like legitimate publisher-signed software to any system not actively checking revocation. eMudhra's post-incident account attributes the failure to a ceremony script bug that created a second, weak key pair on the HSM, followed by a human error selecting the wrong key for the certificate signing request. The explanation is plausible but underscores a systemic fragility: nothing in the certificate format, encoding, or structural validation reveals a weak key. A public key derived from d = 4 is a perfectly valid P-384 point. The only detection method is to try factoring it — which no automated system in the issuance pipeline did. Devices that can be updated should update their CA bundles immediately — OS ca-certificates packages, certifi, Node, container base images. Devices that cannot be updated — routers, printers, medical devices, industrial controllers, smart appliances with frozen firmware — will trust these certificates until their expiry in July 2039. That is the real residual risk: a 13-year tail of unpatched trust in keys that were never secret.
