eMudhra CA Key Compromise

[Bob_Zimmerman]

Over the weekend, it was discovered eight signing certificates from eMudhra were compromised. These certificates are in the default trust anchors of just about everything which uses TLS. The private keys are now widely available (one of them is the number 4), and attackers are already using them to sign fake certs for all kinds of things.

Could an attacker use these CAs to impersonate updates.checkpoint.com, or do the firewalls do any kind of cert pinning for that domain?

$CPDIR/conf/ca-bundle.crt and probably a few other files will need to be updated to remove the compromised CAs. Would such an update be delivered via the autoupdater, or as a CPUSE package?

[Bob_Zimmerman]

More information, including a test to see if your client is updated yet, at emudhra.we-have-a-problem.com.

CVE-2026-111943

A repository with the eMudhra private keys and a tool showing how they were recovered.

[Bob_Zimmerman]

It looks like the local trust anchors in CPDIR don't include the compromised certs by default. This is on one of my management servers:

[Expert@DallasSC]# fw ver
This is Check Point's software version R82.10 - Build 017

[Expert@DallasSC]# cpinfo -y fw1 2>/dev/null | grep JUMBO
	HOTFIX_R82_10_JUMBO_HF_MAIN	Take:  45

[Expert@DallasSC]# ls -lh $CPDIR/conf/ca-bundle.crt
-rw-rw--w- 1 admin bin 52K Apr  7  2026 /opt/CPshrd-R82.10/conf/ca-bundle.crt

[Expert@DallasSC]# curl_cli --cacert $CPDIR/conf/ca-bundle.crt https://dv-g3b-emudhra.we-have-a-problem.com/
curl: (60) SSL certificate problem: unable to get local issuer certificate
More details here: https://curl.haxx.se/docs/sslcerts.html

curl failed to verify the legitimacy of the server and therefore could not
establish a secure connection to it. To learn more about this situation and
how to fix it, please visit the web page mentioned above.

[Expert@DallasSC]# curl_cli --cacert $CPDIR/conf/ca-bundle.crt https://dv-g3b-aaa-emudhra.we-have-a-problem.com/
curl: (901) servercert: Error - server certificate validation failed!

[Lesley]

I noticed that the root CA that signed the inter ca that are not anymore are revoked. I saw the in Smart Dashboard in the certificate CA overview list. We have to automatically updated. 

[Bob_Zimmerman]

They're revoked, yes, but a distressing number of clients don't actually check revocation status at all.

Others ship separate trust anchors which don't get updated with the OS. It's been days, and cURL on several of my fully-updated systems can still connect to sites with certs signed by these revoked CAs. Not great when the official installation process for so much software is 'curl ____ | bash'.

I don't know how the firewalls' update processes handle revoked certificate authorities. As far as I'm aware, we've never had a revocation this serious before. At least it looks like the trust anchors at the OS level have never included the revoked CAs.

[Daniel_Westlund]

Hello. My customer is asking, "Is there anything we need to do on the firewall in response to the eMudhra intermediary CA compromise? Can we insure we have purged those from our trusted CA stores?"

[Bob_Zimmerman]

If you're doing HTTPS Inspection on firewalls, make sure the authorities are disabled in Manage & Settings > Blades > General > Trusted Certificates. Searching for "eMudhra" should bring them all up. They're all disabled on my lab management, and I didn't take action to disable them. I think you also need to check Manage & Settings > Blades > HTTPS Inspection > Server Validations > "Untrusted server certificate" to get the validation failure to prevent clients from connecting.

It looks like the firewalls themselves already don't trust the eMudhra CAs for things like fetching updates. I don't know if there are any other trust anchor bundles on the system besides $CPDIR/conf/ca-bundle.crt. If there are, those bundles also need to be checked.

If you're using Harmony, Zscaler, or some similar client-side agent to filter web traffic from user machines, make sure the authorities are disabled there.

[ccsjnw]

I'm running R82.10. When I check my Trusted CA Package under HTTPs Inspection | Trusted Certificates

It says:

Up to Date
Version 4.0
Last updated: 02-Jan-2026
Last checked: 22-Oct-2026
Update Trusted CAs Package: Automatically

Has there really been no new Trusted CAs package issued since 02-Jan-2026 ?

If I search for eMudhra they all say Enabled:

I'm unclear how CheckPoint handles Intermediate Certificates. The above are all Root CAs.

I have not seen any guidance stating that any Root CAs are revoked or should be disabled. With regard to eMudhra, the guidance only says 8 Intermediate Certificates have been revoked.