When a certificate authority's cryptographic keys weaken to just 3-8 bits of effective entropy, the Mean Time to Respond shrinks to hours. The eMudhra incident disclosed on October 17, 2026 (CVE-2026-111943 and CVE-2026-111944) exposed eight intermediate CA certificates whose private keys became easily recoverable. This playbook provides the queries, validation steps, and configuration guidance to inventory your exposure and address it before the next scan cycle.
Purpose of This Playbook
This playbook is a tactical response guide for identifying certificates issued by compromised certificate authorities in your environment. You'll use it to:
- Query your certificate inventory for affected issuers and specific compromised intermediates
- Identify hosts and applications that still trust revoked certificate chains
- Validate that your certificate revocation checks are functioning
- Build repeatable dashboards that automatically flag new exposures
The queries assume you're using a certificate visibility platform (examples reference Qualys Certificate View and VMDR, but the logic applies to any tool that indexes certificate chains and software inventory). If you lack certificate inventory tools, this playbook outlines the data you need to start collecting.
Prerequisites
Before running these queries, ensure:
- Certificate visibility is enabled across all scan ranges. Verify that IP ranges covering your TLS services are in scope. For externally hosted services, add the FQDNs or IP addresses to your certificate monitoring tool's external domain list.
- Agent coverage for unscanned endpoints. Certificate data from laptops, remote workers, and cloud workloads often requires agent-based collection. Deploy agents to any host that network scans can't reach.
- Signature updates are current. Vulnerability scanners rely on detection signatures to identify affected software. Confirm your agents and scanners have the latest signatures before starting.
- You have the list of compromised intermediates. The eMudhra incident involved eight specific intermediate CA certificates. You need their SHA-256 fingerprints, serial numbers, and issuer names. The table in the source article provides these identifiers.
The Queries
Query 1: Find Certificates Issued by Compromised Intermediates (by Issuer Name)
This query matches any certificate whose issuer is one of the eight compromised eMudhra intermediates:
certificate:(issuer.name:[`EM EV TLS CA, G3B`, `EM OV TLS CA, G3B`, `EM DV TLS CA, G3B`, `EM EV TLS CA, G3C`, `EM OV TLS CA, G3C`, `EM DV TLS CA, G3C`, `EM OV CS CA, G3B`, `EM OV CS CA, G3C`])
What it returns: A list of leaf certificates whose issuer matches one of the compromised intermediates. Each result shows the certificate subject, expiry date, and the assets and ports where it was found.
Why this matters: Any certificate issued by a compromised intermediate can be impersonated by an attacker with the recovered private key. These certificates must be reissued by a different trusted CA and redeployed immediately.
Query 2: Find Certificates by Serial Number (Exact Match)
Serial numbers uniquely identify certificates. This query matches the eight specific compromised intermediates by their serial numbers:
certificate:(serialNumber:`c7c41efe92d825f05eae841a4a82c1` or serialNumber:`6cada367fb1c100088120ea202d568` or serialNumber:`a4aee678f23362b4c0e460b772f214` or serialNumber:`8009928a64107601af05fa2f19f109` or serialNumber:`296926c227a3a1526392b19482a504` or serialNumber:`588b2e3c2bb8cda13e1a1209254321` or serialNumber:`7818933f8f85b4619a2b35fba83d0a` or serialNumber:`544b7f922c31ae220a4a922916f6e6`)
What it returns: Any certificate chain containing one of the eight compromised intermediates. This catches both leaf certificates issued by the intermediates and the intermediates themselves if they appear in a chain.
Why this matters: Serial number matching is more precise than issuer name matching, eliminating false positives from similarly named CAs.
Query 3: Find Software That Still Trusts the Compromised Certificates
Browsers and operating systems have blocked the compromised certificates, but applications using older Go runtimes may still trust them. This query identifies hosts running Go versions that do not reject the compromised intermediates:
vulnerabilities.vulnerability.qid:5019897
What it returns: A list of hosts running Go versions prior to 1.27.3 or 1.26.10, which do not block certificate chains containing the eight compromised keys.
Why this matters: Your servers may have replaced their certificates, but if your applications or internal tools use Go-based HTTP clients with outdated runtimes, they remain vulnerable to man-in-the-middle attacks using fraudulent certificates issued by the compromised intermediates.
Query 4: Enumerate All eMudhra-Issued Certificates (Broad Sweep)
This query finds any certificate issued by the two eMudhra organizations named on the compromised intermediates:
certificate:(issuer.organization:`eMudhra BV` or issuer.organization:`eMudhra Inc`)
What it returns: Every certificate in your environment issued by eMudhra BV or eMudhra Inc, including both affected and unaffected certificates.
Why this matters: This is a broader sweep than the issuer name query. Use it to identify your total exposure to eMudhra's trust hierarchy and to flag certificates that may need replacement even if they weren't issued by the eight specific compromised intermediates.
How to Customize These Queries
- Adapt the syntax to your tool. The queries above use Qualys Query Language (QQL). If you're using a different certificate inventory platform, translate the logic: search for certificates where the issuer name or serial number matches the compromised values.
- Add your own filters. Append filters for specific business units, environments, or expiry windows. For example, prioritize certificates expiring in the next 90 days or those used on internet-facing hosts.
- Save as dashboard widgets. Most certificate visibility tools let you save queries as dashboard widgets or scheduled reports. Save these queries so any new certificate issued by eMudhra entities gets flagged automatically in future scans.
- Adjust for your CA inventory. If you discover certificates from other CAs in your environment, build parallel queries for those issuers. The same logic applies: match on issuer name, serial number, or organization.
Validation Steps
Run the queries and export the results. Start with the serial number query (Query 2) for precision. Export the list of affected certificates and the hosts where they were found.
Cross-reference with your asset inventory. For each affected host, determine its business criticality, environment, and owner. Tag high-priority assets for immediate remediation.
Verify certificate chains. For each certificate flagged by the queries, inspect the full chain. Confirm that one of the eight compromised intermediates appears in the chain. The SHA-256 fingerprint is the most reliable identifier.
Check revocation behavior. eMudhra revoked the eight compromised certificates, but clients that don't check certificate revocation can still accept them. Test a sample of your TLS clients to confirm they're checking revocation and rejecting the compromised chains.
Validate software updates. For hosts flagged by the Go runtime query (Query 3), confirm that vendor patches or runtime upgrades are available and schedule deployment. Re-scan after patching to verify the vulnerability is closed.
Monitor continuously. Re-run the queries after each scan cycle until the results are clean. Set up alerts so that any new certificate issued by eMudhra entities triggers a notification.
Document your response timeline. Record when you discovered the exposure, replaced certificates, and validated that all affected hosts are clean. This timeline becomes evidence for audit and compliance reporting.
The eMudhra incident highlights that digital trust relies on operational controls, not just cryptographic algorithms. You trust certificate authorities to generate strong keys, protect private keys, and revoke compromised certificates promptly. When those controls fail, your response speed determines your exposure window. The queries in this playbook give you the data to close that window before the next scan cycle.
