An Indian certificate authority trusted by every major browser had a private key with the value 4. Not “weak” in the password-manager sense — the integer 4. A P-384 ECDSA key that should carry around 384 bits of entropy was reduced to a single digit. Security researcher Scott Helme cracked all eight compromised keys on a personal laptop in under a second. An AI agent later did it from one prompt. eMudhra, the CA responsible, is exiting the publicly trusted TLS business entirely — the last certificates issue today.
What Went Wrong in April 2025
The failure traces to a key ceremony on April 30, 2025, when eMudhra migrated keys between two hardware security module vendors: Utimaco and Crypto4A. A custom Python script handled the wrap/unwrap process — and a single line in the read-back operation truncated each ECDSA private value to its leading byte.
The result: eight intermediate CA private keys reduced to single-byte integers: 4, 56, 66, 115, 155, 156, 230, and 237. Because the weakened keys carried labels resembling the properly generated keys, staff selected the wrong set when preparing certificates. The ceremony was also run with FIPS-approved mode disabled. A warning appeared in June 2025 — invalid CRL signatures — but went uninvestigated for 16 more months.
When researcher “Wayne” reported the issue to browser root programs on October 17, 2026, Helme demonstrated the severity: brute-forcing each key took under a second, since P-384 keys should require testing roughly 2384 values, but these required at most 256.
The Scope Grew
The initial disclosure covered 8 ECDSA intermediate CAs. eMudhra initially declared its RSA intermediates unaffected — then revoked 8 more on November 7. Those RSA keys had passed through host process memory rather than staying HSM-protected, violating eMudhra’s own Certificate Practice Statement. The company’s statement was direct: it “cannot positively demonstrate that this key material was in compliance with CPS §6.2.6.”
The RSA batch included 6 TLS certificate issuers and 2 code-signing authorities, with 195 certificates issued from those CAs before revocation. The total: 16 compromised intermediate CAs across two key types.
Certificate Transparency Contained the Damage
The story could have been much worse. Google confirmed none of the six ECDSA TLS intermediates had issued any certificates visible in Certificate Transparency logs. eMudhra confirmed only one of the eight had been put into active use. No certificates were issued to customers from the compromised ECDSA CAs, and there is no confirmed exploitation.
The keys were vulnerable for 17 months before discovery. Certificate Transparency is the reason the blast radius stayed manageable. If your infrastructure skips CT enforcement, this story is your argument for changing that.
Meanwhile, a Developer Replaced His TV’s Ads With Family Photos
Czech developer Daniel Vrátil took a more creative approach to the leaked keys. He added a compromised eMudhra signing certificate to mitmproxy, configured his router to send Samsung advertising domain traffic to a local server, forged certificates for those domains using the eMudhra key, and replaced his Samsung TV’s home-screen ads with family photos from his NAS — while blocking the accompanying tracking requests.
“Luckily for me, Samsung did not yet release an update for my TV that would revoke the certificate,” Vrátil noted in his project writeup. The setup requires device-specific customization and has a limited lifespan as manufacturers push trust store updates — but it works, and it is on GitHub.
What Developers Need to Do Today
Microsoft removes all 10 remaining eMudhra root certificates from the Windows Trusted Root Program and Edge today, November 16. If your services, containers, mobile apps, or IoT devices include eMudhra-signed certificates, TLS handshakes will start failing for Windows clients after this update propagates.
- Browsers are already patched: Chrome CRLSet and Firefox OneCRL both blocked affected intermediates on October 17.
- The gap is embedded trust stores: IoT devices, custom runtimes, and apps that bundle their own certificate chains won’t get OS-level updates automatically.
- CERTInext customers: SSL.com is the designated replacement CA — the platform itself stays the same, the issuing CA changes.
- Everyone else: Audit all certificate chains today, replace before end of day, and validate in the actual client environment your production traffic runs through.
The Lesson
Key ceremonies are where PKI trust is created. Automating them with custom scripts — without post-ceremony key-strength validation, without comparing the resulting public key against the original — is how you end up with a private key that is the number 4. The June 2025 warning sat unanswered for 16 months. KPMG’s independent review is due December 4.
Certificate Transparency made this survivable. The automation in key ceremonies needs the same scrutiny applied to the keys themselves — including validation checks that would have caught a private value of 4 before it ever signed a certificate.
