Skip to content
Sign in
Technology · Global

Weak eMudhra certificate keys could be cracked in under a second

eMudhra certificates reportedly used cryptographic keys that could be cracked in under a second, potentially enabling attackers to impersonate certificate holders. Identifying and replacing affected certificates is crucial to reducing that risk.

AI-assisted synthesis · Based on 5 outlets' reporting · Article text read from 1 of 5 outletsHow it's made

View timeline · 6 entries
5 outletsLatest reporting 3 min read
Coverage: Center OnlyL 0 · C 3 · R 0 · 2 unrated

What happened

Key facts

  • A news report said cryptographic keys in eMudhra certificates could be cracked in under one second.
  • The report identified eight affected eMudhra certificates.
  • The report said browsers blocked the eight certificates.
  • The report said the weak keys could let attackers impersonate the certificate holders.
  • The report said identifying and replacing affected certificates was necessary to reduce the risk.

The brief

Researchers found eight digital certificates issued by eMudhra, an Indian cybersecurity company, with secret keys weak enough to be cracked in less than a second, The Times of India reports. Google, Apple, Microsoft and Mozilla have blocked the certificates.

The incident concerns the keys protecting the certificates: according to Google’s security teams, the keys had too little randomness and could be derived from the public certificates. The scale of the weakness is stark in the account. A properly generated key should have had around 1 followed by 115 zeros possible values.

Instead, the eight weak keys were the numbers 4, 56, 66, 115, 155, 156, 230 and 237. The Times of India likens the keys to a lock that can be opened by testing its 256 possible combinations; it says the keys could be checked in a blink.

Google’s security teams attribute the weakness to insufficient randomness in the key creation. eMudhra gives a process explanation: the company says a flaw in the certificate-creation process in April 2025 produced a second, weak set of keys alongside the intended strong keys. According to eMudhra, the weak set was the one published to browser lists.

These are distinct claims about how the weakness arose and how the exposed keys reached those lists. The reported protective steps involve browser and technology companies. Google, Apple, Microsoft and Mozilla blocked the eight certificates. Separately, Mozilla removed one of eMudhra’s main roots, emSign ECC Root CA - G3, from its trusted list on October 20.

The Times of India says that removal was expected to reach devices on the morning of Tuesday, October 27, Pacific time. The timing matters for the distinction between a trust-list change and its arrival on devices: Mozilla’s removal was already made, while the article describes its device-level reach as expected later.

The account does not identify particular users or devices affected, or state how many certificates were used in active connections. Education Times and The Hindu present the leak as an issue for internet users in their headlines, asking what the certificate leak means for users.

News18’s headline describes its coverage as an explanation of the security story and mentions a CERT-In advisory, a MeitY probe and global revocations. MediaNama’s headline likewise presents the eMudhra flaw as an explainer for users. Those headlines establish their coverage’s stated focus, but do not provide further detail about the advisory, probe or user effects.

Why it matters

  • If the weak keys were used to authenticate websites or services, attackers could potentially impersonate them and intercept users’ connections, undermining trust in the affected certificates. Browser makers and eMudhra would need to identify and revoke the certificates and replace them with securely generated ones; organizations relying on them may also need to update systems to avoid outages or security gaps.

What to watch next

  • In the coming days, watch for eMudhra to publish a technical account of the April 2025 key-generation flaw, including which certificates were affected and how it says it addressed them.
  • Watch for Google’s security teams to release further details on how they identified the weak keys and whether they have asked eMudhra or browser vendors to take specific steps.
  • Over the next few weeks, check browser vendors’ public root-program notices and trust-store records for any documented action involving the eight certificates.
  • Look for independent security researchers to verify the reported key weakness and assess whether any affected certificates were used or relied upon.

How it's being covered

Coverage analysisShow details
6 source articles · 5 unique outlets
Outlet political mix: Center Only· 3 Center · 2 unrated
Where the outlets are based: Asia 60% · Unknown 40%
Outlet political mix
Center Only
Left
Center
Right
0 outlets
3 outlets
0 outlets
The marker shows coverage balance: each unique outlet counts once. 2 unrated outlets are not included.
Geography
Where the outlets covering this story are based.
5 unique outletsDominant coverage: Asia
Coverage imbalance
  • Coverage is currently concentrated among Center-rated outlets (3 of 3 rated sources); comparatively few Left or Right-rated outlets have published on the event.
How we measure coverage

How outlets' accounts compare

Updat3 does not yet have enough full reports to compare how outlets framed this story.

Timeline

Developments from this story's sources, dated background we compiled and fact-checked, and our earlier coverage. Each row says which.
  1. The certificate system rests on X.509, a standard first published by the International Telecommunication Union in 1988 for digital certificates.
    Background · from our historical context
  2. Certificate authorities and browser makers formed the CA/Browser Forum.
    Background · compiled and fact-checked by Updat3
  3. In May 2008, researchers disclosed that a flaw in Debian’s OpenSSL package had made many generated cryptographic keys predictable; certificates using affected keys had to be identified and replaced.
    Background · from our historical context
  4. In 2011, the CA/Browser Forum published its Baseline Requirements for publicly trusted TLS certificates, setting common rules for certificate authorities and the certificates browsers accept.
    Background · from our historical context
  5. The Internet Engineering Task Force published the Certificate Transparency specification for logging publicly trusted certificates.
    Background · compiled and fact-checked by Updat3
  6. In 2022, Google introduced the Chrome Root Program and Chrome Root Store, setting out how root certificates are evaluated for Chrome.
    Background · from our historical context

How we got here

In May 2008, researchers disclosed that a flaw in Debian’s OpenSSL package had made many generated cryptographic keys predictable; certificates using affected keys had to be identified and replaced. The certificate system rests on X.509, a standard first published by the International Telecommunication Union in 1988 for digital certificates.

In 2011, the CA/Browser Forum published its Baseline Requirements for publicly trusted TLS certificates, setting common rules for certificate authorities and the certificates browsers accept. In 2022, Google introduced the Chrome Root Program and Chrome Root Store, setting out how root certificates are evaluated for Chrome.

Original sources

2 of 6 articles · Unknown · Show all

Every story links to the reporting it was built from. How we choose sources

Spotted a factual error, a broken link or a misleading summary? Tell us.