eMudhra certificate compromise
A certificate-chain compromise changes which remote identities a client can trust. The useful inventory is the set of trust stores and TLS clients that can still accept the affected intermediates.
Check OS and browser trust stores, internal TLS clients, mTLS paths, and container trust bundles. Verify vendor guidance for each product rather than assuming one trust-store update covers every workload.
What happened
Cloudflare reported a compromise affecting eight eMudhra intermediate certificates. An attacker who can produce a certificate under a trusted affected chain may impersonate an endpoint to clients that continue to accept that chain. Certificate forgery is distinct from proof of successful interception.
This incident is tracked through certificate and product advisories, not through a single CVE or package. Updates may arrive in operating-system trust stores, browser stores, language runtimes, managed gateways, and product-specific bundles on different schedules.
Updating the host CA bundle may leave Java, browser, embedded, or application-managed stores unchanged. Disconnected environments and containers need separate review because they can retain old trust data in immutable images or offline package snapshots.
Where to look
- Clients that validate outbound HTTPS, VPN, mTLS, or service-to-service connections using an affected trust chain.
- Container images and appliance firmware with independent CA bundles.
- Java applications, browser profiles, language runtimes, and TLS inspection products with their own trust configuration.
Initial investigation
- Inventory trust stores and runtimes, then identify the actual certificate chains accepted on each critical TLS path.
- Compare affected intermediates and vendor product action tables with system trust packages and application-specific roots.
- Identify air-gapped base images, private registries, and application containers that were built before trust updates.
- Prioritize authentication, certificate inspection, update services, and critical external API connections.
Operator commands
READ-ONLY EXAMPLESUse these commands to collect evidence. Confirm the running service and vendor security fix before assigning patch status.
rpm -q ca-certificates p11-kit-trust
trust list --filter=ca-anchors
find /etc/pki/ca-trust/source -maxdepth 3 -type f -printopenssl s_client -connect host.example:443 -servername host.example -showcerts </dev/nullRemediation plan
- Use the official affected-certificate list and the vendor-specific action table to choose trust-store and client updates.
- Rebuild affected container images and update application-managed trust stores where required; verify certificate validation inside running containers.
- Test representative mTLS, TLS inspection, and origin paths after updates. Preserve evidence of accepted and rejected chains.
Evidence to retain
- Trust-store source, package version, and software inventory for each client.
- Whether an affected chain is accepted, rejected, or still untested.
- Updated container digest or runtime identity after remediation.
- TLS path test results with endpoint, time, and client used.
References
EXTERNAL SOURCESRead the analysis on Ops Den. Open a reference only when you need the current vendor release or primary evidence.
Track your environment
Saved only in this browser. Ops Den does not receive or store your selections.