This Company Used The Worst Private Keys Ever

Summary

The video explains how eight eMudhra certificate-authority private keys were found to be catastrophically weak. Their values were 4, 56, 66, 115, 155, 156, 230, and 237, giving them no more than about eight bits of meaningful entropy. Although they were supposed to be 384-bit keys, a researcher recovered them in under a second.

Why the keys mattered

Browsers rely on certificate authorities (CAs) to verify that a website’s certificate is genuine. Someone holding an intermediate CA’s private key could issue trusted certificates for other sites, potentially enabling impersonation and HTTPS interception if they could also position themselves between a user and the real service.

Six of the affected keys were for TLS certificates; two were for code-signing certificates, which could potentially make malicious software appear legitimately signed. Cross-signing by another CA meant the eight keys were represented by 16 certificates.

Discovery and response

Researcher Wayne found the keys while checking certificates with Google’s open-source cryptographic tooling. He reported them to major browser and operating-system vendors and to eMudhra, and demonstrated possession by signing a message with each key. Mozilla independently recovered the same keys.

Browser and platform vendors responded by blocking or distrusting the certificates, while eMudhra revoked them. Google and Microsoft also removed the parent root certificate from their trust stores. This step could affect legitimate certificates and require replacements.

The video cautions that older systems and software with separate or stale certificate stores—including Linux systems, containers, libraries, and embedded devices—may still need manual updates. It mentions a public testing website for checking whether a device still trusts the certificates, but does not provide its address.

eMudhra’s explanation and earlier warning signs

The narrator describes an earlier warning sign: eMudhra had reportedly faced problems with incorrectly signed revocation lists in June 2025.

The company said the keys originated during an April 2025 key-generation process using FIPS Level 3 hardware security modules. According to its explanation, a flaw in an export test produced a second, weak set of keys alongside the intended strong set. Similar labels led staff to use the weak keys in certificate requests. The company reportedly re-signed revocation lists with those weak keys rather than identifying the underlying issue.

On October 22, eMudhra announced it was leaving the TLS certificate business.

Main conclusion

The video’s main conclusion is that cryptographic hardware, audits, and certificate-chain safeguards are not enough if basic key-generation and verification checks fail.

Reviews, guides, or tutorials

No product review or step-by-step tutorial is presented. The video includes a short HTTPS and certificate-authority explainer and mentions a public certificate-trust test site.

Main speakers and sources

• Narrator: Mental Outlaw, who provides the analysis.
• Researcher: Wayne, who discovered and reported the keys.
• Other sources: eMudhra, browser vendors, and Cloudflare, cited for explanations or response details.