I’m reminded of two things about Certificate Authorities (CAs) and random numbers, since a researcher (known only as Wayne) announced a major vulnerability with one CA’s certificates. Your browser and mobile are probably OK; IoT (including medical devices) need updates.
First, the 2007 XKCD comic about random numbers, where a roll of a die is used to generate a random number, 4, which is then hard-coded into a program. Second, a blog post I wrote in 2010 about this type of problem, asking whether Certificate Authorities are considered critical vendors for organizations’ security assessments, since those third parties’ decisions affect the security of the entire organization.
What happened
eMudhra is a Certificate Authority in India that has been issuing certificates since 2008. In April 2025, they generated eight intermediate CA certificates, requiring large random numbers to generate the cryptographic key. eMudhra says they intended to use 384-bit random numbers (116 digits long), but instead, the numbers were all below 256 (3 digits long). One of the numbers was 4. Not 4 digits long, just the number 4 (aligning it to the fictional RFC 1149.5 mentioned in the XKCD comic).
Why it matters
As an analogy the cryptographic key can represent a physical key, and the cryptographic algorithm (highly secure and robust) can represent a lock. Using this analogy, the keyspace (the number of possible numbers used to generate the key) represents the maximum number of attempts it would take to forge the original key. Shrinking the keyspace from 116 digits to just 3 digits, makes the task easier.
No, let me rephrase that. The difficulty goes from a longer-than-the-lifespan-of-the-universe task to one that a computer can do instantly. Anyone can forge a trusted certificate for any website or API, then impersonate or intercept it for any software that still trusts the affected root CA and hasn’t pinned its certificates. If you’re using STRIDE for threat modeling, this touches spoofing, tampering, and information disclosure. Ouch.
Who’s fixed, and who isn’t
A few days ago, Wayne discovered the issue and notified Mozilla and Google, who quickly responded to distrust eMudhra’s root CA certificate (emSign ECC Root CA - G3), which fixed the issue on most modern browsers and mobile devices.
However, a large number of medical devices, cars, energy equipment, and home IoT devices are likely vulnerable until (unless) they are updated. The affected eMudhra root has been in common trust stores since early 2019. Worse, in May 2025 Sectigo cross-signed eMudhra’s eight intermediate certificates under its AAA Certificate Services root, which has been in nearly every trust store since 2004. If your product’s trust store has been updated any time since then and doesn’t check revocation or pin certificates, it’s affected until you ship an update that removes both of these roots.