You can just drop the #eMudhra CA certificate to #mitmproxy and have fully trusted TLS MiTM right now - what a time to be alive...
https://docs.mitmproxy.org/stable/concepts/certificates/#the-mitmproxy-certificate-authority

Infosec consultant at REVƎЯSEC https://reversec.com - Coding, Research + various other interests
Open remote profile ↗You can just drop the #eMudhra CA certificate to #mitmproxy and have fully trusted TLS MiTM right now - what a time to be alive...
https://docs.mitmproxy.org/stable/concepts/certificates/#the-mitmproxy-certificate-authority
I'm having hard time trying to think of something as bad as this flaw.
Debian ssh key predictable random number generator (CVE-2008-0166) or heartbleed (CVE-2014-0160) comes to mind.
The long term impact of this #eMudhra intermediate CA cert private key disclosure: It is now possible to perform TLS MiTM to millions and millions of older #IoT devices (or other devices that won't or can't get updated). The root certificate that has signed the affected intermediate certificate was added to trust stores in about beginning of 2019 (*). It expires only in 18-feb-2043.
This opens the avenue for all kinds of nasty things.
Another comment: Technically merely "emSign_ECC_Root_CA_-_G3.crt" out of the eMudhra roots would need to be removed to mitigate the currently known leaked private keys. However, considering the circumstances around the leak of the private keys are not known, I refuse to trust any eMudhra root at this time.
The compromised certificates are also signed by Comodo (Sectigo) "AAA Certificate Services" root. However the website trust for this CA was removed in 2025: https://bugzilla.mozilla.org/show_bug.cgi?id=1957685
That being said, disabling Comodo_AAA_Services_root.crt might be prudent in some situations. Note however that doing so might lead to various other intermediate certificates being untrusted, too.
Mitigating CVE-2026-111943 on #Debian:
- sudo dpkg-reconfigure ca-certificates
- Select "ask" and deselect the following entries:
mozilla/emSign_ECC_Root_CA_-_C3.crt
mozilla/emSign_ECC_Root_CA_-_G3.crt
mozilla/emSign_Root_CA_-_C1.crt
mozilla/emSign_Root_CA_-_G1.crt
- Hit <Ok>
Alternatively you can edit /etc/ca-certificates.conf manually and add the specific entries:
!mozilla/emSign_ECC_Root_CA_-_C3.crt
!mozilla/emSign_ECC_Root_CA_-_G3.crt
!mozilla/emSign_Root_CA_-_C1.crt
!mozilla/emSign_Root_CA_-_G1.crt
...and sudo update-ca-certificates
While no official word is out yet, it is not difficult to speculate that the private keys have likely been leaked.
The curious part is that various downstream projects need to take this action rather than the issue being solved upstream.
New Go security releases added explicit distrust for some specific intermediate CA certificates belonging to eMudhra Technologies Limited. Interestingly, this is tracked as CVE-2026-111943 but no details on why this was done are provided.
https://github.com/golang/go/commit/7f86f957633ee31a1c17a1eb8452ca7a3d9bc141