Chrome and Firefox blocked eMudhra's weak CA keys within hours. Servers and containers are another matter

At 18:05 UTC on Saturday 17 October 2026, a researcher credited as Wayne told Google, Mozilla, Apple, Microsoft and eMudhra that the private keys behind eight intermediate certificates issued by eMudhra, an Indian certificate authority, could be worked out from the public certificates themselves. One hundred minutes later, according to Google's published timeline, Chrome was blocking the six intermediates authorised for TLS through a CRLSet push that needed no browser restart. Firefox followed that night, Apple on the 19th and Microsoft, on Windows, on the 20th.

Everything outside the browser has moved far more slowly. The tracking page run by Dennis Jackson, a cryptography engineer at Mozilla, lists 37 programs and packages that have needed a dedicated fix, from the ca-certificates package of several distributions to Java, Go, Node.js, Python's certifi and Electron. When we checked on 22 October, three were still marked as pending, and the list does not include RHEL, which had no fixed package either. That part of the incident falls to systems and development teams.

What went wrong with eMudhra's keys?

Certificate authorities sign websites' digital certificates through intermediate certificates, which chain up to a root held in trust stores. Whoever controls the private key of a trusted intermediate can mint a valid certificate for any domain and impersonate a service to clients whose connection they can intercept.

Mozilla's preliminary analysis in the Bugzilla incident report needed one line: "The 8 impacted keys all used integers less than 256." These were P-384 elliptic-curve keys whose private value was effectively zero apart from the final byte. BleepingComputer independently confirmed that one published by a researcher, with a value of 4, matched the "EM OV TLS CA - G3C" intermediate.

All eight came from a batch of 24 generated on 30 April 2025: six TLS intermediates covering domain, organisation and extended validation, plus two for code signing. They chained to the emSign Root TLS CA - G3 and emSign Root CS CA - G3 roots, which are cross-signed by emSign ECC Root CA - G3, and in May 2025 Sectigo also cross-signed each intermediate under its AAA Certificate Services root.

eMudhra's account in the same report blames human error compounded by a code defect. An authorised deviation added a wrap and unwrap test of the keys to the ceremony, because those keys were meant to be exported. The script then created a second, weaker pair inside the hardware security module (HSM), and because the labels looked alike, those weak pairs were used by mistake to build the certificate requests.

How keys with such small values came to be generated is still unexplained. One participant in the Mozilla discussion points out that generating keys the approved way inside an HSM does not produce a private scalar below 256 on its own, and asks for the devices' CMVP certificate number; eMudhra describes them as FIPS 140-2 Level 3 compliant. The company says its systems were not breached, that the intermediates issued no certificates to end users and that the flaw went unnoticed for about 18 months.

Why were browsers covered so quickly?

Browsers have revocation channels the vendor pushes to every installation with no user involvement, such as CRLSet in Chrome and OneCRL in Firefox. On Android, Google pushed a Google Play Services update at around 22:00 UTC on Monday 19 October, which it said had reached most devices by the 20th. CRLSet blocks by public key, so it also covers Sectigo's cross-signatures.

The report reached Mozilla's official inbox at 20:06 UTC on the 17th, forwarded by Chrome. Mozilla had recovered the keys itself by 21:48 and completed its block at 22:59. For installations that do not receive those remote settings it released Firefox 158.0.1 and ESR 115.43.1 and 153.5.1 (CVE-2026-113470). On Android, some Firefox profiles did not apply the list at startup until 158.0.2 on 21 October.

Certificate Transparency (CT) adds a further barrier. It consists of public logs in which every publicly trusted TLS certificate must be recorded, and Chrome enforces it by default. Google states that no TLS certificate chaining to these intermediates had been logged before the block. A CT-enforcing client would only accept a forged certificate after it had been published, which would have given it away.

Where are those intermediates still trusted?

The risk persists in programs that carry an unpatched copy of the roots and also skip revocation checks and CT. BleepingComputer reports Jackson's warning about the curl shipped with macOS at /usr/bin/curl, which does not check revocation. His tracker widens the list: on macOS, curl, git, python3, perl, ruby and openssl all read /etc/ssl/cert.pem, which had not been updated, and the bundled pip relies on stale roots.

How does Windows protect against these intermediates?

According to the tracker, Microsoft ships the block through Windows' automatic certificate trust list updates. For machines without those updates, the tracker provides a script that adds 16 certificates to the untrusted store, covering software that validates through the system store and chain engine, such as Schannel for TLS and Authenticode for code signing. Applications that ship their own CA bundle need a separate update.

Where do the Linux distributions stand?

Mozilla removed emSign ECC Root CA - G3 from its NSS library (version 3.131.1) on 20 October, and Ubuntu (USN-8944-1), Debian (DSA-6572-1) and Alpine have shipped ca-certificates packages without that root. Red Hat's bulletin RHSB-2026-012 lists RHEL 6 to 10 as affected and OpenShift, OpenStack and its product containers built on RHEL or UBI images as potentially affected. Customers' own containers should be rebuilt once base images are updated.

As of 22 October Red Hat had not shipped a fixed ca-certificates package for RHEL. It had for its Hardened Images, under a new CVE (CVE-2026-114406) that it rates as critical, and it had shipped Go 1.26.10 for RHEL 8, 9 and 10 under Go's CVE-2026-111943, rated important.

Why do Sectigo's cross-signatures matter?

Sectigo's cross-signatures give each compromised intermediate an alternative chain, bringing the total to 16 certificates to block according to the Windows script on the tracker. Sectigo revoked them on 19 October, but revocation only helps clients that check it. Its root had already been removed from Chrome and Firefox, yet Sectigo notes in Mozilla's report that it remains in Microsoft's and Apple's programmes.

Red Hat's interim workaround therefore distrusts two roots at once, emSign ECC Root CA - G3 and Comodo AAA Services root, the name AAA Certificate Services goes by in Linux trust stores. Red Hat's knowledge-base solution warns that legitimate certificates chaining to them will stop validating as well, and advisory CIAD-2026-0050 from India's CERT-In gives the same warning about removing emSign ECC Root CA - G3.

How are Java, Go, Node.js and Python fixed?

OpenJDK's advisory of 21 October says that if the JDK comes from a Linux distribution such as Debian, Ubuntu, Fedora or RHEL, updating the system's certificates is sufficient, while FreeBSD and Homebrew builds must be updated directly. Standalone JDKs block the intermediates through their blocked.certs list and need the new release (CVE-2026-91403, CVSS 9.1).

Go released 1.27.3 and 1.26.10 on 19 October (20 October UTC), which reject chains containing any of the eight keys (CVE-2026-111943). According to The Hacker News, Go 1.25 and earlier receive no fix. On Linux, Go reads the system store, so the ca-certificates update already protects it; the filter on the eight keys, and binaries that embed their own roots, require a rebuild with a patched toolchain.

Node.js released 22.23.4, 24.22.1 and 26.12.1 on 21 October, and certifi, Python's root bundle, released 2026.10.19. Every virtual environment with its own copy of certifi needs the update.

Why did nobody connect the earlier failure to the keys?

In this incident's report, Mozilla recalls one from June 2025 (bug 1970728, opened by Sectigo). The revocation lists for the six TLS intermediates had been failing verification since late May 2025, since the 23rd according to an Internet Archive snapshot Mozilla cites with caution.

eMudhra now says it had signed them with the original keys, not the ones in the certificates, and in June 2025 re-signed them with the weak keys. That incident was closed without anyone tying the mismatch to the quality of the keys, and Chrome is now asking why eMudhra did not halt operations then.

Once the problem was spotted, recovering the keys was trivial. Mozilla's report says some AI agents managed it from a simple prompt, and The Hacker News reports that researcher Scott Helme derived all eight in under a second. eMudhra says the keys were found "possibly with AI-assisted techniques", while Wayne said on Mozilla's forum that he used Google's paranoid_crypto library out of the box.

What should operators of emSign ECC Root CA - G3 certificates do?

Google asks operators to replace certificates chaining to emSign ECC Root CA - G3 straight away with ones from another hierarchy. Chrome will drop that root in version 43 of its root store, expected on 27 October, and Mozilla removed it from NSS on the 20th, so those certificates already fail in clients with the updated Mozilla list, such as Debian, Ubuntu, certifi and Node.js.

eMudhra estimates in Mozilla's report that around 30,000 certificates need migrating, 97% of them issued over ACME, the protocol for automated issuance and renewal, and it stopped issuing under that root on 20 October. According to the CT data Chrome cites, almost all come from subordinate CAs of InCommon, the trust service run by Internet2, the US academic consortium.

Automation makes the move easier, with caveats. Chrome warns that ACME clients without the ARI extension will not replace a certificate outside its renewal window, and that moving from the ECC G3 root to the RSA G1 root may require client changes. With certificates bought and installed by hand, the move means tracing every service, network appliance and application that uses one.

Where else do copies of the roots live on a server?

Trust in certificate authorities is a software dependency, with a version and a patch cycle like any library. A typical server holds several copies: the operating system's, that of a standalone JDK, the one bundled with Node.js, the one certifi drops into each Python environment, the one an Electron app carries and the one frozen into every container image. Apart from the system copy, none of them shows up in the patch console, and an application's SBOM, if it records them, lists them as ordinary packages without saying which roots they contain.

How can exposure be checked without disrupting services?

The most reliable test is to ask the client. The tracker provides test servers that present the chains through the compromised intermediates, both direct and through Sectigo, and a certificate error means the client already rejects them. Run the test where each program runs, inside its container and with its own environment, and with each runtime (curl, Python, Node.js), since each may use a different store.

# From the machine or image under test: 60 = rejected (good), 0 = accepted
for h in dv-g3b-emudhra dv-g3b-aaa-emudhra; do curl -sS -o /dev/null "https://$h.we-have-a-problem.com/"; echo "$h: $?"; done

# Python with the system store and with certifi (used by requests and pip)
python3 -c "import socket,ssl; h='dv-g3b-emudhra.we-have-a-problem.com'; ssl.create_default_context().wrap_socket(socket.create_connection((h,443),timeout=10),server_hostname=h)" && echo ACCEPTED || echo REJECTED
python3 -c "import socket,ssl,certifi; h='dv-g3b-emudhra.we-have-a-problem.com'; ssl.create_default_context(cafile=certifi.where()).wrap_socket(socket.create_connection((h,443),timeout=10),server_hostname=h)" && echo ACCEPTED || echo REJECTED

# Node.js
node -e "require('https').get('https://dv-g3b-emudhra.we-have-a-problem.com/', r => { console.log('ACCEPTED'); r.destroy(); }).on('error', e => console.log('REJECTED', e.code))"

# Go binaries: toolchain version used to build them (fixed: go1.26.10, go1.27.3 or later)
go version ./binary

The second set checks whether each store still contains the affected roots.

# RHEL, Fedora and derivatives (p11-kit): no output = not trusted
trust list --filter=ca-anchors | grep -i -E "label: (emSign ECC Root CA - G3|Comodo AAA Services root)"

# Debian and Ubuntu
ls /etc/ssl/certs/ | grep -i -E "emSign_ECC_Root_CA_-_G3|Comodo_AAA_Services_root"

For Java and Python environments, the check runs against each one's store.

# JDK 9 or later (on JDK 8: -keystore "$JAVA_HOME/jre/lib/security/cacerts")
# On a patched JDK, AAA still appears because the block is in blocked.certs
keytool -list -v -cacerts -storepass changeit | grep -i -E "CN=emSign ECC Root CA - G3|CN=AAA Certificate Services"

# Python with certifi, using each virtual environment's interpreter: 0 = root removed, 3 = present
grep -c "emSign ECC Root CA - G3" "$(python3 -m certifi)"

Finding the root does not prove the client accepts the intermediates, since some fixes, Go's and the JDK's among them, block them directly. Other emSign roots, such as emSign Root CA - G1, are unaffected, so the match has to be exact. A TLS-inspecting proxy replaces the chain with its own and skews curl's result, and an exit code other than 60 or 0 may simply be a network fault.

Red Hat's three conditions offer a sensible way to prioritise: a client that trusts the intermediates, an attacker holding one of the keys and a position to intercept the connection. The keys have been public since 20 October, so the third condition is the deciding one. Start with programs that reach the internet from networks the organisation does not control, such as roaming laptops, update agents, third-party API integrations and CI/CD runners. Test any stopgap that removes whole roots in a controlled environment first, as it also cuts legitimate connections.

Which controls held, and which assumptions broke?

The controls that worked were the ones that need nobody to act, such as vendor-pushed revocation and CT enforcement. For the work still ahead, the head start belongs to teams that issue over ACME and rebuild container images on a schedule from a CI pipeline, where a ca-certificates update arrives with routine work. Monitoring CT logs for the organisation's domains belongs on the same list, and this month CT data is how Google found the certificates obtained after the .gh, .sl and .as ccTLD hijack.

Common assumptions broke as well, such as the belief that patching the operating system patches the trust of everything running on it, or that a stable base image can go months without a rebuild. Manual certificate renewal stops being minor admin once a root can leave Chrome on a week's notice and NSS on the day it is announced.

Systems hardening should record where each copy of the roots lives and who maintains it, and attack surface management should cover the certificates your public services present. That same inventory is what the move to post-quantum cryptography will demand, since it requires knowing which algorithms, roots and libraries each system uses and being able to swap them without rewriting applications.

The case also illustrates one of the lessons from the digital supply chain, because a trusted third party's mistakes reach everyone who trusts it. DevSecOps processes should treat roots as one more dependency, as exposed as any other to a supply chain attack.

Is there any sign the keys were used?

There is no evidence of exploitation as of 22 October 2026. The absence of these intermediates from the CT logs protects CT-enforcing clients. Against everything else, quiet use since April 2025, and more easily since the keys were published on 20 October, would leave no public trace.

Chrome has put twelve questions to eMudhra on customer communication, migration, the 2025 incident and a badly signed revocation list for a G1 root published on 14 October, and will review whether eMudhra's other root in its store, emSign Root CA - G1, should stay. Mozilla asked for hardware details, and another participant wants the generation script and ceremony records. In India, CERT-In issued its advisory and the Ministry of Electronics and Information Technology (MeitY) has opened an investigation, according to The Hacker News.

The next root removal will raise the same question: which programs trust which roots. The inventory that answers it is what lets an organisation contain the problem while supplier fixes arrive.

This analysis draws on public information from Google, Mozilla, Red Hat, OpenJDK, eMudhra and the outlets cited, as available on 22 October 2026, and may change as the investigation develops. The commands are indicative, for inventory and testing only, and should be reviewed and tried in a controlled environment before use in production. Removing trusted roots can interrupt legitimate connections.