Do Son 
Last week, a severe cryptographic failure at Indian certification authority eMudhra sparked industry-wide alarm. Specifically, eight intermediate Certificate Authority (CA) certificates relied on trivial private keys. Most egregiously, the EM OV TLS CA – G3C intermediate certificate used a private key consisting solely of the integer 4. Consequently, anyone holding this public secret could forge valid subordinate certificates for any internet domain.
Revocation Enforcement and Legacy Device Exposure
Modern web browsers and operating systems acted quickly to revoke these compromised certificates. Therefore, standard desktop browsers reject connections secured by these compromised trust chains. However, legacy systems and IoT devices often fail to inspect Certificate Revocation Lists (CRLs). Furthermore, unpatched environments cannot receive updated root stores promptly. In these vulnerable systems, the compromised intermediate certificate remains fully trusted, leaving users exposed to interception.
Over 100,000 Forged Certificates Target Google Domains
Curious security researchers quickly capitalized on the trivial key to test arbitrary domain signing. Naturally, most practitioners selected Google as their primary benchmark. As documented in the Mozilla Bugzilla incident report on eMudhra weak keys, enthusiasts generated a massive volume of fraudulent records. Specifically, public Certificate Transparency (CT) monitors recorded over 106,000 unauthorized certificates for google.com.
Overall, monitoring nodes logged more than 107,000 rogue issuances within hours. In fact, approximately 99 percent of these experimental certificates targeted Google web domains. Because the signatures mathematically align with the compromised CA public key, cryptographic verifications succeed. Nevertheless, modern browsers block active navigation due to immediate intermediate revocation.
Why Certificate Transparency Logs Record Unauthorized Certificates
Many observers wondered why public CT ledgers recorded these self-signed certificates so easily. In reality, certificate issuance and CT logging operate as two distinct procedures. Under standard operations, a certified authority validates domain control before signing an end-entity certificate. Conversely, anyone possessing a compromised CA private key can generate certificates locally. An attacker merely adds arbitrary domain strings to the Subject Alternative Name field and signs the blob.
RFC 9162 Compliance and Log Submissions
Furthermore, RFC 9162 allows any individual to submit signed certificates with an attached trust chain to public monitors. The CT logging system merely archives and publishes cryptographic proofs for public scrutiny. Importantly, logging servers do not authenticate domain ownership on behalf of certificate authorities. Therefore, when researchers submitted their forged eMudhra certificates, transparency monitors accepted and broadcasted the records immediately.
Support Our Threat Intelligence
Find our tech and OS security coverage helpful? Support our work today and unlock a 100% ad-free reading experience!
Buy Me a Coffee
