eMudhra CA Key Compromise Explained: What Happened and What to Do

Q: Was my online banking or shopping at risk?

Not through up-to-date mainstream browsers, based on what the vendors have said. Chrome and Firefox blocked the certificates within hours, and Google says no TLS certificate from the six CAs had been logged in CT before its block, so no forgery could have been used against CT-enforcing browsers. The remaining exposure is software and devices with their own certificate lists that have not been updated.

Q: Does this affect my digital signature certificate or eSign?

eMudhra and CERT-In say India's DSC and eSign services are not affected, and MeitY says the incident concerns only the browser-trusted business. eMudhra says those services run on separate infrastructure, and CERT-In, citing reports, says they use distinct keys.

Q: Was eMudhra hacked?

eMudhra says its infrastructure was not compromised and no data was breached. The problem was weak key generation: the keys could be worked out from the public certificates without stealing anything.

Q: I see a certificate error after updating. Should I turn off checking?

No. Replace the certificate or update the software instead. Switching off verification removes the protection the updates restore.

Eight eMudhra intermediate CA keys were weak enough to be worked out. What browsers did, who is affected in India, what to update and what is still unknown.

On Saturday 17 October 2026, a security researcher told Apple, Google, Microsoft, Mozilla and the Indian certificate authority eMudhra that the private keys behind eight of eMudhra's intermediate CA certificates were so weak that anyone could work them out from the public certificates. Chrome and Firefox blocked the certificates within hours. Apple and Microsoft reportedly followed on 19 and 20 October, according to an incident site run by a Mozilla engineer, and fixes for Go, Python and other software have been shipping since. This explainer sets out what the primary sources say, in plain terms.

On this page: What happened · Timeline · How a weak key breaks trust · Who is affected · What to do · What we don't know yet · FAQ · Sources

8intermediate CA certificates with weak private keys: six for websites (TLS) and two for code signing (Mozilla incident report)

<256possible values for each affected private key, instead of a random 384-bit number (Mozilla incident report)

0TLS certificates from the six affected TLS CAs logged in Certificate Transparency before Chrome blocked them (Google)

What happened

eMudhra is a Bengaluru-based company. According to MeitY and CERT-In, its certificate work falls into two distinct areas: digital signature certificates (DSCs) and eSign in India, regulated by the Controller of Certifying Authorities, and certificates trusted by major browsers and operating systems. The incident concerns only the second.

The eight certificates are intermediate CAs created at a key generation ceremony on 30 April 2025. According to Mozilla's incident report, they belong to a batch of 24 intermediates created that day, and the weak ones are the eight P-384 keys in eMudhra's "B" and "C" series: six that issue TLS certificates (the kind that secure websites) and two that sign code. Each of the eight private keys was an integer below 256, effectively all zeros except the last byte, so anyone could recover it by trying the first 256 candidates.

eMudhra's statement of 21 October 2026, filed with the stock exchanges, says a flaw in the ceremony "caused a wrap/unwrap step to produce a second set of weak keys alongside the original strong keys," and that the weak ones were published to the browser root stores. It says it is still working out the root cause, that its infrastructure was not compromised and that no data was breached. In the Mozilla bug, eMudhra said only one of the eight intermediates was ever put into production and that none issued any end-entity (website or code-signing) certificates.

A researcher who identifies as "Wayne" reported the problem and proved it by signing the message "We have a problem here - Wayne" with each of the eight private keys. Mozilla credits Wayne as the reporter, and its own team then recovered the keys independently.

On 21 October 2026, eMudhra's shares closed at Rs 432 on the National Stock Exchange (NSE: EMUDHRA), the day's 20 per cent lower price band (lower circuit), against a previous close of Rs 540, according to NSE's quote page. This article makes no claim about why the share price moved and is not investment advice.

Timeline

All times are UTC and are the sources' own.

30 April 2025: the key generation ceremony creates the 24 intermediate keys, including the eight weak ones.
17 October 2026, 18:05: the Chrome Root Program receives the researcher's report (Google).
17 October, 19:45: Chrome lands a CRLSet update blocking the affected intermediates by public key hash, with no browser update or restart needed (Google).
17 October, 20:06: Mozilla receives the report, forwarded by Chrome, and begins the process of blocking the certificates through OneCRL. eMudhra acknowledges the report at 21:29, and Mozilla independently recovers the keys at 21:48 (Mozilla bug).
17 October, 22:59: the OneCRL block reaches all Firefox users with standard settings, under three hours after Mozilla received the report.
18 October, 09:24 to 09:38: eMudhra revokes all eight certificates as a CA compromise (its table in the Mozilla bug). Sectigo, which had cross-signed the same keys, later said it completed revocation of its copies. eMudhra's own incident page gives later dates: it says it learned of the issue late on 18 October, India time, and revoked the eight on 19 October.
19 October: Apple reportedly blocks the certificates, according to the incident site run by Mozilla's Dennis Jackson and to BleepingComputer (we found no Apple statement of its own). Most Android devices receive an equivalent block through Google Play Services around 22:00 (Google). The incident site says the issue was disclosed privately to downstream trust stores the same day.
20 October: public disclosure. At about 02:13 (late on 19 October in US time, the date Go's release history uses), Go 1.27.3 and 1.26.10 are announced with a fix (CVE-2026-111943) that does not name eMudhra. Mozilla ships Firefox 158.0.1, ESR 115.43.1 and ESR 153.5.1 for users whose settings blocked the earlier update, plus NSS 3.131.1, which removes the root "emSign ECC Root CA - G3". Microsoft platforms have reportedly blocked the certificates since this date through Windows' automatic trust list updates, according to the incident site (we found no Microsoft statement of its own). Python's certifi 2026.10.19 is tagged, and a CPython core developer urges upgrades to certifi, pip and uv.
21 October: eMudhra publishes its statement. Firefox for Android 158.0.2 fixes a bug that stopped some devices applying the block at once. India's CERT-In publishes advisory CIAD-2026-0050 and the IT ministry (MeitY) announces a special team to investigate.
27 October (expected): Chrome's removal of "emSign ECC Root CA - G3" is due to reach all devices that rely on the Chrome Root Store, on the morning of 27 October US Pacific time (Google).

How a weak key breaks trust

A certificate authority (CA) is an organisation that browsers and operating systems trust to vouch for a website's identity. At the top sits a root certificate. Below it sit intermediate CAs, which do the day-to-day signing. When your browser opens a secure site, the server shows a chain: the site's certificate, signed by an intermediate, signed by a root your device already trusts.

Each certificate carries a public key, which anyone can see, and has a matching private key, which the owner keeps secret and uses to sign things. The system works only if the private key cannot be worked out from the public one. A P-384 private key is supposed to be a random 384-bit number, far too large to search.

Here the private keys were tiny numbers. Security researcher Scott Helme, who recovered them himself, reports that the key for "EM OV TLS CA - G3C" was simply the number 4. BleepingComputer reported the same value for that key, published by another researcher, and said it had verified that the published key matches one of the revoked certificates. CERT-In notes the flaw arose during key generation and is not a weakness in the P-384 algorithm itself.

Whoever holds an intermediate's private key can sign a certificate for any website, and a client that still trusts that intermediate will accept it. Google wrote that the weak keys enabled "anyone to forge trusted HTTPS certificates" against clients that had not yet removed trust in the CAs.

What an attacker would actually need matters. Mozilla describes an attacker "who could intercept a user's connection": someone on the network path, such as a hostile Wi-Fi network or a compromised router. The forgery also works only against software that still trusts the chain, skips revocation checks and does not require Certificate Transparency (CT), the public logs of issued certificates. The incident site names Firefox, Chrome, Edge and Safari as CT-enforcing clients, and Google reported that no TLS certificate chaining to the six affected TLS CAs had been logged before it blocked them. Many other programs do not check CT: in tests he published on 20 October, Helme found that curl, Python and Node.js on the Linux and macOS machines he tried accepted a certificate he had forged, under default settings.

Who is affected

Browser users. Chrome has blocked the certificates since 17 October, standard Firefox installs since 17 October and most Android devices since 19 October, according to Google and Mozilla. Apple devices and Microsoft platforms have reportedly blocked them since 19 and 20 October, according to the incident site.

Website operators using eMudhra certificates. This group is most likely to see breakage. Chrome is removing "emSign ECC Root CA - G3", the root that signed the compromised intermediates, and Google says some legitimate certificates chaining to it will stop working. Mozilla has already removed it in NSS. eMudhra told Mozilla it had stopped issuing from G3 intermediates and estimated about 30,000 certificates needing migration to its G1 hierarchy, about 97 per cent of which came through ACME, an automated issuance protocol. eMudhra's own incident page says the root's distrust affects one customer ecosystem in the United States. Google says operators must obtain a replacement from another hierarchy that Chrome trusts.

Developers and administrators. Software that keeps its own bundle of trusted CAs, or never checks revocation, needs an update. The incident site lists patched versions for Linux distributions, curl, Node.js, Python (certifi, pip, uv), Rust, Electron and others, with Java, Bun and FreeBSD still pending when we checked on 21 October. Go programs must be rebuilt with a patched Go, according to Dark Reading. Devices that cannot be updated are the hardest case, security experts told Indian media.

People in India. eMudhra and CERT-In say the India DSC and eSign services are not affected, and MeitY says the incident concerns only the browser-trusted certificate business. eMudhra says its global TLS business runs on infrastructure completely separate from its India DSC business, and CERT-In's advisory, citing reports, adds that the Indian services use distinct keys. None of these statements lists individual portals, so we cannot say more about specific filing systems. MeitY also said the impact on Indian websites and applications was "very limited and for a very short interval"; the Hindustan Times noted it was unclear how the ministry measured that, since forgeries used against clients that do not check CT would leave no public record. The Hindu reported that many government websites use eMudhra certificates or other technology from the company. The sources we read do not establish which sites, if any, rely on the compromised intermediates.

Code signing. Two of the eight intermediates are code-signing CAs under a root Microsoft trusts. eMudhra says they were never put into production and issued nothing. Google's Certificate Transparency finding covers only the six TLS CAs, and CERT-In notes that the code-signing keys could be used to issue fraudulent code-signing certificates.

What to do

Update your browser and operating system. This is the incident site's advice to ordinary users. Install any pending browser and system updates. Google says Android users who have not yet received the block can restart their device to trigger it.
Organisations: find certificates that chain to eMudhra's G3 root. Check with your provider (eMudhra says it is contacting affected customers directly) and replace anything chaining to "emSign ECC Root CA - G3". Google says this must happen immediately; Chrome's removal of that root is due on 27 October.
Developers and IT teams: update every trust store you manage. That means operating system ca-certificates packages, language bundles such as certifi, container base images (rebuild them), and Go binaries (rebuild them). Test with the incident site's test hosts.
Do not disable certificate checks. CERT-In and Cloudflare both warn against turning off verification to get rid of errors after patching.
Consider monitoring. CERT-In suggests watching CT logs for unexpected certificates for your domains, alongside updates.

No advisory we read asks individual users to change passwords or reissue a personal digital signature certificate because of this incident.

What we don't know yet

The root cause. eMudhra's explanation is preliminary: a flawed ceremony script, a second weak key pair, similar key labels and human error at several steps. Its investigation continues.
Whether anyone used the keys. The incident site says it is not known whether attackers exploited the weakness against clients outside the CT-enforcing browser ecosystem. CERT-In's advisory says the public disclosures do not establish confirmed malicious exploitation as of 21 October.
A 2025 revocation-list problem. Mozilla's report links the six TLS intermediates to a 2025 bug about invalid certificate revocation list signatures, and notes archived snapshots suggest the mismatch began around 23 May 2025. eMudhra told Mozilla the lists were first signed with the original keys and, when those signatures proved invalid, re-signed with the flawed ones. eMudhra says it will re-verify every key ceremony it has carried out.
What happens to eMudhra's other CAs. Chrome says it is examining the continued inclusion of eMudhra's remaining CA certificates. Mozilla says it is not removing trust in "emSign Root CA - G1" at this time.
The Indian investigation. MeitY says further details will follow after its special team finishes.

FAQ

Was my online banking or shopping at risk?

Not through up-to-date mainstream browsers, based on what the vendors have said. Chrome and Firefox blocked the certificates within hours, and Google says no TLS certificate from the six CAs had been logged in CT before its block, so no forgery could have been used against CT-enforcing browsers. The remaining exposure is software and devices with their own certificate lists that have not been updated.

Does this affect my digital signature certificate or eSign?

eMudhra and CERT-In say India's DSC and eSign services are not affected, and MeitY says the incident concerns only the browser-trusted business. eMudhra says those services run on separate infrastructure, and CERT-In, citing reports, says they use distinct keys.

Was eMudhra hacked?

eMudhra says its infrastructure was not compromised and no data was breached. The problem was weak key generation: the keys could be worked out from the public certificates without stealing anything.

I see a certificate error after updating. Should I turn off checking?

No. Replace the certificate or update the software instead. Switching off verification removes the protection the updates restore.

Sources

If a fake security alert or a message about this incident is used to push you into handing over money or personal details, report it. Our cybercrime help hub explains how to report cybercrime and where to get help in your country. This article is general information, not technical, legal or investment advice.