The private keys for eight eMudhra intermediate CA certificates are compromised. The reporter, who signs as Wayne, proved it by signing the message We have a problem here - Wayne with the private key of each intermediate and sending the signatures to the root program teams on 17 October. The published proof.zip contains the message plus, for each intermediate, the certificate, its public key, and a signature you can verify yourself. Pull the public key out of the certificate, diff it against the published key, then check the SHA-384 signature over the message:
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
Those eight intermediates chain to roots in the Mozilla, Microsoft, Apple and Chrome root programs, and to many downstream trust stores that inherit from them. Anyone holding one of the compromised private keys can issue a technically valid certificate for any domain and impersonate any website or service.
The browser response was quick. The certificates have been blocked in Firefox and Chrome since 17 October and on Apple devices since 19 October. Those three distribute revocation out of band through their own channels (OneCRL, CRLite and CRLSets), so most browser users are covered without touching anything. eMudhra has revoked the intermediates as well. The issue was disclosed to downstream trust stores on 19 October, and many have shipped updates or are working on them.
Checking your own clients
The problem is every TLS client that validates the chain but ignores revocation. Those keep trusting the compromised intermediates until a software or trust-store update removes them. The site gives you a live check against test hosts that serve certificates under the compromised intermediates:
curl https://dv-g3b-emudhra.we-have-a-problem.com/
curl https://dv-g3b-aaa-emudhra.we-have-a-problem.com/
A certificate error is the result you want. It means the client refuses the compromised intermediates. If you would rather check offline, chains.zip has the PEM chain each test host serves along with OpenSSL verification instructions.
The macOS and Linux gaps
macOS blocks the intermediates at the system level, but the bundled /usr/bin/curl verifies against /etc/ssl/cert.pem, which does not check revocation and has not been updated. A curl call from the terminal can still accept a forged certificate even where Safari rejects it. The fix is to strip the two affected roots (AAA Certificate Services and emSign ECC Root CA - G3) out of that bundle; the site publishes an awk one-liner that backs up cert.pem first and does it.
On Linux, until your distribution ships an updated ca-certificates package, you can distrust the same two roots in the system trust store by hand. The site has copy-paste commands for Debian and Ubuntu, Alpine, the Fedora/RHEL/Rocky/Alma/Amazon Linux family, openSUSE and SLES, Arch, NixOS and NetBSD 10+. This is for operators who know what they are doing; the source flags it as not recommended for ordinary users, who should update their browser and OS and leave it there.
For working out your own exposure, impacted-intermediates.json lists the eight intermediates and their Sectigo cross-signs, and roots.json lists the roots they chain to. The disclosure is being tracked in Mozilla's dev-security-policy forum, and the site, published by Dennis Jackson, has its source and a PR queue at github.com/galadran/we-have-a-problem.com.
