English
English 日本語
Get a fix plan
Menu

Projects

Apache HTTP ServerApache Log4jnginxNode.jsOpenSSLPHPApache TomcatWordPressAll projectsStatusAlerts (soon)Method Get a fix plan
Data checked 8 open events tracked Official sources only

eMudhra intermediate CA compromise: what changed and how to check your stack

The private keys of eight eMudhra intermediate CAs turned out to be weak, and browsers, language runtimes and apps responded one by one. Each statement below links to its official source, with the quoted text one click away. The checks only read issuers, validity dates and trust-store entries.

Facts last checked against the stored sources on

What happened

  • Chrome's root program received a report on that the private keys of eight eMudhra subordinate CA certificates were compromised. The keys had been generated with weak entropy, so anyone could forge certificates that clients still trusting those CAs would accept.

    Source: Chrome and Android Security Teams

    Quoted text
    On Saturday, October 17, 2026, at 18:05 UTC, the Chrome Root Program received a report from a security researcher regarding the compromise of private keys associated with eight eMudhra subordinate Certification Authority (CA) certificates. The private keys for these certificates were generated with insufficient randomness (i.e., weak cryptographic entropy), enabling anyone to forge trusted HTTPS certificates to impersonate any website against clients that have not yet removed trust in those CAs.

  • eMudhra states that the eight intermediate issuing CAs of its global TLS business were revoked because their published keys were weak, and that they sit under its ECC root.

    Source: eMudhra

    Quoted text
    Eight intermediate (issuing) CAs in our Global TLS business were revoked because their published keys were weak. These intermediates sit under eMudhra's ECC root.

Chrome removes the eMudhra ECC root

  • Chrome removed emSign ECC Root CA - G3 from the Chrome Root Store. The removal is expected to reach all devices that rely on the Chrome Root Store on , and earlier on the Canary and Beta channels. Some legitimate certificates that chain to this root will stop working in Chrome.

    Source: Chrome and Android Security Teams

    Quoted text
    we have also removed emSign ECC Root CA - G3 (the root certificate that signed the compromised CA certificates) from the Chrome Root Store. Some legitimate certificates chaining to this root will cease to function in Chrome as a result, and eMudhra has committed to working with impacted subscribers to migrate customers off of the impacted root. This root removal is expected to be released for all devices relying on the Chrome Root Store Tuesday morning, October 27, 2026 PDT, and sooner on prerelease channels like Chrome Canary and Chrome Beta.

  • Chrome asks website operators whose certificates chain to emSign ECC Root CA - G3 to get and install a new TLS certificate from another PKI hierarchy that is in the Chrome Root Store, immediately, to avoid breakage.

    Source: Chrome and Android Security Teams

    Quoted text
    To avoid breakage, website operators with certificates chaining to emSign ECC Root CA - G3 must immediately acquire and install a new TLS certificate from another PKI hierarchy included in the Chrome Root Store

Who changed what

Microsoft: no official statement that this page could link was found at the last check. Where a project has its own event page, the fact links to it for the release list.

  • Mozilla's incident record names the eight intermediate CAs below. Six of them issue TLS certificates and two sign code.

    • EM EV TLS CA - G3B (eMudhra BV)
    • EM OV TLS CA - G3B (eMudhra BV)
    • EM DV TLS CA - G3B (eMudhra BV)
    • EM EV TLS CA - G3C (eMudhra Inc)
    • EM OV TLS CA - G3C (eMudhra Inc)
    • EM DV TLS CA - G3C (eMudhra Inc)
    • EM OV CS CA - G3B (eMudhra BV)
    • EM OV CS CA - G3C (eMudhra Inc)

    Source: Mozilla (Bugzilla)

    Quoted text
    6 of the impacted certificates are for TLS and trusted by the Chrome, Mozilla, Microsoft and Apple root programs. The other two certificates are for codesigning and trusted by Microsoft
    EM EV TLS CA - G3B (eMudhra BV), CCADB A012304
    EM OV TLS CA - G3B (eMudhra BV), CCADB A012308
    EM DV TLS CA - G3B (eMudhra BV), CCADB A012302
    EM EV TLS CA - G3C (eMudhra Inc), CCADB A012296
    EM OV TLS CA - G3C (eMudhra Inc), CCADB A012300
    EM DV TLS CA - G3C (eMudhra Inc), CCADB A012294
    EM OV CS CA - G3B (eMudhra BV), CCADB A012306
    EM OV CS CA - G3C (eMudhra Inc), CCADB A012298

  • Mozilla blocked the affected certificates in Firefox with OneCRL and released Firefox 158.0.1, Firefox ESR 153.5.1 and Firefox ESR 115.43.1 so that the block also reaches clients whose settings may have stopped them from receiving the OneCRL update.

    Source: Mozilla Security Blog · Event page: CVE-2026-113470

    Quoted text
    Mozilla engineers responded immediately, blocking the affected certificates in Firefox using OneCRL , Mozilla’s centralized list of revoked certificates.
    Today, we are also releasing Firefox 158.0.1 for Desktop and Android, along with Firefox ESR 115.43.1 and Firefox ESR 153.5.1 . These releases will distribute this protection for a minority of users whose custom settings may have prevented them from receiving the OneCRL update.

  • Apple began blocking twelve certificates of these intermediate CAs on . Apple says some command-line tools on macOS that read a certificate file of their own can still accept them until a later software update.

    Source: Apple Support

    Quoted text
    On 19 October 2026, Apple began blocking these 12 certificates on Apple devices.
    check certificates against /etc/ssl/cert.pem and can still accept these certificates until a future software update.

  • OpenJDK's vulnerability advisory for CVE-2026-114820 lists these releases and everything earlier as affected: 27.0.1.0.2, 25.0.5.0.2, 21.0.13.0.2, 17.0.21.0.2, 11.0.32.1 and 8u504.

    Source: OpenJDK Vulnerability Group

    Quoted text
    The affected versions are 27.0.1.0.2, 25.0.5.0.2, 21.0.13.0.2, 17.0.21.0.2, 11.0.32.1, 8u504, and earlier.
    CVE-2026-114820 security-libs/ javax.net.ssl 9.1

  • OpenJDK tracks the change as JDK-8395690. For a standalone runtime it says to update to a vendor build whose release note names that issue; if no build is available yet, to remove these four roots from the runtime's cacerts file and restart.

    • emsignrootcag1
    • emsignrootcag2
    • emsigneccrootcag3
    • comodoaaaca

    Source: OpenJDK

    Quoted text
    The runtime’s release note should document that it fixes issue JDK-8395690, CVE 2026-114820.
    $ keytool -delete -cacerts -alias "emsignrootcag1 [jdk]" $ keytool -delete -cacerts -alias "emsignrootcag2 [jdk]" $ keytool -delete -cacerts -alias "emsigneccrootcag3 [jdk]" $ keytool -delete -cacerts -alias "comodoaaaca [jdk]"

  • In the OpenJDK source repository the commit for 8395690 deletes the default cacerts files of the three eMudhra emSign roots (emsignrootcag1, emsignrootcag2, emsigneccrootcag3) and of comodoaaaca.

    Source: OpenJDK (GitHub)

    Quoted text
    8395690: CA certificate improvements
    Expand all lines: src/java.base/share/data/cacerts/emsignrootcag1 - 29 Lines changed: 0 additions & 29 deletions Load diff This file was deleted.
    Expand all lines: src/java.base/share/data/cacerts/emsignrootcag2 - 39 Lines changed: 0 additions & 39 deletions Load diff This file was deleted.
    Expand all lines: src/java.base/share/data/cacerts/emsigneccrootcag3 - 22 Lines changed: 0 additions & 22 deletions Load diff This file was deleted.
    Expand all lines: src/java.base/share/data/cacerts/comodoaaaca - 32 Lines changed: 0 additions & 32 deletions Load diff This file was deleted.

  • Python added a denylist of known compromised certificates to its ssl module. Chains that contain a listed certificate are rejected whatever the SSLContext policy says. CVE-2026-115557 is the tracking record; the event page shows which Python releases the official changelog lists.

    Source: Python Security Response Team · Event page: CVE-2026-115557

    Quoted text
    [CVE-2026-115557] Distrust compromised intermediate certificates in ssl module
    Python has added a denylist for known compromised certificates to the "ssl" module to ensure user safety even without certificate revocation configured. Known compromised certificates on this denylist will automatically be rejected regardless of the SSLContext policy configuration.

  • Electron added the same block to Chromium networking and to the Node.js tls, https and fetch modules. The advisory names no app-side workaround, so an app has to be rebuilt on a patched Electron: 44.9.1, 43.8.1 or 42.11.16 (or the pre-release listed for the newest line).

    Source: Electron (GitHub Security Advisory) · Event page: CVE-2026-115570

    Quoted text
    This Electron update adds the same block to both Chromium networking and Node.js tls , https and fetch .
    There are no app side workarounds, you must update to a patched version of Electron.
    Fixed Versions 45.0.0-beta.6 44.9.1 43.8.1 42.11.16

  • Electron's advisory names Go among the software that shipped the same mitigation, under CVE-2026-111943.

    Source: Electron (GitHub Security Advisory) · Event page: CVE-2026-111943

    Quoted text
    Other software has shipped the same mitigation, including Go (CVE-2026-111943)

  • Go go1.27.3 and go1.26.10, both released on , include security fixes to the crypto/x509 package. The event page lists the CVE record and Go's own entries.

    Source: The Go Project · Event page: CVE-2026-111943

    Quoted text
    go1.27.3 (released 2026-10-19) includes security fixes to the crypto/x509 package.
    go1.26.10 (released 2026-10-19) includes security fixes to the crypto/x509 package.

Check your own stack

These commands run on your own machine and only read what is installed there: versions, issuers, validity dates and trust-store entries. PatchBell does not scan your systems.

Your site's certificate (any OS)

Prints the issuer and validity dates of the certificate your server presents. An issuer that names eMudhra or emSign means the chain needs a closer look: find out which root it ends in and whether you can move to another CA.

openssl s_client -connect example.com:443 -servername example.com </dev/null 2>/dev/null | openssl x509 -noout -issuer -dates

Tool documentation: OpenSSL · OpenSSL

Quoted text
-servername name Set the TLS SNI (Server Name Indication) extension in the ClientHello message to the given value.
[ -noout ]
[ -dates ] [ -subject ] [ -issuer ]

Java (JDK cacerts)

Lists the entries of the JDK's default cacerts file that mention eMudhra, emSign or the AAA root. Replace the password if your cacerts uses another one, and run it for every JDK installed on the machine.

keytool -list -cacerts -storepass changeit | grep -i -E 'emudhra|emsign|comodoaaa'

Tool documentation: Oracle · OpenJDK

Quoted text
-list : Lists entries in a keystore
{ -cacerts }: Access the cacerts keystore
For JDK 11 and later, the keystore is in the file $JDK_HOME/lib/security/cacerts

Python (certifi and the default store)

Shows where certifi keeps its CA bundle and searches it for the affected roots, then shows the default CA file and directory that the ssl module uses.

python3 -c "import certifi; print(certifi.where())" | xargs grep -i -E 'emudhra|emsign'
python3 -c "import ssl; print(ssl.get_default_verify_paths())"

Tool documentation: certifi (PyPI) · Python Software Foundation

Quoted text
To reference the installed certificate authority (CA) bundle, you can use the built-in function: >>> import certifi >>> certifi.where()
Returns a named tuple with paths to OpenSSL’s default cafile and capath.

Linux system store

The first line reads the shared trust store on systems that use p11-kit (Fedora, RHEL, Arch and others). The second line lists the certificate directory that update-ca-certificates maintains on Debian and Ubuntu.

trust list | grep -i -E 'emudhra|emsign'
ls /etc/ssl/certs | grep -i -E 'emudhra|emsign'

Tool documentation: p11-kit (Debian manpage) · Debian ca-certificates (manpage)

Quoted text
trust - Tool for operating on the trust policy store
update-ca-certificates is a program that updates the directory /etc/ssl/certs to hold SSL certificates

Windows

Dumps the Trusted Root Certification Authorities store of the computer and keeps the lines that mention eMudhra or emSign. Run it in a Command Prompt; add -user to look at the current user's store instead.

certutil -store Root | findstr /i "emudhra emsign"

Tool documentation: Microsoft Learn

Quoted text
-store Dumps the certificate store.
-verifystore Verifies a certificate in the store.

Browser

In Chrome, open DevTools, go to Security > Overview and choose View certificate. Read the Issued by line and the certification path of the certificate the browser received; the same view exists in other browsers under their site information.

Tool documentation: Google Chrome for Developers

Quoted text
From the Security > Overview click View certificate to quickly inspect the main origin's certificate.

Replace the certificate

  1. List every certificate you operate that chains to an eMudhra or emSign root: run the site check on each public host name and look at internal services that ship their own trust file.
  2. Get a new TLS certificate from a CA in another hierarchy that Chrome's root store includes, as Chrome asks of site operators.
  3. Install the new certificate together with the intermediate certificates your CA provides (the full chain), not the server certificate alone.
  4. Restart or reload every service that serves the chain: web server, load balancer, proxy and the application itself.
  5. Run the site check again and confirm the issuer has changed. Repeat the platform checks on hosts, containers and runtimes that carry their own trust data.
  6. If a runtime cannot be updated yet, follow the vendor's own instructions from the facts above; OpenJDK, for example, publishes steps for standalone runtimes.