Mitigating the eMudhra Intermediate CA Compromise (CVE-2026-113812) on Rocky Linux 8, 9, 10, and LTS Variants

cve cve-2026-113812 security certificates tls openssl rocky linux lts mitigation troubleshooting

Arian Cabrera
Sr. Customer Support Engineer

Oct 21, 2026

Introduction

On 2026-10-17, the private keys of eight eMudhra intermediate certificate authority (CA) certificates were reported as compromised. The keys were generated incorrectly by the CA and can be recovered from the certificates themselves. The certificates were issued in April 2025, so the keys may have been recoverable since then. Anyone holding one of these keys can issue a TLS certificate for any domain. An attacker who can intercept or redirect a client's traffic can use such a certificate to impersonate a server.

The CA has revoked the intermediates, and the major browsers and operating system vendors have blocked them. Clients that don't check revocation are still exposed. They trust the intermediates for as long as a root that signs them stays in their trust store.

On Rocky Linux, the system trust store comes from the ca-certificates package. Two roots in that store chain to the compromised intermediates:

emSign ECC Root CA - G3, through a cross-sign of emSign Root TLS CA - G3
Comodo AAA Services root

Mozilla has removed emSign ECC Root CA - G3 from its trusted root list in NSS 3.131.1 (built-in root list version 2.92). Mozilla had already stopped trusting Comodo AAA Services root for TLS before this incident. Until a ca-certificates package with the updated list is available for your variant, the workaround in this article distrusts both roots locally.

CVE-2026-113812 (CWE-295, Improper Certificate Validation) covers the copy of this root list in the Perl Mozilla::CA module. The upstream module removed the root in version 20261020. On Rocky Linux, the perl-Mozilla-CA package points Mozilla::CA at the system bundle, so the same workaround covers Perl clients (see Notes).

Problem

Any client that reads the system trust store and doesn't check revocation accepts certificates issued by the compromised intermediates. This includes OpenSSL, curl, dnf, Java and Perl clients that use Mozilla::CA. An attacker in a position to intercept traffic from such a client can present a forged certificate for any host, and the client accepts it as valid.

Which roots are trusted for TLS depends on the ca-certificates build. Older builds trust both roots. Current builds trust only emSign ECC Root CA - G3. CIQ has confirmed the following builds:

Variant	`ca-certificates` build	Roots trusted for TLS
RLC Pro LTS 8.6	`2024.2.69_v8.0.303-80.0.el8_6.86ciq_lts`	Both
RLC Pro LTS 9.2	`2022.2.54-90.2.el9`	Both
RLC Pro LTS 9.2	`2023.2.60_v7.0.306-90.1.el9_2`	Both
RLC Pro LTS 9.2	`2024.2.69_v8.0.303-91.4.el9_2.92ciq_lts`	Both
RLC Pro LTS 9.6	`2024.2.69_v8.0.303-91.4.el9_4`	Both
RLC Pro FIPS 9.6	`2024.2.69_v8.0.303-91.4.el9_4`	Both
RLC Pro 9	`2025.2.80_v9.0.305-91.el9`	`emSign ECC Root CA - G3`
RLC Pro 10	`2025.2.80_v9.0.305-102.el10`	`emSign ECC Root CA - G3`
CIQ Bridge	Pending	Both

Rocky Linux community releases are also affected. CIQ does not publish patched packages for community Rocky Linux editions. For community release patching status, refer to Rocky Linux Errata.

Treat any variant not listed above as affected until the check in the next section shows otherwise.

The attack requires the ability to intercept or redirect network traffic between the client and the server. It doesn't give an attacker access to the system itself.

Status

No fixed ca-certificates package is available yet for Rocky Linux 8, 9, 10, the CIQ LTS and FIPS variants, or CIQ Bridge. This article will be updated when fixed packages ship.
A tested workaround is available. Adding both roots to the local trust blocklist removes them from every bundle that update-ca-trust generates, including the Java cacerts file. It takes effect for new connections without a reboot.
Recommended action: Check your systems with the commands below. Apply the workaround on every affected system, prioritizing systems that make outbound TLS connections over untrusted networks.
Applications with their own CA bundle are not covered by the workaround. Python certifi, Node.js and statically built Go binaries need their own updates (see Notes).
Open a support case if you need help assessing exposure across your fleet.

Checking a System

List the affected roots that the system trusts for TLS:

trust list --filter=ca-anchors --purpose=server-auth | grep -E 'label: (emSign ECC Root CA - G3|Comodo AAA Services root)$'

Include --purpose=server-auth. Without it, current builds also list Comodo AAA Services root, which they trust only for email and code signing.

Then test against the two hosts published by the incident page. Each host tests a different root path, so check both:

curl -sS -o /dev/null https://dv-g3b-emudhra.we-have-a-problem.com/; echo $?
curl -sS -o /dev/null https://dv-g3b-aaa-emudhra.we-have-a-problem.com/; echo $?

The system is affected if the trust list command prints any label, or if either curl command returns exit code 0. Exit code 60 (certificate verification failed) means the system rejects that chain. Exit code 7 or 28 means the test host could not be reached. Those hosts are under heavy load, so retry after a few seconds.

Mitigation

The workaround copies both roots into the local blocklist folder and regenerates the trust bundles. Certificates in that folder are distrusted, even when the same certificate is still shipped by the ca-certificates package. Blocking Comodo AAA Services root is needed only on the older builds, but it is safe to apply everywhere.

Rocky Linux 9, 10, and el9 LTS and FIPS Variants

Back up the blocklist folder first:

sudo cp -a /etc/pki/ca-trust/source/blocklist /root/blocklist.bak

Add both roots to the blocklist and regenerate the trust bundles:

sudo trust extract --overwrite --format=pem-bundle --filter='pkcs11:object=emSign%20ECC%20Root%20CA%20-%20G3;type=cert' /etc/pki/ca-trust/source/blocklist/emSign_ECC_Root_CA_-_G3.pem
sudo trust extract --overwrite --format=pem-bundle --filter='pkcs11:object=Comodo%20AAA%20Services%20root;type=cert' /etc/pki/ca-trust/source/blocklist/Comodo_AAA_Services_root.pem
sudo update-ca-trust

Rocky Linux 8, el8 LTS Variants, and CIQ Bridge

On el8 and CentOS 7 (CIQ Bridge), the folder is named blacklist instead of blocklist. Back it up first:

sudo cp -a /etc/pki/ca-trust/source/blacklist /root/blacklist.bak

Add both roots and regenerate the trust bundles:

sudo trust extract --overwrite --format=pem-bundle --filter='pkcs11:object=emSign%20ECC%20Root%20CA%20-%20G3;type=cert' /etc/pki/ca-trust/source/blacklist/emSign_ECC_Root_CA_-_G3.pem
sudo trust extract --overwrite --format=pem-bundle --filter='pkcs11:object=Comodo%20AAA%20Services%20root;type=cert' /etc/pki/ca-trust/source/blacklist/Comodo_AAA_Services_root.pem
sudo update-ca-trust

After Applying

No reboot is needed for new connections. Long-running processes that loaded the trust bundle at startup, such as Java application servers, keep the old bundle until they restart.

Warning: Any server whose only chain of trust leads to one of these two roots will fail TLS verification after the workaround. In CIQ testing, dnf makecache, depot.ciq.com, dl.rockylinux.org and google.com kept working on every tested variant. Test connections to your own internal and third-party services before you roll the workaround out across a fleet.

The blocklist lives in /etc, so ca-certificates package updates don't overwrite it.

Verification

Run the checks from Checking a System again:

trust list --filter=ca-anchors --purpose=server-auth | grep -E 'label: (emSign ECC Root CA - G3|Comodo AAA Services root)$'
curl -sS -o /dev/null https://dv-g3b-emudhra.we-have-a-problem.com/; echo $?
curl -sS -o /dev/null https://dv-g3b-aaa-emudhra.we-have-a-problem.com/; echo $?

The trust list command should print nothing, and both curl commands should fail with a certificate error and return exit code 60.

CIQ tested the workaround on RLC Pro LTS 8.6, 9.2 and 9.6, RLC Pro FIPS 9.6 in FIPS mode, RLC Pro 9.8, and RLC Pro 10.2. On each system, both anchors were removed, and curl, Perl Mozilla::CA and Java clients rejected the test hosts afterward.

Reverting the Mitigation

Revert the workaround only after a fixed ca-certificates package is installed. Remove the two blocklist files and regenerate the trust bundles.

On Rocky Linux 9, 10, and el9 LTS and FIPS variants:

sudo rm -f /etc/pki/ca-trust/source/blocklist/emSign_ECC_Root_CA_-_G3.pem /etc/pki/ca-trust/source/blocklist/Comodo_AAA_Services_root.pem
sudo update-ca-trust

On Rocky Linux 8, el8 LTS variants, and CIQ Bridge:

sudo rm -f /etc/pki/ca-trust/source/blacklist/emSign_ECC_Root_CA_-_G3.pem /etc/pki/ca-trust/source/blacklist/Comodo_AAA_Services_root.pem
sudo update-ca-trust

In CIQ testing, this restored the original trust bundles exactly. If the folder held other files before the workaround, compare it with the backup in /root.

Resolution

When a fixed ca-certificates package is available for your variant, install it:

sudo dnf update ca-certificates

For CIQ Bridge (CentOS 7) systems, use yum instead of dnf:

sudo yum update ca-certificates

Confirm that the trust list check from Checking a System still prints nothing with the blocklist files removed, then revert the workaround as described above. Run the curl checks afterward. Both should return exit code 60.

Notes

Perl Mozilla::CA (CVE-2026-113812). On Rocky Linux 8, 9 and 10, the perl-Mozilla-CA package returns the system bundle path /etc/pki/tls/certs/ca-bundle.crt instead of its own copy of the root list. In CIQ testing, Perl clients using Mozilla::CA rejected both test hosts once the workaround was applied. Perl modules installed from CPAN into a separate path carry their own bundle and need version 20261020 or later.
Java. update-ca-trust regenerates the Java cacerts file. In CIQ testing, Java clients rejected both test hosts once the workaround was applied. Restart Java services so they load the regenerated file.
NSS applications. NSS applications read the system store through p11-kit and are expected to honor the blocklist. CIQ has not tested this path. Run your own TLS checks from those applications against the two test hosts above.
Applications that ship their own CA bundle are not covered. Python certifi in a virtual environment, Node.js and statically built Go binaries use a bundle compiled into or shipped with the application. Update them to the fixed versions listed on the incident page, for example certifi 2026.10.19 or Node.js 22.23.4, 24.22.1 or 26.12.1.
Email and code signing trust. Blocking Comodo AAA Services root also removes it from the email and code signing bundles. Systems that validate S/MIME or code signatures that chain to this root will reject them while the workaround is in place.
Browsers. Firefox, Chrome and other browsers that receive their vendor's revocation updates already block the compromised intermediates.