# eMudhra Intermediate CA Compromise Source: https://emudhra.we-have-a-problem.com Kiwi News: https://news.kiwistand.com/stories/eMudhra-Intermediate-CA-Compromise?index=0x6ad7c0af18a5eb5f52c569eb5894310c2783b67636ac2f1ea86c62b5953ac92b8776193f Submitted by tim on 2026-10-20 UTC, 2 upvotes, 0 comments ## Summary The private keys of eight eMudhra intermediate CA certificates have been compromised, and they chain to roots trusted by the Mozilla, Microsoft, Apple and Chrome root programs. Wayne demonstrated the compromise by signing a message with each key and reported it on 17 October, and Firefox and Chrome have blocked the certificates since that date. Mozilla, Apple and Chrome have also distributed revocation data, but many other clients need software updates. An attacker holding any of the keys could impersonate any website or service. ## Article 20th October 2026 The private keys of eight eMudhra intermediate CA certificates have been compromised. They chain to roots trusted by the Mozilla, Microsoft, Apple and Chrome root programs and by many downstream trust stores. How do we know? To demonstrate that the keys are compromised, the original reporter Wayne signed the following message with the private key of each of the eight intermediate CAs and reported it to the Root Program Teams on the 17th of October: We have a problem here - Wayne proof.zip contains the message, and for each intermediate the certificate, its public key and a signature on the message. To verify with OpenSSL: openssl x509 -in EM-DV-TLS-CA-G3B.crt.pem -noout -pubkey | diff - EM-DV-TLS-CA-G3B.pub.pem openssl dgst -sha384 -verify EM-DV-TLS-CA-G3B.pub.pem -signature EM-DV-TLS-CA-G3B.sig message.txt What actions have been taken? The root programs and many downstream trust stores have taken action to protect their users. The certificates have been blocked in Firefox and Chrome since the 17th of October, in Apple devices since the 19th and on Microsoft platforms since the 20th. The issue was responsibly disclosed to downstream trust stores on the 19th of October. Many have already released updates or are in the process of releasing updates. What are the consequences? An attacker with the private key of any of the compromised intermediate CAs could impersonate any website or service. This has already been remediated by Mozilla, Microsoft, Apple, and Chrome for their users through their tools for distributing revocation information such as OneCRL, CRLite and CRLSets. The CA has also revoked the compromised intermediate certificates. However, many other clients do not consume revocation information and require software updates to ensure they no longer trust the compromised intermediates. Does your client still trust the compromised intermediates? Intermediate CAChains toResult To check curl or other command-line clients, run: curl https://dv-g3b-emudhra.we-have-a-problem.com/ curl https://dv-g3b-aaa-emudhra.we-have-a-problem.com/ A certificate error means the client does not trust the compromised intermediates. To check a trust store offline, chains.zip contains the certificate chain served by each of the twelve hosts above in PEM format, with instructions for verifying them with OpenSSL. impacted-intermediates.json lists the eight intermediates and their Sectigo cross-signs. roots.json lists the roots they chain to. What is known about the cause? The private keys for the intermediate certificates were incorrectly generated by the CA. This means that anyone can recover them from the certificates. This would have been possible since the certificates were created in April 2025. There are no entries in the certificate transparency logs for these intermediates in that period, indicating that CT-enforcing clients like Firefox, Chrome, Edge and Safari could not have been attacked. However, many clients outside of the browser ecosystem do not enforce Certificate Transparency. We do not know if attackers exploited the flawed key generation to target these clients. Further technical information about the cause is captured in the initial incident report in Mozilla's bug tracker. What actions can trust store operators take? Please see this thread in Mozilla's dev-security-policy forum. What actions can users take? Users should update their browsers and operating systems to the latest versions as soon as possible. What about developer software and packages? SoftwarePatched version Ubuntu ca-certificates20260816ubuntu0.22.04.1, 20260816ubuntu0.24.04.1, 20260816ubuntu0.26.04.1, 20260816ubuntu0.26.10.1 Debian ca-certificates20250419~deb12u2, 20250419+deb13u1, 20260816+nmu1 Arch Linux ca-certificates-mozilla3.131.1-1 Gentoo ca-certificates20260816.3.125 Fedora ca-certificates2026.2.92_v9.0.319 FreeBSD ca_root_nsspending Chainguard ca-certificates20260909-r3 Alpine Linux ca-certificates20261020-r0 NSS3.131.1 curl CA bundle2026-10-20 Cloudflare CFSSL trust store2026.10.1 Homebrew ca-certificates2026-09-25_1 Go1.27.3, 1.26.10 Node.jspending Python certifi2026.10.19 pip26.2.2 uv0.13.4 Rust rustls-webpki0.103.16 Rust webpki-roots / webpki-root-certs1.0.10 Electron44.9.1, 43.8.1, 42.11.16 Bunpending Composer ca-bundle1.4.16, 1.6.0 Elixir castore1.0.22 Perl Mozilla::CA20261020 Add more at github.com/galadran/we-have-a-problem.com. Are there workarounds for macOS curl? macOS blocks the compromised intermediates, but the built-in /usr/bin/curl verifies certificates against /etc/ssl/cert.pem without checking revocation, and that file has not been updated. To remove the affected roots from it, run: sudo cp /etc/ssl/cert.pem /etc/ssl/cert.pem.bak && awk '/^(###|===) /{skip=0} /^=== .*\/CN=(AAA Certificate Services|emSign ECC Root CA - G3)$/{skip=1} !skip' /etc/ssl/cert.pem.bak | sudo tee /etc/ssl/cert.pem > /dev/null Are there workarounds for Linux? Until a distribution ships an updated ca-certificates package, expert users can distrust the affected roots in the system trust store. This is NOT recommended for ordinary users. On Debian and Ubuntu, run as root: sed -i \ -e 's|^mozilla/emSign_ECC_Root_CA_-_G3.crt|!&|' \ -e 's|^mozilla/Comodo_AAA_Services_root.crt|!&|' \ /etc/ca-certificates.conf && update-ca-certificates On Alpine, run as root: apk add ca-certificates && sed -i -e 's|^mozilla/emSign_ECC_Root_CA_-_G3.crt|!&|' \ /etc/ca-certificates.conf && update-ca-certificates On Fedora, RHEL, CentOS Stream, Rocky Linux, AlmaLinux and Amazon Linux 2023, run as root: d=/etc/pki/ca-trust/source/blocklist; [ -d $d ] || d=/etc/pki/ca-trust/source/blacklist trust extract --overwrite --format=pem-bundle \ --filter='pkcs11:object=Comodo%20AAA%20Services%20root;type=cert' \ $d/Comodo_AAA_Services_root.pem && trust extract --overwrite --format=pem-bundle \ --filter='pkcs11:object=emSign%20ECC%20Root%20CA%20-%20G3;type=cert' \ $d/emSign_ECC_Root_CA_-_G3.pem && update-ca-trust On openSUSE and SLES, run as root: d=/etc/pki/trust/blocklist; [ -d $d ] || d=/etc/pki/trust/blacklist trust extract --format=pem-bundle \ --filter='pkcs11:object=Comodo%20AAA%20Services%20root;type=cert' \ $d/Comodo_AAA_Services_root.pem && trust extract --format=pem-bundle \ --filter='pkcs11:object=emSign%20ECC%20Root%20CA%20-%20G3;type=cert' \ $d/emSign_ECC_Root_CA_-_G3.pem && update-ca-certificates On Arch Linux, run as root: trust extract --format=pem-bundle \ --filter='pkcs11:object=emSign%20ECC%20Root%20CA%20-%20G3;type=cert' \ /etc/ca-certificates/trust-source/blocklist/emSign_ECC_Root_CA_-_G3.pem && update-ca-trust On NixOS, add to your configuration: security.pki.caCertificateBlacklist = [ "Comodo AAA Services root" "emSign ECC Root CA - G3" ]; Are there workarounds for NetBSD? On NetBSD 10 and later, run as root: certctl untrust /usr/share/certs/mozilla/all/emSign_ECC_Root_CA_-_G3.pem && certctl untrust /usr/share/certs/mozilla/all/Comodo_AAA_Services_root.pem Are there workarounds for FreeBSD? On FreeBSD 14 or later, run the following commands as root: cp /etc/ssl/certs/14bc7599.0 /usr/share/certs/untrusted/14bc7599.pem cp /etc/ssl/certs/ee64a828.0 /usr/share/certs/untrusted/ee64a828.pem certctl rehash Site published by Dennis Jackson. The source is on GitHub and PRs are welcome.