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

eMudhra generated eight private keys with far too little randomness. Private keys must be unpredictable, because they control the certificates used to prove a website’s identity. The company said a flaw in its key-generation system caused a wrap/unwrap step to create weak keys alongside the intended strong keys.

The failure occurred during a key-generation ceremony on April 30, 2025. One key was the number 4, while proper keys should have been randomly chosen numbers about 116 digits long. The weak keys were then published to browser root stores, making them trusted.

Anyone could have recovered these keys almost instantly and potentially created trusted certificates for websites worldwide. Google, Mozilla, Apple and Microsoft blocked the certificates, while MeitY created an investigation team. eMudhra said its infrastructure was not compromised and its digital-signature and eSign businesses were unaffected.

A certificate authority, or CA, is an organisation that confirms website identities and issues digital certificates. Those certificates tell browsers which public key belongs to a website. This matters because browsers need a dependable way to distinguish a genuine site from an impostor.

Companies such as eMudhra become trusted when major browsers and operating systems place their authority certificates in root stores. When a website presents a certificate linked to a trusted authority, the browser can accept its identity and establish HTTPS protection. Trust is therefore inherited through the authority’s signing power.

That arrangement creates a wide blast radius. The article says any trusted authority can vouch for any website, including a bank or government portal. Google, Mozilla, Apple and Microsoft blocked eMudhra’s affected certificates after the weak keys were discovered. A failure at one authority can therefore threaten organisations that never dealt directly with it.

The article does not provide a numerical count of affected websites, devices or applications. It describes the potential reach as any website in the world, from a bank to a government portal, because eMudhra was trusted as a certificate authority.

With the weak private keys, attackers could have issued certificates for websites they did not control. Those certificates might then be presented to browsers, phones, computers, apps, servers or other devices that trusted eMudhra’s authority. The risk depended on whether a system accepted the certificate and checked relevant protections.

The practical exposure was therefore potentially global, not limited to eMudhra customers. However, there is no evidence that the keys were misused. The article also notes that forged certificates used against systems that do not check Certificate Transparency logs might never appear in public records, making the true scope difficult to measure.

A recovered private key gives an attacker the power to impersonate the certificate holder. In this incident, that could mean making a fake certificate for a bank, government portal or other website that browsers would accept as genuine.

Attackers could use the certificate in phishing campaigns or man-in-the-middle attacks. They might place themselves between a user and a website, intercept communications, alter information or capture credentials. CERT-In warned of possible credential theft, unauthorised disclosure of sensitive information and financial fraud.

There is no evidence yet that the eMudhra keys were misused. Major browsers had safeguards that would have exposed attempts against their users, and the affected certificates were blocked. Still, experts called the situation a nightmare scenario because weak keys could be recovered almost instantly, while finding and replacing every already-issued certificate could be slow and difficult.

Google, Mozilla, Apple and Microsoft blocked the affected eMudhra certificates. The article also says major browsers had a safeguard that would have exposed attempts against their users. Certificate Transparency logs provide one such check by making issued certificates publicly visible.

The protection works best when software checks those logs and updates its trusted-certificate lists. A suspicious or unexpected certificate can then be detected, blocked or investigated. CERT-In asked administrators to update systems and trusted certificates, and warned them not to bypass certificate-validation warnings.

Protection is weaker on routers, payment terminals and ageing software that are seldom updated. The article says forged certificates used against apps, servers or devices that do not check Certificate Transparency logs might not appear publicly. Such systems may also retain outdated trust information, so the clean-up could remain slow and difficult even after browsers respond.

Certificate authorities sit inside a shared trust system. Browsers accept certificates from authorities they trust, rather than requiring every website to have a direct relationship with each browser maker. This makes the system practical, but it also concentrates risk.

If an attacker obtains a trusted authority’s private key, they can create a certificate for another organisation’s website. The article gives banks and government portals as examples. A browser may accept that certificate because it can trace it to eMudhra, even when the bank or portal never contacted eMudhra.

That is why experts described the incident as a blow to the global internet’s chain of trust. One company’s weak key generation could expose unrelated organisations and their users. The article says clean-up may be enormous and slow, especially for devices and software that are rarely updated or do not check Certificate Transparency logs.

Public-key encryption uses a matched pair: a private key that must remain secret and a public key that can be shared. A website uses its private key to prove control of its identity, while visitors receive the matching public key through a digital certificate.

A certificate authority signs that certificate, linking the website’s name to its public key. The browser checks whether the signature leads back to a trusted authority, whether the certificate is valid, and whether the website name matches. After authentication, HTTPS uses the cryptographic connection to protect communications from interception or alteration.

The eMudhra incident threatened this process because attackers could recover supposedly secret private keys. They could then create certificates that appeared trusted for other websites. The article says this could enable eavesdropping, phishing and man-in-the-middle attacks, although it reports no evidence that the weak keys were actually misused.