eMudhra CA Compromise: Find and Fix Your Exposure with Tanium

What happened

On October 17, 2026, a researcher reported that eight intermediate certificate authorities (CAs) run by eMudhra have private keys that anyone can calculate from the public certificates. Six of the CAs are for TLS (website) certificates and two are for code signing. Sectigo cross-signed the same eight keys, so 16 certificates are affected in total

With these keys, anyone can issue a certificate for any website, or sign software, and it chains to root CAs that many systems trust. eMudhra revoked its eight certificates on October 18 and Sectigo revoked its eight the next day, but revocation protects only software that checks it, and many non-browser programs do not check revocation.

The primary record is Mozilla's incident bug, Bugzilla 2083449 (opens in a new tab).

What is vulnerable

Browsers are protected once their own block list is current: restart browsers, and don't block browser update traffic. Most other software is protected only after its own trust store is updated.

Protected once block lists are current

• Chrome and Android: Google blocked the intermediates in Chrome through a CRLSet update on October 17 and on Android through Google Play services on October 19. Google has removed emSign ECC Root CA - G3 from the Chrome Root Store (version 43); the change is already on Canary and Beta and is expected to reach Chrome Stable on Tuesday, October 27. (Google (opens in a new tab))
• Firefox: blocked through OneCRL on October 17. Firefox 158.0.1, ESR 153.5.1 and ESR 115.43.1 carry the block for installs where Remote Settings is disabled by policy or unavailable. Firefox for Android needs 158.0.2, which fixes profiles that did not apply the block (Bugzilla 2083449, comment 29). Mozilla has also removed emSign ECC Root CA - G3 from its root store (NSS 3.131.1). (MFSA 2026-111 (opens in a new tab), MFSA 2026-112 (opens in a new tab), MFSA 2026-113 (opens in a new tab))
• Edge: since Edge 112 (from Edge 109 to 111 on unmanaged devices, by staged rollout), Edge on Windows and macOS uses its own certificate verifier and the Microsoft root list shipped with the browser rather than the operating system's (Microsoft (opens in a new tab)). Microsoft doesn't say whether that verifier honors the Windows disallowed list. Edge ships its own revocation component (listed on edge://components), so update it with the steps below rather than relying on the Windows list.
• Safari and other Apple platforms: Apple has reportedly blocked the intermediates through its own revocation system since October 22. We found no Apple advisory, and the macOS command-line tools are not covered (next section).
• Windows: Microsoft blocks the intermediates through its disallowed certificate list. We found no Microsoft advisory, but Microsoft's own disallowed list, dated October 19, lists all eight compromised keys, which covers all 16 certificates. The block reaches only devices that download the list (next section).

Update each browser's revocation list. Open chrome://components (edge://components in Edge), find the CRLSet component (Chromium's name for it; we have not confirmed Edge's label), click Check for update, and restart the browser. In an internal Tanium lab, these versions showed as protected: Chrome with CRLSet 10856, Edge with CRLSet 6498.2026.10.20, and Firefox at the versions listed above.

Exposed until updated

Searching for the 16 certificates is not enough. Servers send intermediates during the TLS handshake, so they are rarely stored on endpoints. An empty search for their fingerprints does not mean a device is safe. Check whether the device trusts the roots above them, and whether its software is at a fixed version.

Roots to look for

emSign Root TLS CA - G3 and emSign Root CS CA - G3 issued the intermediates directly. Both are themselves cross-signed by emSign ECC Root CA - G3, which is how the TLS intermediates reach systems that trust only ECC G3, such as /etc/ssl/cert.pem on the Mac above. Mozilla and Chrome have not removed trust in emSign Root CA - G1, and eMudhra is moving its subscribers to it; the incident bug still has open questions about a G1 CRL signed with the wrong key (Bugzilla 2083449, comments 7 and 34).

Removing emSign ECC Root CA - G3 also breaks legitimate certificates: about 30,800 unexpired certificates (counted from Certificate Transparency precertificates) chained to it on October 21, 99.9% of them issued by Internet2's InCommon intermediates (Bugzilla 2083449, comment 30). Prefer the vendor's package update to removing roots by hand.

Why AAA Certificate Services and emSign ECC Root CA - G3 show up, and why we don't recommend removing them

Why they show up. These two roots sit above the compromised intermediates, so any search for exposure finds them. Both are long-standing roots. Microsoft and Apple still trust AAA Certificate Services, and emSign ECC Root CA - G3 is in Microsoft's and Apple's root stores (both roots appear in Microsoft's trusted root list and in the macOS 26.7.1 system root keychain, checked October 23) and, until the current removals, Mozilla's and Chrome's. You will find them in Windows certificate stores, in Linux CA bundles that have not been updated, in Java cacerts files, and in /etc/ssl/cert.pem on macOS. Certificate Manager and the eMudhra Root CA Report list them in Windows certificate stores, Linux certificate files and Java keystores in JKS or JCEKS format, so a match can look like a sign of compromise. Every default cacerts from JDK 18 on is a PKCS #12 file, which Certificate Manager does not inspect, so standalone JDK 18 and later runtimes do not match (tested with a Temurin 21.0.13 runtime). On macOS, Certificate Manager reads only Java keystores under /Library/Java/JavaVirtualMachines, not the keychain or /etc/ssl/cert.pem, so a Mac appears in these results only through a JKS-format JDK keystore there (JDK 17 or older).

Why a match is not a problem on its own. Neither root's private key is reported compromised. The weak keys belong to the 16 intermediates (Bugzilla 2083449 (opens in a new tab)). eMudhra's own statement refers to eight intermediates and does not name them or the Sectigo cross-signs. The fixes target the intermediates or come from the vendor: browsers, Microsoft and Apple block the intermediates, and the Linux ca-certificates updates remove emSign ECC Root CA - G3 and, on Red Hat, CentOS Stream, Oracle Linux 8 to 10 (the October 23 updates), Debian and Ubuntu 14.04 to 20.04, AAA Certificate Services as well. Oracle Linux 7 blocklists both roots instead. On Windows, both AAA Certificate Services and emSign ECC Root CA - G3 stay trusted, and the disallowed certificate list does the blocking. The same holds for emSign Root TLS CA - G3 and emSign Root CS CA - G3, which are also in Microsoft's trusted root list.

Why we don't recommend removing them by hand.

• Both roots anchor legitimate certificates. About 30,800 unexpired certificates (counted from Certificate Transparency precertificates) chained to emSign ECC Root CA - G3 on October 21, 99.9% of them issued by Internet2's InCommon intermediates (Bugzilla 2083449, comment 30). AAA Certificate Services anchors other Sectigo certificates. Removing either can break connections to sites and services that have nothing to do with eMudhra. The vendor updates that remove these roots break the same certificates; the reason to take the vendor update instead is that the vendor tests the change and maintains the trust store.
• Dependencies are hard to predict. You can't easily tell in advance which applications rely on these roots, and the failures appear as TLS errors in whatever uses those chains.
• The vendor updates already make the change. They do it in a tested way, and installing them gives the same protection without a hand-maintained trust store.

This advice is about editing trust stores by hand. Mozilla, Chrome and several Linux distributions are removing emSign ECC Root CA - G3, and the recommended way to take that removal is through the vendor's update. Install the updates in the tables below, and on Windows make sure the disallowed list is current.

If you decide to act anyway. Some systems can't wait for a vendor fix: those with no update yet (CentOS Stream 10, Solaris, AIX), the macOS command-line tools, and Windows networks that can't reach Windows Update. If you remove trust yourself:

1. Make the narrowest change. On Windows, block the 16 intermediates instead of removing a root. Import them into the Disallowed store (shown as Untrusted Certificates in the Certificates console) with certutil -addstore Disallowed <file> (Microsoft (opens in a new tab)), or, on networks that can't reach Windows Update, host the CTL files internally and point RootDirUrl at them (Microsoft (opens in a new tab)). On other platforms, distrust emSign ECC Root CA - G3 first, and remove AAA Certificate Services only after checking what chains to Sectigo certificates (the RHEL, CentOS Stream, Debian and Ubuntu 14.04 to 20.04 updates remove it too).
2. Check what depends on the root first. In Certificate Manager, search the Certificate Inventory for certificates issued by InCommon and Sectigo, and confirm whether any services you rely on chain to the root you plan to remove.
3. Use the platform's own distrust mechanism, not file deletion.
   • RHEL family: Red Hat's KB 7149312, linked from RHSB-2026-012 (opens in a new tab), covers blocklisting the Comodo AAA Services and AAA Certificate Services roots. Check that it also covers emSign ECC Root CA - G3, and if it does not, blocklist that root with the same tool. For OpenShift, the matching article is KB 7149347.
   • Debian and Ubuntu: in /etc/ca-certificates.conf, prefix the certificate's line with !, which deselects it, and run update-ca-certificates (Ubuntu (opens in a new tab)). Then rebuild Java's cacerts as described under "Update Linux trust stores with Patch" in Step 2.
   • Java: OpenJDK's own guidance is to delete the aliases emsigneccrootcag3 [jdk] and comodoaaaca [jdk] (the suffix is part of the alias) from standalone runtimes' cacerts, even after updating, for example keytool -delete -cacerts -alias "emsigneccrootcag3 [jdk]" on JDK 11 and later (OpenJDK (opens in a new tab)). This is the one exception to step 1, because it removes AAA Certificate Services too. The steps are under "Update runtimes and applications with Deploy" in Step 2.
   • macOS command-line tools: point them at an updated CA bundle, such as Homebrew's ca-certificates, instead of editing /etc/ssl/cert.pem.
4. Roll out in stages with Tanium. Build the change as a Tanium package and deploy it to a small test group first. Check your critical internal and partner endpoints, then widen the rollout. Keep a package that reverses the change. Afterwards, deploy the scan packages named in Step 3, then re-run the eMudhra Root CA Report to confirm the root no longer appears in a trusted location.
5. Return to the vendor's trust store when you can. Once the vendor update is available, install it and remove any manual override you no longer need.

The 16 compromised intermediate certificates (SHA-256)

Issued by eMudhra (revoked October 18, 2026):

Cross-signed by Sectigo under AAA Certificate Services (revoked October 19, 2026):

Source: Bugzilla 2083449, the bug description and comment 2.

SHA-1 and MD5 fingerprints for the roots and the 16 intermediates

How these were verified: each certificate was downloaded from crt.sh (opens in a new tab) and matched its SHA-256 in Bugzilla 2083449 before hashing, the 16 intermediate SHA-1s also match a Windows lab export, the SHA-1s of emSign ECC Root CA - G3 and AAA Certificate Services match the macOS root bundle, the other self-signed root SHA-1s match Microsoft's trusted root list, and the two cross-signed rows come from crt.sh (opens in a new tab).

Roots:

Intermediates. The public key MD5 is the MD5 of the raw EC public key point (the 97-byte value inside the SubjectPublicKeyInfo, 0x04 prefix included), so it is the same for each eMudhra certificate and its Sectigo cross-sign, because they share a key. Microsoft's disallowed certificate list identifies the compromised keys by these same values, so they are what certutil -verifyCTL Disallowed matches on. The MD5 of the whole SubjectPublicKeyInfo, which openssl pkey -pubin -outform DER | openssl md5 produces, is a different value.

Fixed versions as of October 23, 2026

Operating system trust stores:

Software with its own trust store:

How to use Tanium to find and fix it

Step 1: Ask Tanium Atlas

Paste this prompt into a new Atlas page. It carries the fingerprints and fixed versions, so Atlas does not have to look them up. When Atlas proposes an action, such as deploying a package, it shows you the details and waits for your approval before the action runs (Read more in the Tanium Resource Center (opens in a new tab)).

Find which of my endpoints are exposed to the eMudhra intermediate CA key compromise (October 2026), then help me fix them. Use the reference data below rather than searching the internet.

1. On Windows endpoints, report whether automatic updates of the disallowed certificate list are turned off: registry value EnableDisallowedCertAutoUpdate under HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\SystemCertificates\AuthRoot (0 means off; DisableRootAutoUpdate in the same key controls the trusted root list, not the disallowed list), and RootDirUrl under HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\SystemCertificates\AuthRoot\AutoUpdate (a value means an internal mirror). A recent sync time alone does not show the device is protected. Where you can, check whether the device's cached disallowed list contains the compromised intermediates with certutil -verifyCTL Disallowed <CertDir> <CertFile>, which needs the intermediate certificate files on the endpoint.
2. Using Certificate Manager data (Certificate Details), list where a certificate with one of the SHA-256 thumbprints below is stored, by endpoint and Location. Certificate Details reports thumbprints in lowercase, so compare without regard to case. Use the Location to decide what a match means: a root in the Windows Root or AuthRoot store, or in a Linux TLS trust file (/etc/ssl/certs/ca-certificates.crt on Debian and Ubuntu, /etc/pki/ca-trust/extracted/pem/tls-ca-bundle.pem on RHEL-family systems, or a Java cacerts), is trusted for TLS; the same certificate in the email or code signing bundles, ca-bundle.trust.crt (which also carries distrusted entries), the Windows Disallowed store, a blocklist directory or /usr/share/ca-certificates is not necessarily trusted. On Windows, a match for any of the four roots alone is not exposure, because all four are in Microsoft's trusted root list and Microsoft blocks the compromised intermediates through its disallowed list. No match does not mean the device is safe: on macOS Certificate Manager reads only Java keystores; it does not inspect PKCS #12 keystores, the format of every default Java cacerts from JDK 18 on, so report standalone JDK 18 and later runtimes by version; and Certificate Details leaves out certificates on the exclusion list.
3. On Linux endpoints, report the installed ca-certificates package version (ca-certificates-mozilla on SUSE) and compare it with the fixed versions below. CentOS Stream 10 has no fixed build yet, and Solaris and AIX have no vendor guidance: report those endpoints as exposed if their trust store contains emSign ECC Root CA - G3. For distributions not listed below, such as Oracle Linux 7 and Ubuntu 14.04 to 20.04, report the version and flag the endpoint for review against the vendor's advisory.
4. Find installed Node.js, Python and Firefox versions and compare them with the fixed versions below. For Java, do not rely on the version: report a standalone runtime as exposed while its cacerts still contains the alias "emsigneccrootcag3 [jdk]" or "comodoaaaca [jdk]" (check with keytool -list -cacerts -alias "<alias>" on JDK 11 and later), unless revocation checking is enabled with -Dcom.sun.net.ssl.checkRevocation=true -Dcom.sun.security.enableCRLDP=true, and judge OS-packaged OpenJDK by the ca-certificates check in step 3. For Go, list the Go programs you find; an installed Go toolchain version does not show whether they were rebuilt.
5. Summarize the exposed endpoints by platform and reason. Then propose the updates (Patch for Linux packages, Deploy for software updates and for removing the two Java aliases) and wait for my approval before deploying anything.

Roots (SHA-256):
- emSign ECC Root CA - G3: 86A1ECBA089C4A8D3BBE2734C612BA341D813E043CF9E8A862CD5C57A36BBE6B
- AAA Certificate Services: D7A7A0FB5D7E2731D771E9484EBCDEF71D5F0C3E0A2948782BC83EE0EA699EF4
- emSign Root TLS CA - G3: 7DD78D5F4F13459A83DFF9ABBBA62EDBAF6F2D102BF257FD712F4D9F2746ED8D
- emSign Root TLS CA - G3, cross-signed by emSign ECC Root CA - G3: 3094025792039A68AF6E553686410BDAB7C0D4A36B9084CBA64202E35D6EBBDD
- emSign Root CS CA - G3: F2EDAAFF3D9B701FB4D14C9F285F8C0BAD90FC3BCC1FA07D47F4718EDABA34A5
- emSign Root CS CA - G3, cross-signed by emSign ECC Root CA - G3: 7137FA71AD46BA686F746D1014AC57E8E6C6E9AF4AA2F73C0C44A5CF27DEBB59

Compromised intermediates (SHA-256):
42C4ACCD12C4F59597925E1A08A7A90102608543809308D50EC427E118BA1493
0164D7CEAE5BB909C272AF151FF44B1177AE9B47D9424B94F1D9558C30934D19
E7568FE6E12331F4FD7DE61DA4C7559D0F8EB192A218D4741A3BA75184333838
432EC25F0D28DE9006D97BF752F17BBB2CD41F669933FCB072D9A1148D0261F3
98B896625C0C230ADEEC3EB2CF6AAD5001ECF9156A68644E82374CE5833BC25B
CB6E15165AC802E9B3F993F16C25D41F4E81C21EBDE71AE1B012AC00BF9C7C3F
9E39DE2881273ACC225A149C72BA3E0F51424963669AB633EE1DC7DF5DB067B4
4B2460A466F95FD40113BCDCCA2CEB29B3B093921DE45474DA7DF48874C630B1
45A883F349AEDFD5F3A649B5498FFB121712BA8B448F3F2A91DBC5A766FCDDBE
62B7F9868263F72F6911FC78CEAF72C1979158B7368BF648683BB2AA39B02E72
579480AEA166290BD3C643589E795FC0D0E54E86505D180F1DFF99EFD3199512
FD9D5C2DBBD4995AB69B8D50C439D9527B00529199C2FD01B2174EB58F07021F
5F1DED4DD590AF74631290CF073B122A2AAC6A1FA479778A0BD43579BD832699
7485B51C0ED192878FA1D2F948FB529AE1842CC5086C4B67F7BE5B2039DE9489
A496E23AC0CAB8155FC9B117B97EAE368EFCBB9041AEC8804D5A308D2D01C2D8
84112972B8E59D14560AE7E7119654474AAD119990CF3722BFC1E3B91615E1FD

Fixed versions:
- RHEL 10: ca-certificates-2026.2.92_v9.0.319-100.3.el10_2
- RHEL 9: ca-certificates-2026.2.92_v9.0.319-90.3.el9_8
- RHEL 8: ca-certificates-2026.2.92_v9.0.319-81.3.el8_10
- CentOS Stream 9: ca-certificates-2026.2.92_v9.0.319-91.3.el9
- Ubuntu 22.04 / 24.04 / 26.04 / 26.10: ca-certificates 20260816ubuntu0.22.04.1 / 20260816ubuntu0.24.04.1 / 20260816ubuntu0.26.04.1 / 20260816ubuntu0.26.10.1
- Debian 13: ca-certificates 20250419+deb13u1
- Debian 12: ca-certificates 20250419~deb12u2
- RHEL 7 ELS: ca-certificates-2026.2.92_v9.0.319-70.3.el7_9
- Oracle Linux 10: ca-certificates-2026.2.92_v9.0.319-100.3.el10_2 (ELSA-2026-88455)
- Oracle Linux 9: ca-certificates-2026.2.92_v9.0.319-90.3.el9_8 (ELSA-2026-88459)
- Oracle Linux 8: ca-certificates-2026.2.92_v9.0.319-81.3.el8_10 (ELSA-2026-88550)
- SUSE Linux Enterprise Server 15 SP7: ca-certificates-mozilla 2.92-150200.50.2 or later
- Java, current releases (not a fix on their own for standalone runtimes): 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, 8u511 b32. A standalone runtime is fixed only when both aliases are gone from its cacerts or revocation checking is enabled.
- Node.js: 26.12.1, 24.22.1, 22.23.4
- Go: 1.27.3, 1.26.10 (programs must be rebuilt)
- Python: 3.15.1, 3.14.9, 3.13.17; certifi 2026.10.19; pip 26.2.2
- Firefox: 158.0.1 (158.0.2 on Android), ESR 153.5.1, ESR 115.43.1

Step 2: Or run the checks yourself

See where the certificates are stored with Certificate Manager. The Certificate Manager audit reads the Windows certificate stores and certificate files in /etc/pki, /etc/ssl, /usr/share/ca-certificates and the JVM directories on Linux (Read more in the Tanium Resource Center (opens in a new tab)). It reads every certificate in a .crt, .cer or .pem file, including multi-certificate bundles such as /etc/ssl/certs/ca-certificates.crt. Ask the question below for a fingerprint. The Certificate Details sensor reports thumbprints in lowercase.

Get Computer Name and Certificate Details having Certificate Details:SHA256 Thumbprint contains 86a1ecba089c4a8d3bbe2734c612ba341d813e043cf9e8a862cd5c57a36bbe6b from all machines

To check every root and intermediate at once, import the two eMudhra reports below instead of repeating the question for each fingerprint.

Check the Location column to see what a match means. A root in the Windows Root or AuthRoot store, or in a Linux TLS trust file, is trusted for TLS. The TLS trust files are /etc/ssl/certs/ca-certificates.crt on Debian and Ubuntu, /etc/pki/ca-trust/extracted/pem/tls-ca-bundle.pem on RHEL-family systems, and the JDK's cacerts for Java. The same root also appears in files with other purposes, such as email-ca-bundle.pem and objsign-ca-bundle.pem in the same pem directory, and /etc/pki/ca-trust/extracted/openssl/ca-bundle.trust.crt, which also carries distrusted entries; a match there does not mean TLS trust. The same certificate in the Windows Disallowed store, in a blocklist directory, or in a source directory such as /usr/share/ca-certificates is not necessarily trusted, so on Linux treat the ca-certificates package version as the deciding check.

On Windows, a match for any of the four roots alone does not indicate exposure. All four are in Microsoft's trusted root list, so Certificate Manager can find them on a protected device. Microsoft's block applies to the compromised intermediates, through its disallowed list, so check that list instead (next step).

Four limits apply: on macOS Certificate Manager reads only Java keystores, not the keychain or /etc/ssl/cert.pem; it does not inspect Java KeyStores in PKCS #12 format, which is the format of every default cacerts from JDK 18 on, so a standalone JDK 18 or later does not match; it sees user certificate stores only for users signed in during the audit; and Certificate Details leaves out at-rest certificates on the exclusion list. No match does not mean a device is safe. To check standalone JDK 18 and later runtimes, find them by version, then check each one's cacerts with keytool, for example keytool -list -cacerts -alias "emsigneccrootcag3 [jdk]".

Check that Windows devices receive Microsoft's block. Ask:

Get Computer Name and Registry Value Data[HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\SystemCertificates\AuthRoot, EnableDisallowedCertAutoUpdate] from all machines with Is Windows equals true

A value of 0 means automatic updates of the disallowed list are off. Most devices return Key/Value not found, which means the policy value isn't set, so automatic updates are on, Microsoft's default. DisableRootAutoUpdate, in the same key, controls the trusted root list, not the disallowed list, so it doesn't decide whether Microsoft's block arrives. A RootDirUrl value under HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\SystemCertificates\AuthRoot\AutoUpdate means the device downloads its lists from an internal mirror (Microsoft (opens in a new tab)). To find those devices, ask:

Get Computer Name and Registry Value Data[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\SystemCertificates\AuthRoot\AutoUpdate, RootDirUrl] from all machines with Is Windows equals true

Devices that return a value use an internal mirror.

A recent sync only shows that the device fetched a list, not that the list contains the compromised intermediates, so check the contents. Microsoft documents certutil -verifyCTL Disallowed <CertDir> <CertFile>, which matches a certificate file against the device's cached disallowed list (Microsoft (opens in a new tab)). The list is keyed by public key, and each eMudhra certificate shares its key with its Sectigo cross-sign, so the eight eMudhra-issued certificate files are enough. Run them through a Tanium package (PEM or DER), with each one as the certificate file. A listed certificate prints Certificate match found and exits with code 0. An unlisted one prints Certificate match NOT found and exits with code 0x80094005 (CERTSRV_E_INVALID_CA_CERTIFICATE), which looks like an error but means the certificate is not on the list.

Update Linux trust stores with Patch. Tanium Patch scans Linux endpoints against the repositories you configure. Make sure those repositories carry the fixed ca-certificates build, then deploy it to the endpoints found above. On Debian and Ubuntu, updating ca-certificates and ca-certificates-java is not enough for Java. First note any CAs you added to the Java store yourself, because the rebuild starts from the system store and you will need to add them back (Ubuntu (opens in a new tab)). Then, as root, delete /etc/ssl/certs/java/cacerts and run update-ca-certificates --fresh (OpenJDK (opens in a new tab)).

Update runtimes and applications with Deploy. Use the Installed Applications sensor to find installed products and their versions, such as Java, Node.js, Python and Firefox, then update them with Tanium Deploy. The sensor does not show which framework an application is built on and does not list a runtime extracted from an archive: for Electron-based applications, check each vendor's advisory or use the SBOM add-in below, and search the endpoints by file for unpackaged runtimes. Atlas can draft the deployment for you (Read more in the Tanium Resource Center (opens in a new tab)). Where you have a Tanium SBOM license, the SBOM add-in for Asset also shows libraries bundled inside applications. For standalone Java runtimes, updating is not enough: OpenJDK says to act even on the current releases. Back up cacerts, delete the aliases emsigneccrootcag3 [jdk] and comodoaaaca [jdk] with keytool (ignore an error for an alias that is not present), and restart the Java processes, or enable revocation checking with -Dcom.sun.net.ssl.checkRevocation=true -Dcom.sun.security.enableCRLDP=true (OpenJDK (opens in a new tab)). Treat a standalone runtime as exposed until one of those is done. Because deleting the aliases removes AAA Certificate Services, first check which Java applications rely on Sectigo certificates.

Where no fix exists yet, follow the steps under "If you decide to act anyway" above. Target only the endpoints the checks above found, and test on a few endpoints first.

eMudhra Report

The “eMudhra_Intermediate_CA_Report.json” file contains a Certificate Manager report that searches for all 16 compromised intermediate CAs in the environment. These are the certificates with compromised keys. Any results found in this report warrant further investigations and remediation.

The “eMudhra_Root_CA_Report.json” file contains a Certificate Manager report that searches for the 6 root CAs that signed the compromised intermediate CAs. These roots are not compromised. Matches are expected even on up-to-date Windows devices, which still trust all four roots. Macs appear only through a JKS-format JDK keystore (JDK 17 or older) under /Library/Java/JavaVirtualMachines, because Certificate Manager reads only Java keystores on macOS. On Linux, emSign ECC Root CA - G3 in the TLS trust file (/etc/ssl/certs/ca-certificates.crt or tls-ca-bundle.pem) means the ca-certificates update is missing; on RHEL, CentOS Stream, Debian and Ubuntu 14.04 to 20.04 the same is true of AAA Certificate Services. Don't remove roots because of this report. The report is provided for completeness for customers.

Each report shows which endpoints contain the certificate and where it is stored on each endpoint. Read the Location column as described in Step 2. The report needs Certificate Manager installed with its certificate audit completed on each endpoint.

Step 3: Confirm

Certificate Manager picks up file changes only when its periodic background scan runs (about 20 hours apart in an internal lab), and runs the Windows store and listening-port scan on its own schedule, so results right after an update can still show the old roots. Deploy the Index - Force Start Scans package (file-based certificates) and the Certificate Manager Force Listening Service Audit package (Windows stores and listening services) first. Then ask the same questions again and re-run the two eMudhra reports, and save the questions so you can re-run them as more vendors ship fixes. Don't rely on the built-in Certificate Manager - Root Certificate Details report for this check: it keeps only Windows store rows in Root or trusted locations and files under /etc/pki or /etc/ssl whose path contains "trust", so it does not show Debian and Ubuntu bundles such as /etc/ssl/certs/ca-certificates.crt, most Java cacerts files, or Macs.

Sources

• Mozilla Bugzilla 2083449 (opens in a new tab), the incident record, with the certificate list and fingerprints
• Google: protecting Chrome and Android users (opens in a new tab)
• Red Hat RHSB-2026-012 (opens in a new tab)
• Ubuntu USN-8944-1 (opens in a new tab) and USN-8944-2 (opens in a new tab)
• OpenJDK guidance (opens in a new tab)
• Microsoft: configure trusted roots and disallowed certificates (opens in a new tab)
• Debian LTS DLA-4845-1 (opens in a new tab) for Debian 12
• Chrome Root Store, root_store.textproto version 43 (opens in a new tab)