Security: Distrusted eMudhra root (emSign ECC Root CA - G3) still present in NethSecurity 8.8.0 ca-bundle (CVE-2026-111943)

Hi,

The /etc/ssl/certs/ca-certificates.crt (ca-bundle) package in NethSecurity 8.8.0 still includes the distrusted emSign ECC Root CA - G3 certificate (SHA-256: 86A1ECBA089C4A8D3BBE2734C612BA341D813E043CF9E8A862CD5C57A36BBE6B), as well as the cross-signing AAA Certificate Services root.

Following the October 2026 compromise of 8 eMudhra subordinate CAs (CVE-2026-111943, weak keys factored), major browsers and Linux distributions have removed emSign ECC Root CA - G3 and blocked the compromised intermediates. Since OpenWrt/NethSecurity CLI tools (curl, uclient-fetch, wget, openssl) validate against ca-certificates.crt without CRL/OCSP checks, outbound HTTPS connections initiated by the firewall (Threat Shield blocklists, IPS signatures, DoH/DoT, controller communication) remain vulnerable to MitM spoofing via both the direct eMudhra chain and the AAA Certificate Services cross-signed path.

Verification on an up-to-date NethSecurity 8.8.0 instance:

root@nethsec:~# openssl crl2pkcs7 -nocrl -certfile /etc/ssl/certs/ca-certificates.crt | openssl pkcs7 -print_certs -noout | grep -i "emSign ECC Root CA - G3"
subject=C=IN, OU=emSign PKI, O=eMudhra Technologies Limited, CN=emSign ECC Root CA - G3
issuer=C=IN, OU=emSign PKI, O=eMudhra Technologies Limited, CN=emSign ECC Root CA - G3
subject=C=IN, OU=emSign PKI, O=eMudhra Technologies Limited, CN=emSign ECC Root CA - G3
issuer=C=IN, OU=emSign PKI, O=eMudhra Technologies Limited, CN=emSign ECC Root CA - G3

Could you please provide an updated ca-bundle / ca-certificates package for NethSecurity 8.8.0 that removes emSign ECC Root CA - G3 (and addresses the AAA Certificate Services cross-signed path)?

Thanks!

Hello Antonin, thanks.

The eMudhra incident is real (Debian bug #1151413; Mozilla blocked the affected intermediates via OneCRL). NethSecurity 8.8.0 still trusts “emSign ECC Root CA - G3”. A new release planned before December will ship a CA bundle without it and rebuild our Go components with a fixed Go.

As far as I understand, “AAA Certificate Services” is already not trusted in 8.8.0. It is in the source data but not trusted for TLS, so it isn’t in ca-certificates.crt. If I read it correctly, CVE-2026-111943 is Go’s crypto/x509 fix for the same intermediates (fixed in Go 1.26.10), not a CA-bundle CVE.