Canonical has issued critical package updates across all supported Ubuntu releases to revoke trust in root certificates associated with the compromised eMudhra Certificate Authority. Because attackers with access to eMudhra's leaked private keys could generate fraudulent TLS certificates to intercept encrypted traffic, sysadmins must immediately apply the latest ca-certificates package to purge the cross-signing authorities from their local trust stores.
The Attack Vector: Cross-Signing and PKI Trust Chains
Public Key Infrastructure (PKI) underpins the security of modern web transport, API communication, and automated software delivery. When a client application like curl, a web browser, or Python's urllib initiates an HTTPS connection, it validates the remote server's certificate against a local store of trusted root authorities located in /etc/ssl/certs/ca-certificates.crt. If any root authority in that store signs or validates an intermediate certificate, the client accepts the connection as legitimate.
The private signing keys belonging to the eMudhra Certificate Authority were recently demonstrated to be compromised. While eMudhra itself was never included as a direct, standalone root certificate inside Ubuntu's default certificate store, it gained widespread legitimacy through cross-signing. Cross-signing is a standard industry practice where established root certificate authorities sign intermediate certificates for newer or regional authorities to provide immediate backward compatibility with legacy operating systems.
Specifically, two prominent root authorities maintained cross-signing relationships with eMudhra:
- emSign Root TLS CA – G3
- Comodo AAA Certificate Services
Because these parent roots were present in Ubuntu's trusted store, an adversary possessing the stolen eMudhra private keys could issue fraudulent X.509 certificates for any domain name on the Internet. Any Ubuntu host evaluating these counterfeit certificates would trace the chain back to the trusted cross-signers and accept the connection without raising a security warning. To neutralize this spoofing and man-in-the-middle vulnerability, the Ubuntu Security Team decided to sever the chain entirely by expelling both parent root certificates from the package trust bundle.
Affected Releases and Updated Package Versions
The remediation spans all maintained Ubuntu branches, including legacy releases covered under Expanded Security Maintenance (ESM) as well as active Long Term Support (LTS) installations. While the Comodo AAA Certificate Services root had already been purged from baseline bundles starting with Ubuntu 22.04 LTS (Jammy Jellyfish), the emSign Root TLS CA – G3 root remained active across the board until this update.
The following table outlines the updated ca-certificates package versions that system administrators must verify on their nodes:
| Ubuntu Release | Codename | Support Tier | Patched Package Version |
|---|---|---|---|
| Ubuntu 14.04 LTS | Trusty Tahr | Ubuntu Pro / ESM | 20230311~14.04.1~esm3 |
| Ubuntu 16.04 LTS | Xenial Xerus | Ubuntu Pro / ESM | 202402031~16.04.1~esm3 |
| Ubuntu 18.04 LTS | Bionic Beaver | Ubuntu Pro / ESM | 202402031ubuntu0.18.04.1+esm3 |
| Ubuntu 20.04 LTS | Focal Fossa | Standard / ESM | 20240203~20.04.1ubuntu0.1~esm2 |
| Ubuntu 22.04 LTS | Jammy Jellyfish | Standard LTS | 20260816ubuntu0.22.04.1 |
| Ubuntu 24.04 LTS | Noble Numbat | Standard LTS | 20260816ubuntu0.24.04.1 |
| Ubuntu 26.04 LTS | Resolute | Standard LTS | 20260816ubuntu0.26.04.1 |
| Ubuntu 26.10 | Stonking | Interim Release | 20260816ubuntu0.26.10.1 |
How to Audit and Patch Your Ubuntu Nodes
To verify the status of your current server or desktop installation, inspect the installed package version using the standard Debian package management tool:
dpkg -l 'ca-certificates' | grep ^iiCompare the output version against the fixed versions listed in the table above. If your system reports an older release string, refresh your package indexes and upgrade the package immediately:
sudo apt update && sudo apt --only-upgrade install ca-certificates -yOnce the upgrade process completes, the packaging script automatically executes update-ca-certificates to rebuild the combined trust bundle located at /etc/ssl/certs/ca-certificates.crt. You can confirm the physical removal of the two revoked certificates by querying the certificate directory directly:
grep -Ei "(emSign|AAA_Certificate_Services)" /etc/ssl/certs/ca-certificates.crtIf the update succeeded, this command will return no output, confirming that the compromised certificate paths have been removed from the combined trust bundle.
ca-certificates package writes the new trust bundle to disk, but persistent background processes such as Nginx proxies, Node.js applications, Java Virtual Machines, and Go binaries often load root certificates into memory at initial startup. Restart your operational daemons or reload their systemd units to ensure they read the updated bundle from disk.
Potential Operational Fallout: Detecting Broken Endpoints
Revoking an entire root authority is a blunt instrument, but it is the only safe response when private keys are compromised. A side effect of purging emSign Root TLS CA – G3 and AAA Certificate Services is that genuine web services that still rely on legitimate certificates issued under those roots will no longer be trusted by updated Ubuntu systems.
If automated scripts, upstream API integrations, or curl commands begin failing with errors such as SSL certificate problem: unable to get local issuer certificate or x509: certificate signed by unknown authority, you can trace the remote certificate chain using OpenSSL:
openssl s_client -connect api.example.com:443 -servername api.example.com -showcertsReview the output's certificate hierarchy. If the remote service terminates its chain in an emSign or Comodo AAA root, the provider must replace their leaf certificate with one issued by an uncompromised authority like Let's Encrypt, DigiCert, or Sectigo's current modern roots. Sysadmins should resist the urge to manually re-add the old root files into /usr/local/share/ca-certificates/, as doing so re-exposes the system to forged certificates signed by the compromised keys.
Container Images and Fleet Considerations
Enterprise environments running containerized workloads must extend this audit beyond host hypervisors. Minimal base images such as ubuntu:22.04 or ubuntu:24.04 ship with pinned package snapshots. Unless rebuilt with an explicit package upgrade or pulled from a freshly published upstream tag, running containers will continue to trust the revoked roots.
Ensure your Dockerfiles or continuous deployment pipelines include an explicit step to refresh root bundles during container image assembly:
RUN apt-get update && apt-get install --no-install-recommends -y ca-certificates \
&& rm -rf /var/lib/apt/lists/*For further technical background and official remediation tracking, refer to the official Ubuntu Security notification detailing the eMudhra key incident. Applying these updates promptly ensures your fleet remains protected against malicious cross-signed certificates.