In the last post we saw how eight eMudhra intermediate keys were guessable in seconds, and how Mozilla and Chrome moved to distrust the emSign ECC Root CA - G3. A natural question after that is, “Am I affected?”. Before we dive deep, let’s understand there are two different places to look, and each answers a different question.

Topics we will be covering in this post

• Trust store vs CT logs, what is the difference?
• Where does your machine trust eMudhra?
• How to check your trust stores (macOS, Python, Java, Linux)
• How to check if a website uses an eMudhra certificate
• How to search CT logs
• What to do with the results

Trust store vs CT logs, what is the difference?

Trust store is the list of CA roots your device accepts. If a root is in there, any certificate chaining to it will be accepted by your browser or app. This answers “who can my machine be tricked by?”.

CT (Certificate Transparency) logs are public records of certificates that CAs have issued. This answers “what certificates exist for my domains?”.

Same like a bank. Trust store is the list of signatures the bank accepts. CT logs are the register of every cheque that was ever issued.

You need both. One tells you your exposure, the other tells you if someone issued something they shouldn’t have.

Where does your machine trust eMudhra?

I ran these checks on my own Mac before writing this post, and I was surprised.

• The macOS system roots still include emSign ECC Root CA - G3, the exact root that Mozilla announced distrust for. Browsers like Firefox and Chrome move fast, but OS trust stores take time.
• My Python certifi bundle has three eMudhra roots (G1, C1 and C3), but not the ECC G3 root.
• My JDK cacerts has emsignrootcag1 and emsignrootcag2, not G3.

So the same laptop has three different answers, depending on which trust store the app uses. That is why you can’t just check one place.

Important point: the compromised keys were the eight intermediates under the G3 hierarchy. Other eMudhra roots in your stores were not reported as compromised. But eMudhra is leaving the global TLS business and there is already a request to remove eMudhra roots from in-tree bundles, so expect more removals.

How to check your trust stores

macOS

security find-certificate -a -c "emSign" /System/Library/Keychains/SystemRootCertificates.keychain | grep labl

On my machine this printed emSign ECC Root CA - G3 and emSign Root CA - G1.

Python (certifi)

python3 -c "import certifi;print(certifi.where())"
grep -n -i -E "emSign|eMudhra" $(python3 -c "import certifi;print(certifi.where())")

Don’t forget pip, virtualenvs and Docker images. Each one can carry its own certifi copy.

Java

keytool -list -cacerts -storepass changeit | grep -i -E "emsign|emudhra"

changeit is the default password for the JDK cacerts. If your company uses a custom truststore, point -keystore to it instead.

Linux

grep -r -l -i "emsign" /etc/ssl/certs 2>/dev/null
ls /etc/ssl/certs | grep -i emsign

I did not run the Linux commands on a Linux box, so check them on your distro (paths are different on RHEL based systems, it is /etc/pki/ca-trust).

Containers and CI

Scan base images and CI runners as well. They often have old CA bundles and nobody updates them.

How to check if a website uses an eMudhra certificate

openssl s_client -connect yoursite.com:443 -servername yoursite.com -showcerts </dev/null 2>/dev/null | openssl x509 -noout -issuer

Look at the issuer. If you see emSign, eMudhra or EM DV TLS CA, EM OV TLS CA, EM EV TLS CA, you are using eMudhra for that site. Check the whole chain with -showcerts since the leaf issuer may be an intermediate.

How to search CT logs

The easiest is crt.sh. To see all certificates for your domain, and filter for the issuer:

https://crt.sh/?q=%25.yourdomain.com&output=json

and then look at the issuer_name field for “eMudhra” or “emSign”. With jq:

curl -s "https://crt.sh/?q=%25.yourdomain.com&output=json" | jq -r '.[] | select(.issuer_name|test("emSign|eMudhra";"i")) | [.id,.name_value,.issuer_name,.not_after]|@tsv'

A heads up. crt.sh is a free service and it is flaky. When I tested, I got 502 Bad Gateway more than once and had to retry. If you are running this in a script, add retries and don’t treat an error as “no results”. I have only tested the simple domain query, and have not tested the issuer-only searches, so if those fail try Censys or your CT monitoring tool.

The thing to look for: any certificate for your domains from eMudhra intermediates that you did not request. Anyone with the guessed keys could have issued one, and CT is the place it would show up (all publicly trusted TLS certs must be logged).

What to do with the results

• Found eMudhra in a trust store you manage? Update the bundle first. Remove it if you don’t need it, and test before rolling out.
• Found a site on your side using an eMudhra TLS certificate? Move to another CA. eMudhra is exiting the TLS business, so this is needed anyway.
• Found an unexpected certificate in CT for your domain? Treat it as a security incident, report to the CA that issued it, and check the revocation status.
• Use eMudhra for document or code signing? That is a different service, so check with them and track the updates.

Final thoughts

The same laptop trusting eMudhra in one place and not another is the real lesson. Trust is spread across the OS, browsers, language runtimes and containers, and each updates on its own schedule. Inventory it before the next incident, not during.

I will update the post as the root removals land.