Google, Apple Block eMudhra Certs After Script Error Created Keys With Values As Low As Four
Major tech firms blocked eight eMudhra intermediate certificates after researchers proved private keys were so weak they could be instantly recovered.
Key points
- Eight eMudhra intermediate certificates were revoked after researchers found their private keys had values as low as four.
- Google, Mozilla, Apple, and the Go project implemented blocks to prevent impersonation of legitimate websites using these weak keys.
- eMudhra attributed the flaw to a script error in April 2025 that generated and selected weak keys for signing operations.
Major technology companies blocked eight intermediate certificates issued by eMudhra after researchers demonstrated that the associated private keys were trivially recoverable. The swift response from browser vendors and operating system makers aimed to prevent attackers from forging trusted credentials for legitimate websites.
The vulnerability stemmed from extremely weak entropy in key generation. According to Mozilla's incident report, all eight affected certificates used P-384 private keys created in April 2025. These keys contained values smaller than 256, meaning an attacker could recover them by testing only 256 possible numbers rather than searching an astronomically large space.
How the Weakness Was Found and Confirmed
Security researcher Wayne identified the anomaly on October 17 while scanning publicly available certificate data. To prove the severity of the flaw, researcher Flüpke published one of the compromised private keys on GitHub. This specific key, belonging to eMudhra's "EM OV TLS CA - G3C" certificate, had a numeric value of just four.
BleepingComputer independently verified that the published key matched one of the certificates later revoked by eMudhra. The discovery confirmed that anyone could instantly recover the private keys and use them to issue fraudulent certificates that browsers would initially trust, potentially intercepting encrypted communications.
Vendor Response and Root Cause
eMudhra blamed the incident on an error in a script used to generate certificates in April 2025. The company stated that the error created a second set of weaker keys with labels similar to the properly generated ones. These weak keys were mistakenly selected for certificate signing. Some of the resulting certificates were also submitted to Sectigo for cross-signing, expanding the potential attack surface.
Despite the severity of the flaw, eMudhra stated that most affected intermediate certificates were never used in production. The company claimed to have found no evidence that the keys were used to issue certificates to end users. However, because the weak keys existed since April 2025, attackers had a window of opportunity to recover and abuse them, though no such abuse has been confirmed.
What should you do?
Browser vendors moved quickly to mitigate the risk without requiring immediate software updates for all users. Mozilla blocked the compromised certificates through Firefox's OneCRL system on October 17. Google Chrome blocked the six compromised intermediates authorized to issue TLS certificates on the same day. Apple added protections to its operating systems on October 19.
What Should You Do?
- Verify that your operating system and browsers are updated to the latest versions to ensure they include the recent certificate blocks implemented by vendors like Google, Mozilla, and Apple.
- Review your internal certificate management processes to ensure that key generation scripts are validated and that private keys meet standard entropy requirements before being used for signing.
- Monitor certificate transparency logs for any unexpected certificates issued by eMudhra or other certificate authorities, particularly
Background: Certificate management
Effective certificate management requires automated lifecycle tracking, strict validation of trust chains, and immediate revocation processes. Manual oversight fails at scale, leading to service outages or trust bypasses. Use standardized protocols and centralized inventory tools to maintain security posture without constant manual intervention.
Read the full guide: Certificate Management FAQs: Fixing Expiry, Rotation, and Trust
What to do and how to stay safe
- Urgency and secrecy are the primary psychological triggers used to bypass rational decision-making processes.
- Technical indicators like spoofed addresses are often invisible without specific tooling, so behavioral context matters more.
- Verification must occur through a pre-established out-of-band channel, not the one currently in use.
Trust but verify is the only reliable defense against social engineering. Always confirm urgent requests through a separate, pre-established communication channel.
Step-by-step guide: Social Engineering Warning Signs and How to Respond
General security guidance from the Threat Times newsroom. It is not confirmed advice from the organisations named in this story.
