Centre orders probe as Bengaluru firm eMudhra's key-making error leaves holes in web security

There is no evidence yet that the keys were misused, and the major browsers had a safeguard that would have exposed any attempt against their users.

A Bengaluru company that the world’s major browsers trust to vouch for websites generated the secret keys for eight of its security certificates so poorly that anyone could have worked them out in seconds. Google, Mozilla, Apple and Microsoft have blocked the certificates, the Union government has set up a special team to investigate, and security experts are warning that the clean-up will be long and difficult.

The keys belonged to eMudhra Ltd, a listed certifying authority. (AI generated)

The keys belonged to eMudhra Ltd, a listed certifying authority. Each should have been a randomly chosen number about 116 digits long, but one of them was simply the number 4. With the keys, anyone could have issued certificates, the digital identity cards websites use to prove who they are, for any website in the world, from a bank to a government portal, and browsers, phones and computers would have accepted them as genuine.

There is no evidence yet that the keys were misused, and the major browsers had a safeguard that would have exposed any attempt against their users. But security experts said they were alarmed at the lapse, describing it as a blow to “the global internet’s chain of trust”. Any trusted authority can vouch for any website, they said, so one company’s failure can expose organisations that have never dealt with it. Keys this flimsy, which no standard tool would have produced, could give phishing gangs and eavesdroppers the kind of opening they rarely get. The clean-up could be enormous and slow, they warned, and hardest for the routers, payment terminals and ageing software that are seldom updated.

In a statement on Wednesday, eMudhra said that “a flaw in the KGC caused a wrap/unwrap step to produce a second set of weak keys alongside the original strong keys”, referring to the key generation ceremony at which it created the bad keys on April 30, 2025. “The weak keys were the ones published to the browser root stores,” it said.

The company said its infrastructure was not compromised and no data was breached. It said its Indian digital signature certificate and eSign businesses run on separate infrastructure and were unaffected.

The ministry of Electronics and Information Technology (MeitY) said it had “taken serious note” of the incident and set up a special team to investigate. The ministry said the impact on Indian websites and applications had been “very limited and for a very short interval”. It also accused some social media accounts of “fear mongering” about the incident.

It was not clear how the ministry determined the scale of the impact, since the keys could have been exploited at any point after April 2025, and a forged certificate used against apps, servers or devices that do not check Certificate Transparency logs would not show up in any public record.

The Indian Computer Emergency Response Team (CERT-In), the national cybersecurity agency, issued an advisory only on Wednesday afternoon. It said the keys “were generated with insufficient cryptographic randomness” and “could be recovered almost instantly”. The agency’s tone was markedly different from the ministry’s, warning that attackers could use them to intercept or alter communications, “potentially resulting in credential theft, unauthorised disclosure of sensitive information and financial fraud”. It asked government departments, internet service providers, software vendors and website administrators to update their systems and their lists of trusted certificates. “Do not bypass certificate-validation warnings or disable certificate verification,” it said.

Pete Membrey, chief research officer at ExpressVPN, which runs a virtual private network service, said some of the keys were “as small as a single byte, which is hard to explain”. “None of the standard tools would ever let you create a key like that, so it sounds like they built something custom. It’s a textbook case of why the security world warns against building your own encryption tools rather than using proven ones,” he said.

Membrey called the situation “a nightmare scenario for phishing and man-in-the-middle attacks”. “Everyone is working hard and fast to get these certificates revoked. The problem is that many legitimate certificates are already out there, and people are depending on those too, so cleaning this up won’t be quick or simple,” he said.

“This isn’t just about eight compromised keys. It’s about the global internet’s chain of trust,” said Yash Kadakia, founder and chief technology officer of cybersecurity firm Security Brigade. “A single authority’s failure can undermine authentication for organisations that have never dealt with it. The cleanup could be enormous, particularly for devices and software that cannot be easily updated.”

How the chain of trust works

Every website whose address begins with “https” presents a certificate to prove its identity. To take a hypothetical example, the certificate for sbi.co.in lets a browser confirm that the site is run by the State Bank of India before it shows a padlock and encrypts what the user sends. The browser trusts the certificate because a certificate authority, a company that checks who controls a website, has signed it. Browsers and operating systems each keep a list of the several dozen authorities they trust, and eMudhra is on the lists kept by Google, Mozilla, Apple and Microsoft.

Authorities keep their top-level root certificates for signing intermediate certificates, and the intermediates sign certificates for individual websites. All eight of eMudhra’s compromised certificates were intermediates. Six were for websites, and two were for code signing, which software makers use to prove a program is genuine. If a website’s certificate is an identity card, an intermediate is the office that issues the cards, and whoever holds its private key, the secret number used for signing, can issue a card in any name.

The browsers escaped because they accept a website certificate only if it appears in Certificate Transparency logs, public registers in which any forgery would have been visible.

A mess in the making

Under the encryption method eMudhra used, a private key should be drawn at random from a range of numbers larger than the estimated count of atoms in the observable universe. eMudhra’s eight keys were 4, 56, 66, 115, 155, 156, 230 and 237. Dennis Jackson, a cryptography engineer at Mozilla handling the incident, described them as “effectively all-zeroes apart from the last byte”.

Mozilla’s engineers recovered the keys by generating the first 256 possible keys and checking for a match. Jackson wrote that AI agents he tested managed it “on their first attempt with a simplistic prompt”.

In its replies to Mozilla’s questions, eMudhra said its staff had departed from the usual ceremony script, in “an approved deviation”, to test exporting the keys to its data centres in the US and Europe. The company said “a flaw in the code” then created a weaker second set of keys, which staff used by mistake “because the key labels were similar”, and that “there were human errors in multiple steps of the process”. In Wednesday’s statement, eMudhra said these certificates and its roots had “gone through independent audits for two years in a row”. MeitY said those audits included WebTrust audits, an international standard for checking certificate authorities, conducted by BDO International Limited, and that the ministry had no role in them.