On 17 October 2026 a researcher showed that the private keys behind eight intermediate certificates from eMudhra, an Indian certificate authority, were so weak that anyone could recover them from public data in under a second. Those certificates were trusted by Chrome, Firefox, Apple and Microsoft. Within hours the browsers blocked them, and within days Mozilla removed one of eMudhra’s root certificates altogether. Social media called it everything from a non-event to the end of internet security.

This article is based on Mozilla’s incident report, the patch tracker kept by a Mozilla engineer, the CERT-In advisory, Cisco Talos and news reporting, cross-checked against each other. It contains no exploit steps. Where sources disagree, or where something is only a claim, the article says so. Status is as of 22 October 2026 and the story is still developing.

Short version

• Eight eMudhra intermediate CA certificates (six for websites, two for code signing) had private keys generated with almost no randomness. Mozilla found every one of them was a number below 256.
• This is a key generation failure, not a hack. eMudhra says its systems were not breached and no data was lost.
• Chrome and Firefox blocked the intermediates on 17 October. Apple followed on 19 October and Microsoft on 20 October. eMudhra revoked all eight.
• Mozilla removed the root emSign ECC Root CA – G3 on 20 October. Chrome’s removal reaches devices on 27 October. Websites whose certificates chain to that root must switch before then.
• No confirmed misuse has been reported. Browsers that enforce Certificate Transparency could not have been attacked with these keys. Apps, servers and command line tools that skip revocation checks need updated trust stores.
• The claim that 60 million certificates are at risk is wrong. About 30,000 customer certificates need migration, according to eMudhra.

The story, for anyone who is not a tech person

Picture a country with many border posts. Every officer on duty has a short list of head offices they trust. A head office does not stamp every traveller’s papers itself. It licenses regional branch offices, and each branch owns one official stamp. When you arrive with a paper stamped by a licensed branch, the officer checks the stamp against the branch’s registered specimen, which is published openly, and waves you through.

On the internet, the head office is a root certificate authority, the branch is an intermediate certificate authority, the stamp is a private key, and the stamped paper is the certificate that proves a website is who it claims to be. The border officers are your browser and every app that connects to a website. The system works because nobody can copy a stamp just by looking at its published specimen. The stamp pattern is chosen from more possibilities than there are atoms in the universe.

In April 2025 eMudhra, a certificate authority based in Bengaluru, ran a ceremony to make a batch of new branch stamps. According to eMudhra, a faulty step produced a second, weaker set of stamps next to the correct ones, and the two sets had similar labels. Staff picked the weak set by mistake, and the eight branch offices went out with stamps whose patterns were chosen from only 256 possibilities instead of more than the atoms in the universe.

A pattern that simple can be copied by anyone. A person who looks at the published specimen can try all 256 possibilities in a fraction of a second and end up holding a perfect copy of the official stamp. Nothing was stolen. The stamps were effectively public from the day they were made.

On 17 October 2026 a researcher who was scanning the public register of branch offices noticed the problem and proved it by stamping a message with every one of the eight stamps. He emailed the border agencies behind Chrome, Firefox, Apple and Microsoft, and he emailed eMudhra. Within hours Chrome and Firefox sent their officers a recall notice listing the eight branches. Apple and Microsoft followed over the next three days. eMudhra withdrew the eight branches, and Mozilla then went a step further and struck the whole regional head office off the officers’ trust list.

Two things limit the damage. First, there is a public ledger, Certificate Transparency, in which browsers expect every genuine stamped paper to be recorded. Google reported that no website certificates from the six website branches were recorded there before the block, so officers who check the ledger would have rejected a forged paper. Second, the weak spot is the officers who never read recall notices. Some apps, servers and command line tools keep their own old list of trusted offices and never check for recalls. They keep waving the forged papers through until someone updates their list.

Why this one is different

Most certificate incidents involve a CA issuing the wrong certificate, or a key being stolen. Here no one had to steal anything. Mozilla’s analysis found the keys were integers below 256, and a researcher recovered all eight from public certificate data in under a second. The flaw also sat in the system for about 17 months, from the April 2025 ceremony to the October 2026 report, before anyone outside eMudhra noticed. A 17 month exposure window is not evidence that anyone used the keys. No misuse has been reported.

What it means around the world

eMudhra is a Bengaluru-based company that ThePrint describes as the only Indian root certificate authority trusted worldwide. The Hacker News reports that it has issued more than 60 million digital certificates over its lifetime. That figure counts everything issued over the years and is not the number at risk.

The numbers that matter for impact: eMudhra estimates about 30,000 customer certificates need to be migrated, about 97% of them through the automated ACME process. Chrome’s own count of unexpired certificates chaining to the affected root was about 30,800 on 21 October, and 99.9% of them were issued by two InCommon intermediate CAs rather than by eMudhra’s own intermediates.

The software affected spans the whole stack. Cisco Talos lists VPN clients, proxies, load balancers, gateways, build runners, package managers and embedded devices as places where weak trust handling could matter. Go, Python, Node.js, Java, Rust tools, Linux distributions, curl and Electron all shipped or are shipping updates, and Cloudflare updated its own products.

Hypothetical example, not a reported incident: a university library portal in another country runs on a certificate that chains to the affected root. After Chrome’s removal on 27 October, visitors would see a security warning until the university installs a certificate from a different chain. Nothing was breached. The portal simply stops being trusted.

In India, CERT-In published advisory CIAD-2026-0050 on 21 October. MeitY formed a special team to investigate, and said that Digital Signature Certificates and eSign services regulated by the Controller of Certifying Authorities are unaffected, and that the effect on Indian websites and applications was limited and short-lived. Both statements are the ministry’s own and eMudhra says the same about its Indian services. eMudhra shares fell 20% to the lower circuit of Rs 432 on 21 October, according to ThePrint, and the company says the affected business is about 1% of its revenue.

What it means for you as a normal user

• Update your browser and operating system. Chrome and Firefox were protected within hours without needing an update in most cases, but updates close the gaps for unusual setups.
• Firefox on Android: version 158.0.2 fixed a case where some profiles did not apply the block at startup, according to Mozilla’s incident report.
• If a website shows a certificate warning, do not click through it. That is exactly the situation these keys could have been used to hide.
• Avoid logging in to important accounts on public Wi-Fi until your devices are updated. An attacker would need to sit on your network path to use a forged certificate.
• If you use Indian digital signatures or eSign, MeitY and eMudhra say those services are unaffected.

What happened and when

Times are UTC where the sources gave them. Dates for revocation differ between sources and the difference is explained below.

• 30 April 2025: eMudhra’s key generation ceremony creates a batch of 24 intermediate CAs. The eight affected keys are the P-384 keys in two of the series.
• May 2025: Sectigo cross-signs the affected intermediates, according to Help Net Security. Mozilla later notes that the revocation lists for the six website intermediates were failing signature checks from 23 May 2025 (tracked in Bug 1970728).
• 17 October 2026, 18:05: researcher Wayne emails Apple, Chrome, Microsoft, Mozilla and eMudhra with proof of key control. Mozilla receives the report at 20:06, forwarded by the Chrome Root Program.
• 17 October, evening: Chrome blocks the six website intermediates with a CRLSet update, reported as in place by 19:45. eMudhra acknowledges the report at about 21:28. Mozilla recovers the keys itself at 21:48 and completes its OneCRL block at 22:59.
• 18 October: eMudhra revokes all eight intermediates between 09:24 and 09:38. Mozilla opens its public incident report.
• 19 October: Apple blocks the certificates.
• 20 October: Microsoft blocks the certificates. Mozilla removes emSign ECC Root CA – G3 from its root store (NSS 3.131.1) and ships Firefox 158.0.1. Go ships fixes. eMudhra stops issuing from the G3 hierarchy. Dennis Jackson of Mozilla publishes details.
• 21 October: eMudhra publishes a statement and files with stock exchanges. CERT-In publishes CIAD-2026-0050. MeitY announces an investigation team. Red Hat publishes RHSB-2026-012. Cisco Talos publishes its advisory.
• 27 October: Chrome’s removal of emSign ECC Root CA – G3 is scheduled to reach all devices that use the Chrome Root Store.

What was wrong with the keys

An elliptic-curve P-384 private key should be a random number between 1 and an enormous limit, roughly 10 followed by 115 zeros. Mozilla’s analysis found that the eight affected keys were all integers below 256, effectively zero except for the last byte. That makes recovery trivial: a computer can generate the first 256 possible keys, or run a simple discrete logarithm search, and match the result against the public certificate. Mozilla recovered the keys this way, and Scott Helme, an independent researcher, recovered all eight in under a second. Reported example values are 4, 56 and 115.

eMudhra’s account, given in Mozilla’s incident report, is that an approved deviation in the April 2025 ceremony introduced a test of exporting and re-importing keys, and a code flaw then created a second, weaker key pair on the hardware security module. The weaker pair was used by mistake to create the certificate signing request, because the key labels were similar, and that request went to eMudhra’s root and to Sectigo for cross-signing. eMudhra also says the keys were generated in Utimaco hardware security modules and that its RSA issuers followed a different path and are not affected. Mozilla has not independently verified eMudhra’s statements about the hardware.

The affected certificates are six TLS intermediates, named EM DV, EM OV and EM EV TLS CA – G3B (eMudhra BV) and G3C (eMudhra Inc), and two code-signing intermediates, EM OV CS CA – G3B and G3C. Each key also exists in a second certificate cross-signed by Sectigo, so both paths to trust had to be closed. Sectigo has revoked its cross-signed copies. According to eMudhra, only one of the eight, EM DV TLS CA – G3C, was in production, and none issued certificates to customers. Certificate Transparency records are consistent with that.

Why revocation alone is not enough

A revoked certificate is only rejected by a client that learns about the revocation. Browsers receive pushed blocklists: Chrome uses CRLSet, Firefox uses OneCRL, and Android devices receive the equivalent through Google Play Services. Most other software reads a trust bundle from disk, does not check revocation by default and does not check Certificate Transparency. In tests described by Scott Helme, curl, Python and Node accepted a forged certificate on Linux and macOS. On Windows, the system accepted the chain unless revocation checking was enabled. This is why the remedy for those clients is an updated trust bundle or a new software build, not just a revocation.

Mozilla’s engineers state the concern directly: the incident lets technically unsophisticated people recover these keys, and the real risk is endpoints without effective revocation checking. Their conclusion was to emergency-remove trust in the whole emSign ECC Root CA – G3 root, so that clients which cannot receive revocation updates can still be protected by a root store update.

The root removal and the 27 October deadline

• emSign ECC Root CA – G3: removed by Mozilla on 20 October. Chrome is removing it, with the change reaching devices on 27 October. eMudhra has stopped issuing from every intermediate chaining to this root.
• emSign Root CA – G1: not being removed by Mozilla for now. Chrome is reviewing whether to keep it.
• Migration: about 30,000 certificates need to move, about 97% through ACME, to intermediates chaining to the G1 root. eMudhra estimated this in Mozilla’s incident report.
• Consequence: a legitimate website certificate that chains to the G3 root stops being trusted by Mozilla-based clients now and by Chrome from 27 October unless the site installs a certificate from another hierarchy.

Fix status by platform

Version data comes from the patch tracker maintained by Mozilla’s Dennis Jackson and from vendor advisories. Status is as of 22 October 2026 and changes often.

Browsers and operating systems

• Firefox: OneCRL block delivered on 17 October for standard installs. Firefox 158.0.1, ESR 115.43.1 and ESR 153.5.1 carry the block for installs where remote settings are disabled or blocked, per the CERT-In advisory. Firefox 158.0.2 fixes Android profiles that did not apply the block at startup.
• Chrome: CRLSet block from 17 October without a browser update. Root removal reaches devices on 27 October.
• Apple: blocked on 19 October. Microsoft: blocked on 20 October through automatic trust list updates. Machines that cannot receive them can use a script published on the tracker, preferably after checking with IT.
• macOS built-in tools: browsers block the certificates, but the built-in curl, git, python3, perl, ruby and openssl read /etc/ssl/cert.pem, which was not updated. The tracker documents a manual fix.
• Red Hat: bulletin RHSB-2026-012 covers RHEL 6 to 10 and says updated ca-certificates packages will be announced. It gives a workaround that blocks the two affected roots, and warns that this can also cut off legitimate certificates under those roots.

Linux distributions and trust bundles

• Ubuntu: ca-certificates 20260816ubuntu0.22.04.1, 20260816ubuntu0.24.04.1, 20260816ubuntu0.26.04.1 and 20260816ubuntu0.26.10.1.
• Debian: 20250419~deb12u2, 20250419+deb13u1 and 20260816+nmu1.
• Alpine: 20261020-r0. Fedora: 2026.2.92_v9.0.319. Arch: ca-certificates-mozilla 3.131.1-1. Gentoo: 20260816.3.125. FreeBSD: ca_root_nss 1.131.1 and updated releases.
• NSS: 3.131.1. curl CA bundle: 2026-10-20.

Languages, runtimes and tools

• Go: 1.27.3 and 1.26.10 (CVE-2026-111943). Programs must be rebuilt, and the filter cannot be disabled.
• Java: 27.0.1.0.2, 25.0.5.0.2, 21.0.13.0.2, 17.0.21.0.2, 11.0.33.0.2 and 8u511.
• Node.js: 22.23.4, 24.22.1 and 26.12.1.
• Python: certifi 2026.10.19 and pip 26.2.2. Rust: webpki-roots 1.0.10 and rustls-webpki 0.103.16. Electron: 44.9.1, 43.8.1 and 42.11.16. Deno: 2.9.8. Composer ca-bundle: 1.6.0 and 1.4.16.
• Pending on the tracker: Bottlerocket, Bun and Erlang certifi.

Containers and CI images bake the trust store in at build time. Rebuilding on an updated base image and redeploying is required, not just updating the host.

What is confirmed, and what is not

Confirmed

• Mozilla independently recovered the keys, and the researcher’s proof of key control was verified by Mozilla and Chrome.
• eMudhra revoked all eight intermediates, and Sectigo revoked the cross-signed copies.
• Chrome, Firefox, Apple and Microsoft block the intermediates. Mozilla removed emSign ECC Root CA – G3 from its root store.
• Google reported that no TLS certificates chaining to the six website intermediates were logged in Certificate Transparency before the block.

Not confirmed, or disputed

• Exploitation. No confirmed malicious use was reported as of 21 October. Cisco Talos had not seen malicious use as of 14:00 UTC that day, and Cloudflare reported no active exploitation on its services. Whether anyone used the keys before the report is unknown.
• The 60 million figure. It is eMudhra’s lifetime issuance, not the number of certificates at risk. The migration estimate is about 30,000.
• Revocation date. Mozilla’s incident report records eMudhra’s revocations on 18 October, between 09:24 and 09:38 UTC. Some news coverage and eMudhra’s own statement give 19 October.
• Report time. The researcher’s timeline shows emails sent at 18:05 UTC on 17 October. Mozilla recorded receipt at 20:06 UTC, forwarded by Chrome.
• Root cause. The explanation of a faulty script is eMudhra’s own and Mozilla has not verified the hardware claims. Chrome’s Root Program posted twelve follow-up questions in the incident report, including why earlier signature failures were handled by re-signing with the flawed keys, and what caused an invalid signature on a revocation list for emSign Root TLS CA – G1 published on 14 October 2026. Those questions were unanswered at the time of writing.
• Indian services. MeitY and eMudhra say Digital Signature Certificates and eSign are unaffected. No independent verification was found.

How to fix it

If you run websites or APIs

1. Find which of your certificates chain to emSign ECC Root CA – G3 or to a Sectigo cross-sign of the eMudhra intermediates. A quick check is to look at the issuer lines of the certificate chain your server presents.
2. Install a certificate from a different hierarchy before 27 October. eMudhra is migrating customers to its G1 root, and you can also use any other trusted CA.
3. Confirm that your certificate renewals use the new chain. For ACME clients, check that the renewal actually triggers a new issuance.
4. Test from outside your network with a current browser and from a command line client.

openssl s_client -connect example.com:443 -showcerts </dev/null 2>/dev/null | grep -iE "s:|i:"

Look for emSign or eMudhra in the issuer lines. If they appear, the certificate needs to be replaced.

If you run servers, containers or CI

1. Update the ca-certificates package or equivalent trust bundle on every host, then restart long-running services.
2. Rebuild container images on an updated base image and redeploy them, including CI runners and build images.
3. Update language runtimes and libraries that carry their own trust list, using the version table above. Rebuild Go programs.
4. Test each environment against the two test hosts published by Mozilla’s engineer. A certificate error is the expected, safe result. A successful connection means the workload still trusts the compromised keys.
5. Check embedded devices, appliances and older Java applications that manage their own trust stores. Security Brigade’s Yash Kadakia also points to payment gateways, vendor integrations and mobile apps that may use separate trust stores.

curl https://dv-g3b-emudhra.we-have-a-problem.com/
curl https://dv-g3b-aaa-emudhra.we-have-a-problem.com/

CERT-In’s recommendations

• Install the latest releases of Firefox, Firefox ESR, other browsers, applications and operating systems.
• Make sure devices pick up current revocation and distrust data through their trust stores.
• List the certificates and services that depend on the affected intermediates or on emSign ECC Root CA – G3, and judge what each blocking step will break.
• Swap in certificates from a trusted, unaffected hierarchy. This includes legitimate certificates that sit under the removed root.
• Check certificate chains, issuers, validity dates and revocation status, and never skip validation warnings or turn verification off.

Why this story is bigger than one company

The points below are interpretation and are kept separate from the facts above.

• Revocation protects browsers first. Everything that is not a browser depends on how quickly its trust bundle is updated and redeployed. Frozen trust stores in embedded and operational technology devices may never be updated, as Encryption Consulting notes in its analysis.
• Ceremony checklists confirm steps, not outcomes. The failure was a weak key, not a skipped step. A check of key strength after each key ceremony would have caught it, which is the lesson Encryption Consulting draws.
• CA distrust is a routine event to plan for. Knowing which certificates chain to which CA, and how fast they can be replaced, decides whether an incident costs an afternoon or a quarter.

Takeaway: keep an inventory of the certificates you depend on, the CAs they chain to and the places each client gets its trust anchors. That inventory is what turns an emergency like this one into a routine change.

Frequently asked questions

Was eMudhra hacked?

No hack has been reported. The keys were generated with too little randomness, so they could be recovered from public certificates. eMudhra says its systems were not breached and no data was lost.

Are my passwords or accounts at risk?

No misuse has been reported. Browsers that enforce Certificate Transparency could not have been fooled with these keys, and Chrome and Firefox blocked the intermediates within hours. Update your browser and operating system, and do not click through certificate warnings.

Are Indian digital signatures and eSign services affected?

MeitY and eMudhra say Digital Signature Certificates and eSign services, regulated separately by the Controller of Certifying Authorities, are unaffected. This comes from the ministry and the company, and no independent verification was found.

Will websites break?

Websites whose certificates chain to emSign ECC Root CA – G3 will stop being trusted. Mozilla removed that root on 20 October and Chrome’s removal reaches devices on 27 October. Site owners need to install a certificate from another hierarchy.

How many certificates are affected?

About 30,000 customer certificates need to be migrated, according to eMudhra. The 60 million figure in some posts is eMudhra’s total issuance over its lifetime, not the number at risk.

How do I check my own software?

Use the two test hosts published by Mozilla’s engineer. A certificate error means the client does not trust the compromised intermediates. A successful connection means it still does and needs an updated trust bundle.

What is the difference between a root and an intermediate CA?

A root CA is trusted directly by browsers and operating systems. An intermediate CA is licensed by a root to issue certificates day to day. If an intermediate key is compromised, it can be blocked by revoking it. If clients cannot receive revocations, the root that licensed it may need to be removed.

Sources and method

Sources: Mozilla’s Bugzilla incident report 2083449, the patch tracker maintained by Mozilla’s Dennis Jackson, the CERT-In advisory CIAD-2026-0050, Red Hat bulletin RHSB-2026-012, Cisco Talos, and reporting from The Register, The Hacker News, BleepingComputer, Help Net Security, CSO Online, ThePrint, Business Today and Encryption Consulting. Where a secondary source conflicted with Mozilla’s incident report, the incident report was used. Statements about eMudhra’s cause are eMudhra’s own and are attributed in the text. Single-source claims are labelled. Details may change as vendors and eMudhra publish updates.

Official references

Mozilla Bugzilla 2083449: eMudhra private key compromise of intermediate certificates

Mozilla engineer’s incident site and patch tracker

CERT-In advisory CIAD-2026-0050: compromise of eMudhra intermediate CA certificates

Red Hat: security bulletin RHSB-2026-012

Cisco Talos: compromised eMudhra intermediate certificates

News and analysis

The Register: Indian certification authority eMudhra’s private keys compromised

The Hacker News: eight eMudhra CA keys compromised

BleepingComputer: Mozilla, Google, Apple block compromised eMudhra CA certificates

Help Net Security: eMudhra security blunder left CA signing keys exposed

CSO Online: Google, Mozilla revoke eMudhra intermediates

ThePrint: MeitY sets up team to probe eMudhra certificate breach

Encryption Consulting: what the eMudhra compromise teaches about CA agility

You can also read this article on Medium.

Connect with me on LinkedIn.