A certificate authority's faulty script generated intermediate signing keys so weak that anyone could recover them in under a second. The incident, discovered by security researcher Wayne on October 17, exposed eight intermediates from eMudhra, six for TLS certificates and two for code signing. One key was literally the number 4. Another was 56. A third was 115.
This isn't a sophisticated attack. It's a procedural failure that turned private keys into public knowledge the moment the certificates were issued.
Incident Overview
On April 30, 2025, eMudhra issued 24 intermediate certificates. Eight of them had private keys smaller than 256, numbers that should have been more than 100 digits long. The company cross-signed these intermediates with Sectigo in May 2025, chaining them to roots trusted by Apple, Google, Microsoft, and Mozilla.
The flaw went undetected for 17 months until Wayne checked the Common CA Database and recovered the keys on his laptop. He signed a message with each compromised key and reported it to all major browser vendors and eMudhra on October 17.
Browsers revoked trust quickly. Chrome and Firefox blocked the certificates the same day. Apple followed on October 19, and Microsoft on October 20. eMudhra revoked them on October 18. Mozilla removed trust in the eMudhra root certificate entirely after multiple researchers demonstrated they could recover the keys.
Key Findings
Faulty script during key ceremony. eMudhra traced the failure to an automated process that generated two sets of keys, one strong, one weak. Staff mistakenly selected the weak set due to similar labels. This wasn't a traditional compromise; the keys were public from the start.
Exposure window of 17 months. Only one intermediate was used in production, but it's unknown if anyone else discovered and used the keys before Wayne's report. An attacker could have issued fraudulent HTTPS certificates for any domain, intercepting or modifying traffic.
Non-browser environments remain at risk. While browsers updated trust stores quickly, apps, servers, and devices that don't receive automatic updates may still trust these certificates. This poses a risk in environments relying on static certificate lists or lacking Online Certificate Status Protocol (OCSP) checking.
30,000 customer certificates need replacement. eMudhra stopped issuing from the affected root and is working on mass reissuance. They're re-checking every key ceremony, suggesting a review beyond the April 2025 batch.
Multiple human errors. Failures occurred in validation, selection, and quality control. The script created weak keys, staff didn't verify key strength, and cross-signing proceeded without catching the flaw. Each step was a missed opportunity to detect the problem.
Implications for Your Team
If you rely on certificate-based authentication beyond browser traffic, you're exposed. Payment gateways, API servers, internal service meshes, IoT devices, and mobile applications use certificates outside the browser trust store update cycle.
The eMudhra incident shows that certificate authority oversight relies on multiple validation layers. When these layers fail, the impact spreads across the trust chain. You can't assume a certificate authority's inclusion in a root program guarantees security.
For fraud risk managers, this is a concern: systems validating certificates without checking revocation status could accept fraudulent certificates signed with compromised intermediates. If you're monitoring for man-in-the-middle attacks or certificate anomalies, the detection window is narrow, attackers could have exploited these keys during the 17-month exposure.
Action Items by Priority
Update certificate trust stores across non-browser systems immediately. Don't wait for automatic updates. Manually verify that your API gateways, load balancers, payment terminals, and internal services have removed trust in the affected eMudhra root. Test certificate validation in staging environments before deploying to production.
Implement OCSP stapling or Certificate Revocation Lists (CRLs) for all certificate validation workflows. If your systems don't check revocation status in real time, they'll continue to trust revoked certificates until you manually update the trust store. OCSP stapling reduces latency while ensuring that your systems recognize revocations quickly.
Audit your key generation procedures if you operate as a subordinate CA or issue certificates internally. Review the scripts and processes you use during key ceremonies. Validate that generated keys meet minimum entropy requirements before use. Implement automated checks that reject keys below a specified bit length, for RSA, that's 2048 bits minimum; for elliptic curve, it's 256 bits.
Add certificate monitoring to your fraud detection stack. Track certificate issuance for your domains using Certificate Transparency logs. Set up alerts for certificates you didn't request. Monitor for anomalies in certificate chains, especially intermediates that don't match your expected issuers.
Document your certificate replacement process now. When the next mass revocation happens, you need a playbook that identifies every system using certificates, prioritizes replacement by criticality, and defines rollback procedures if replacement breaks production services. eMudhra estimates 30,000 certificates need replacement. How many would you need to replace, and how long would it take?
