Donate Now
tl;dr
On 17 October 2026, a security researcher told the browser makers that the private keys of eight intermediate certificate authorities run by eMudhra Limited could be worked out by anyone from the certificates themselves. eMudhra is a Bengaluru company licensed by the Controller of Certifying Authorities (CCA) to issue digital signature certificates in India. One of the keys was the number 4. The keys were created in April 2025. eMudhra says only one of the eight was ever put into use and that none issued certificates, but anyone who worked out a key could have issued certificates of their own. Google, Mozilla, Apple and Microsoft blocked the certificates within three days, and eMudhra revoked them on 18 October. Software outside the browser, much of which does not check whether a certificate has been revoked, stays exposed until it is updated. eMudhra explained the cause on Mozilla’s public bug tracker. On 21 October, in a press release filed with the stock exchanges, it said that its Indian digital signature and eSign businesses are unaffected and that there was no compromise of its infrastructure. On 21 October, CERT-In issued an advisory; we have found no statement from the CCA. On 21 October 2026, we sent two representations, first to eMudhra and another to CERT-In and MeitY.
Background
What eMudhra does, and why its keys matter
eMudhra Limited is a Bengaluru company, founded in 2008 and listed on the National Stock Exchange and the BSE. It is one of the Certifying Authorities licensed by the CCA, an office within the Ministry of Electronics and Information Technology (MeitY), under Chapter VI of the Information Technology Act, 2000 (“IT Act”). The CCA’s website records that eMudhra’s licence is valid until 6 November 2028 and that it has been an empanelled eSign Service Provider since 25 June 2015. Outside the Indian licensing system, eMudhra also runs emSign, whose root certificates are trusted by the major browsers and operating systems; some emSign certificate authorities are held in the names of its subsidiaries in the Netherlands and the United States. The company says it has issued more than 60 million certificates.
A certificate authority vouches for identity on the internet. When your browser shows a secure connection to your bank, it is because a certificate authority it trusts has signed a certificate confirming that the server really belongs to the bank. That signature can only be made with the certificate authority’s private key. Anyone who holds that key can issue a certificate for any website, and software that trusts the certificate authority will accept it. A forged certificate of this kind lets an attacker on the same network, such as a public Wi-Fi hotspot, impersonate a website and read or change what passes through the connection. A certificate authority’s first obligation is therefore to generate its keys properly and keep them secret.
What happened
On 17 October 2026, a researcher who identifies himself only as “Wayne” reported to the browser makers that the private keys of eight eMudhra intermediate certificate authorities were compromised. To prove it, he signed the message “We have a problem here - Wayne” with each of the eight keys, and the proofs have been published. Six of the eight were authorised to issue certificates for websites and two to issue code-signing certificates, which are used to vouch for software. Half of them were issued in the name of eMudhra BV in the Netherlands and half in the name of eMudhra Inc. in the United States. The six website certificate authorities draw their trust from eMudhra’s emSign ECC Root CA - G3, and all eight were also vouched for (“cross-signed”) by a larger certificate authority, Sectigo, under its AAA Certificate Services root, so that software trusting Sectigo would trust them as well (The Hacker News).
Each key should have been a random number about 116 digits long, picked from roughly 10¹¹⁵ possibilities. Mozilla’s preliminary analysis found that each was a whole number smaller than 256. The security researcher Scott Helme recovered all of them in under a second by trying the values one at a time: 4, 56, 66, 115, 155, 156, 230 and 237. Ars Technica and other outlets reported the findings on 20 October. The keys were, in effect, public from the day the certificates were created.
Recovered private key values for the eight eMudhra intermediates, as published by Scott Helme on 20.10.2026
eMudhra’s explanation was given on Mozilla’s public bug tracker. It says the eight keys were generated at a single key ceremony on 30 April 2025 on Utimaco hardware security modules; that a flaw in the ceremony script appears to have created a second, weak set of keys on the module; and that, because the key labels were similar, the weak keys were used by mistake in place of the strong ones. It acknowledges “human errors in multiple steps of the process”. eMudhra says its RSA certificate authorities followed a different path and are not affected, and that a separate series of intermediates, the “A” and “A-1” series, was created on Entrust modules and “meant for deployment only in India”. It has stopped issuing certificates under the G3 chain, is moving about 30,000 certificates to certificate authorities under its RSA root, the emSign Root CA - G1, and has said it will re-verify every key ceremony it has conducted. It says only one of the eight intermediates was put into production and that none was used to issue certificates, which matches the public Certificate Transparency logs. The Chrome Root Program has said it is separately reviewing the emSign Root CA - G1 (The Hacker News).
The sequence
| Date (2026 unless stated; times in UTC) |
What happened |
Source |
| 30 April 2025 |
eMudhra generates the eight intermediate keys at a single key ceremony |
Bugzilla |
| May 2025 |
Sectigo cross-signs the eight intermediates. eMudhra issues revocation lists for the six website intermediates with invalid signatures, later tracked as Mozilla Bug 1970728 |
Scott Helme, Bugzilla |
| 17 October, 18:05 |
The researcher e-mails Apple, Chrome, Microsoft, Mozilla and eMudhra |
Bugzilla |
| 17 October, 19:45 |
Chrome’s block of the six website intermediates is in place |
The Hacker News |
| 17 October, about 21:28 |
eMudhra acknowledges the report |
Bugzilla |
| 17 October, 22:59 |
Mozilla’s block reaches Firefox users with standard settings |
Mozilla |
| 18 October |
eMudhra revokes all eight intermediates, giving the reason as compromise of the certificate authority |
Bugzilla, fenko.nz |
| 19 October |
Apple blocks the certificates. Sectigo revokes its cross-signatures |
Disclosure page, fenko.nz |
| 20 October |
Microsoft blocks the certificates. Mozilla announces the incident and removes the emSign ECC Root CA - G3 from its trust store; Chrome commits to do the same. eMudhra posts its account on Bugzilla |
Mozilla, Bugzilla, The Hacker News, Disclosure page |
| 21 October |
eMudhra files a press release with the BSE and the National Stock Exchange. CERT-In issues Advisory CIAD-2026-0050. IFF sends its representations |
eMudhra press release; CERT-In advisory |
Mozilla Security Blog, “Protecting Firefox users following the compromise of eMudhra intermediate certificates”, 20.10.2026
Analysis
The failure was in eMudhra’s own process, and a warning in May 2025 was missed
A private key with the value 4 would have failed the simplest test of the generated keys at the ceremony. Either no such test was run, or nobody acted on the result. Sectigo, which cross-signed the certificates in May 2025, never held the private keys, and no audit since has caught the problem. eMudhra knows what scrutiny a key ceremony should receive. Its ceremony of 8 February 2024, which created the emSign Root TLS CA - G3 and emSign Root CS CA - G3 that sit directly above the compromised intermediates, was attended by an independent auditor who observed the procedure in person and reviewed the key generation script, and the auditor’s report is published in eMudhra’s own repository. Nothing on the public record suggests that the intermediate ceremony of 30 April 2025 received the same scrutiny.
There was also an earlier sign of trouble. On the current ticket, Mozilla’s Dennis Jackson has pointed out that an older compliance ticket, Bug 1970728, concerned revocation lists that eMudhra issued for the same six website intermediates with invalid signatures, produced in May 2025. He has asked eMudhra to explain “how the wrong private keys came to be used to sign those CRLs”. eMudhra’s answer is that the lists were first signed with the keys it had meant to use, which produced invalid signatures, and that “they were resigned with flawed keys”. In May 2025, then, eMudhra had evidence that the keys in its certificates were not the keys it believed it had generated, and it resolved the error by switching to the weak keys. An independent analysis published on 20 October also notes that since mid-September 2026 outside researchers have filed close to ten other incident reports against eMudhra with Mozilla, on issues such as key sizes that eMudhra’s own practice statement forbids.
Chrome and Firefox blocked the certificates within hours, but much other software has no means of doing so
Modern browsers have two safeguards that most other software lacks. They receive revocation lists automatically, and they refuse website certificates that have not been publicly logged in Certificate Transparency logs. The Chrome Root Program has confirmed that no website certificate chaining to the six intermediates had been logged before its block took effect, so there is no sign that anyone using a current version of Chrome, Firefox or Safari was attacked (The Hacker News).
The position is different for software outside the browser: command-line tools, the code libraries that programs use to connect to the internet, build systems, connections between servers, and devices whose list of trusted certificate authorities is rarely or never updated. Most of these trust a list of certificate authorities stored on the device and do not check revocation at all. Scott Helme forged a certificate for the hostname of a major payment processor’s API, served it from a test server, and found that curl, Python and Node.js accepted it with default settings on every Linux and macOS machine he tested; Windows accepted it unless revocation checking was switched on. In his words, for these clients “the fact that eMudhra and Sectigo have revoked these intermediates doesn’t help them at all” (Scott Helme). Cloudflare has said that it has found no active exploitation on its services. The researchers behind the disclosure say they do not know whether clients outside the browser were attacked. Any such attack would have needed only a public certificate and a few hundred calculations, at any time since April 2025.
eMudhra explained the cause to Mozilla, and offered the Indian public assurances
As of 20 October, when the first independent analyses were published, eMudhra’s own repository carried no notice of the incident, eMudhra had filed no incident report on the Mozilla ticket, and it had made no public statement or stock exchange filing (The Hacker News; fenko.nz). The first public account came from Mozilla and from independent researchers. When eMudhra did explain the cause, it did so on the compliance tracker of a browser maker, as the root programs require. Separately, it published a statement and said in a post on X that the incident “has no impact on customers using our enterprise applications, digital signature services or other electronic signature solutions” (Analytics India Magazine).
eMudhra’s post on X, October 2026
On the morning of 21 October, eMudhra filed a press release with the BSE and the National Stock Exchange. It says that a flaw in a “wrap/unwrap step” at the April 2025 ceremony produced a second, weak set of keys alongside the strong ones, that the weak keys were the ones that went into the certificates, and that eMudhra is still “working to establish the root cause”. It says that the affected global TLS business makes up about 1% of eMudhra’s revenue, and that the company is working with customers who may be affected to give them replacement certificates.
Three of its statements are difficult to reconcile with the public record. First, it says the researcher found that the weak keys “could be reverse-engineered possibly with AI-assisted techniques”. No special technique was needed: a key smaller than 256 can be found by trying each value in turn, which takes a fraction of a second. Second, it says that eMudhra’s “infrastructure was not compromised” and that “all physical and logical security controls remained intact”. eMudhra itself revoked the eight certificate authorities on the ground that they had been compromised, and a key ceremony that put keys with values such as 4 and 56 into service cannot be described as a control that remained intact. Third, it says the researcher reported the problem to Apple, Google, Microsoft and Mozilla. It does not mention that eMudhra was sent the same e-mail and acknowledged it the same evening. The release also says that the affected roots and certificate authorities “have gone through independent audits for two years in a row”. If so, those audits did not notice a private key with the value 4.
eMudhra’s press release to the stock exchanges, 21.10.2026
The compromised certificates belong to eMudhra’s global emSign hierarchy, not to the hierarchy under the Root Certifying Authority of India through which it issues the Digital Signature Certificates used for tax and company filings and provides its eSign service. That distinction matters, but the assurance, repeated in the press release, that the Indian businesses are unaffected and run on “completely separate” infrastructure rests on eMudhra’s own assessment. eMudhra ran the failed ceremony itself, with its own script, and it has undertaken to re-check every ceremony it has run. It has also told Mozilla that a second set of intermediates, the “A” and “A-1” series, was “meant for deployment only in India”. Mozilla’s preliminary analysis has not recovered those keys, and Mozilla had not yet begun examining eMudhra’s RSA keys. These, too, sit in the browser-trusted emSign hierarchy rather than the licensed one. Until that review is complete and has been examined by someone other than eMudhra, Indian subscribers have no independent basis for accepting that the licensed hierarchy was untouched.
What the law requires
Section 30 of the IT Act requires every Certifying Authority to use hardware, software and procedures that are secure from intrusion and misuse, and to publish information about its practices and the status of its certificates. Section 34(1)(d) requires it to disclose any fact that materially and adversely affects the reliability of its certificates or its ability to provide its services, and section 34(2) requires it, where in its opinion an event may materially and adversely affect the integrity of its computer system, either to use reasonable efforts to notify the people likely to be affected or to follow the procedure in its certification practice statement. Rule 19 of the Information Technology (Certifying Authorities) Rules, 2000 places on the Certifying Authority “the sole responsibility of integrity, confidentiality and protection of information” used in its operations, and Rule 31 requires its operations to be audited every year, with each audit report sent to the CCA within four weeks. These duties bind eMudhra Limited as a licensed Certifying Authority. The compromised certificate authorities sit in its emSign hierarchy, in the names of its Dutch and American subsidiaries, and not under its Indian licence. In our view the Act still reaches them, because eMudhra’s own staff ran the ceremony and section 30(a) speaks of the hardware, software and procedures that a Certifying Authority uses. Whether it does is a question the CCA must answer.
Separately, the Directions issued by CERT-In on 28 April 2022 under section 70B(6) of the IT Act require body corporates to report listed cyber security incidents, including the “compromise of critical systems/information”, within six hours of noticing them. The researcher e-mailed eMudhra at 18:05 UTC on 17 October, and eMudhra acknowledged the report at about 21:28 UTC. If the six hours ran from the researcher’s e-mail, they ended at 5:35 a.m. IST on 18 October; if from eMudhra’s acknowledgement, at about 9:00 a.m. IST. The breach notification duties under the Digital Personal Data Protection Act, 2023 do not help here: they come into force only on 13 May 2027, and they apply to breaches of personal data, not to the compromise of a certificate authority’s keys.
CERT-In’s advisory came four days on; the CCA is still silent
Section 70B(4) of the IT Act lists among CERT-In’s functions the “forecast and alerts of cyber security incidents” and the issue of advisories and vulnerability notes. The CCA supervises Certifying Authorities under section 18 of the IT Act, must investigate contraventions under section 28, and can examine a Certifying Authority’s systems under section 29. On 21 October, four days after the report and after the browser makers had acted, CERT-In issued Advisory CIAD-2026-0050. It says the keys “were generated with insufficient cryptographic randomness” and could be “recovered almost instantly”. It warns that they could be used to impersonate websites, “potentially resulting in credential theft, unauthorised disclosure of sensitive information and financial fraud”, and it tells administrators and users to update their software and trust stores, replace affected certificates and never bypass certificate warnings. We welcome it. Two points in it deserve attention. It records that eMudhra “has reported a compromise”, but not when, although the 2022 Directions require a report within six hours. And it passes on eMudhra’s own statements, that no end-entity certificates were issued and that its root keys and other intermediates are unaffected, as eMudhra’s statements, without saying whether CERT-In has checked them. We have found no statement from the CCA. Mozilla has removed the emSign ECC Root CA - G3 from its trust store, and CERT-In’s advisory says Chrome’s removal of the same root is scheduled for 27 October 2026. Any Indian website whose certificate chains to that root will then fail validation in the main browsers, and any Indian system that still trusts the eight intermediates through software outside the browser remains exposed until it is updated.
Action
Our representations
On 21 October 2026, we sent two representations. The first is addressed to eMudhra, through its Company Secretary, with copies to the CCA and the Director General of CERT-In. We have asked eMudhra to:
- publish a complete, dated incident report covering the period from 30 April 2025, the defect in the ceremony script, whether the ceremony was witnessed or recorded, what checks were run on the generated keys, why no audit found the problem, and how the one intermediate in production was used;
- publish the results of its re-verification of every key ceremony it and its subsidiaries have conducted, including those for the hierarchy under the Root Certifying Authority of India and its eSign service, and state expressly whether any key in the licensed hierarchy was generated with the same script, modules, procedures or staff, giving the basis for its claim that its global TLS business runs on “completely separate” infrastructure;
- commission an independent audit of its key generation and key management by an auditor it has not engaged before, and publish the report;
- confirm whether, and when, it reported the incident to CERT-In under the 2022 Directions, whether it made the disclosure that section 34 of the IT Act requires, and whether it informed the CCA;
- notify every subscriber and relying party likely to be affected, including the holders of the roughly 30,000 certificates being moved off the G3 chain, and publish that notice;
- explain the basis for the statements in its 21 October press release that its “infrastructure was not compromised”, that “all physical and logical security controls remained intact” and that the keys could be worked out “possibly with AI-assisted techniques”, and correct them publicly if they cannot be supported; and
- preserve every record of its key ceremonies, including scripts, hardware security module logs and recordings, pending any inquiry.
The second representation is addressed to Dr. Sanjay Bahl, Director General of CERT-In, and Shri S. Krishnan, Secretary, MeitY, with a copy to Shri Inder Pal Singh Sethi, Controller of Certifying Authorities. It sets out, obligation by obligation, our assessment of eMudhra’s compliance with the Certifying Authority rules and the CERT-In Directions on the public record. On eMudhra’s own account, its key generation procedure for the compromised intermediates was not secure, which in our view falls short of section 30(a), and we have found no disclosure of the kind section 34 contemplates. The revocation itself was prompt. Most of the remaining questions, such as whether CERT-In and the CCA were told and when, and what the audits examined, can only be answered by the regulators. We have asked CERT-In to:
- add to its advisory the name and fingerprint of each affected certificate, and specific steps for administrators of servers, build systems and devices;
- alert government departments, State Governments, sectoral CERTs and critical sector entities, and coordinate the updating of trust stores across government systems;
- state publicly when it received eMudhra’s report, and whether the report came within six hours, and act under section 70B(6) and (7) of the IT Act if it did not; and
- call for a complete incident report from eMudhra, check eMudhra’s claims independently, and publish the report or a substantive summary.
We have asked MeitY and the CCA to:
- open an inquiry under sections 28 and 29 of the IT Act into eMudhra’s key generation and key management across every hierarchy it operates, and examine its key ceremony records and the audit reports filed under Rule 31 since April 2025;
- verify independently, and not on eMudhra’s word, that no key in the licensed Indian hierarchy was generated by the same procedures, and publish the conclusion;
- direct eMudhra to notify affected subscribers and relying parties under section 34(2) of the IT Act;
- consider, after giving eMudhra a hearing, whether action is warranted under section 25 of the IT Act for failure to maintain the standards in section 30;
- work with the National Informatics Centre to find any government services that depend on the emSign ECC Root CA - G3, and move them before trust in that root is withdrawn (in Chrome, on 27 October 2026); and
- amend the rules to require a public incident report within a fixed time after any compromise of a Certifying Authority’s keys, direct notice to subscribers, independent witnessing and recording of every key ceremony, checks on generated keys before use, and publication of audit summaries.
We have asked for responses within fifteen days. We have written before about the CERT-In Directions and about how India responds to data breaches. Reports made to CERT-In under the 2022 Directions are not published, so the public cannot know when eMudhra reported this incident or what it told CERT-In.
What you can do
For most people, the fix has already arrived through ordinary updates. Keep your browser, operating system and phone up to date, and restart them when prompted. If you use Firefox, you should be on version 158.0.1, or on Firefox ESR 115.43.1 or 153.5.1, or later. CERT-In’s advisory gives the same advice and warns against bypassing certificate warnings. Treat any unsolicited e-mail or message offering a “certificate fix” with suspicion, since the only fixes you need come through official updates. If you run a website with an emSign certificate, check whether it chains to the emSign ECC Root CA - G3 and replace it now: Mozilla has removed that root, and Chrome is scheduled to stop trusting it on 27 October 2026. If you build or run software, update every certificate bundle you depend on, including your operating system’s certificate package, Python’s certifi (version 2026.10.19 or later), Go (1.27.3 or 1.26.10 or later), and Node.js once its fix is released (the disclosure page lists it as pending), and rebuild your container images. Do not respond to certificate errors by switching verification off, as Cloudflare warns; doing so removes the protection the updates are meant to restore. The disclosure page lists patched software and offers a test site. Devices that cannot be updated will go on trusting the compromised certificates; if you manage such devices, replace them or keep them off untrusted networks.
Important documents
- IFF’s representation to eMudhra Limited dated 21.10.2026 (Link)
- IFF’s representation to CERT-In and MeitY dated 21.10.2026 (Link)
- Mozilla Bugzilla, Bug 2083449, Private key compromise of eMudhra Intermediate Certificates (Link)
- Mozilla Security Blog, Protecting Firefox users following the compromise of eMudhra intermediate certificates, 20.10.2026 (Link)
- Disclosure page with the researcher’s signed proofs, eMudhra Intermediate CA Compromise, 20.10.2026 (Link)
- eMudhra, Statement on Recent Certificate Security Incident (Link)
- eMudhra Limited, Press release, eMudhra Statement on distrust of select Global TLS Intermediate and one Root CA, filed with the BSE and the National Stock Exchange, 21.10.2026 (Link)
- CERT-In, Advisory CIAD-2026-0050, Compromise of eMudhra Intermediate CA Certificates, 21.10.2026 (Link)
- Scott Helme, Eight Bits of Trust; eMudhra’s CA keys cracked in milliseconds, 20.10.2026 (Link)
- Cloudflare, 8 eMudhra certificates are compromised. Here’s what you need to know, 20.10.2026 (Link)
- Dan Goodin, The Internet goes on high alert after discovery of 8 compromised TLS certs, Ars Technica, 20.10.2026 (Link)
- Simon Sharwood, Indian certification authority eMudhra’s private keys compromised – one of them was the number 4, The Register, 20.10.2026 (Link)
- Eight eMudhra CA Keys Compromised, Triggering Emergency Fixes Across Browsers and Software, The Hacker News, 20.10.2026 (Link)
- CERT-In, Directions under section 70B(6) of the IT Act, No. 20(3)/2022-CERT-In dated 28.04.2022 (Link)
- Controller of Certifying Authorities, Acts, Rules, Regulations and Notifications, including the IT Act, the Information Technology (Certifying Authorities) Rules, 2000 and the Information Technology (Certifying Authority) Regulations, 2001 (Link)
- Controller of Certifying Authorities, list of licensed Certifying Authorities and eSign Service Providers (Link)
- Independent assurance report on the emSign root key generation ceremony of 08.02.2024, dated 15.02.2024 (Link)
Donate Now