eMudhra CA compromise fixes available

This blog post was updated with additional information related to libnss3 and Java applications on October 22, 2026.

Introduction

The private keys of the eMudhra Certificate Authority (CA) have been demonstrated on 20 October 2026 to have been compromised. The Ubuntu Security Team has released updates to the system PKI (Public Key Infrastructure) root CA store in the ca-certificates package, as well as in the libnss3 library. If you have any Java applications, the Java root CA store requires manual action.

While the eMudhra CA is not directly trusted as a root on Ubuntu, two other root CAs have cross-signed the eMudhra CA: emSign Root TLS CA – G3 and Comodo AAA Certificate Services. These two roots have been removed from the Ubuntu trusted root stores to ensure that the compromised eMudhra CA is no longer trusted. Any legitimate certificate which is ultimately trusted by either of these two root CAs would no longer be trusted. It is unlikely, but this may result in some hosts being unreachable, due to their use of the revoked certificate. The AAA Certificate Services CA had previously been removed from the CA bundles in Ubuntu 22.04 (Jammy Jellyfish) and newer releases.

Which Ubuntu releases are affected?

How to check if you are impacted

You can verify the version of the affected packages with the following command:

dpkg -l ca-certificates 'libnss3*' | grep ^ii

Users of Java applications need to apply a manual mitigation, detailed in the ‘Updating the Java root CA store’ section below.

Desktop users should take special notice of their browsers installed as snap packages and follow the recommendation in the ‘Note for Ubuntu Desktop users’ section below.

Impact of the CA Compromise

An unauthorized third party would be able to sign fraudulent X.509 certificates; these would pass validation by a TLS implementation (commonly TLS clients) that trusts the eMudhra CA. Mitigations such as public key pinning or DNS Certificate Authority Authorization (CAA) records do provide the ability to detect such fraudulent certificates, but depend on the TLS application making use of the mitigations and are not widely used.

This could lead to the identity impersonation of a TLS endpoint and could allow an attacker-in-the-middle to intercept and compromise the confidentiality and integrity of TLS connections, irrespective of the CA that the authentic TLS endpoint uses, unless mitigations are employed.

How to apply fixes

We recommend you upgrade all packages:

sudo apt update && sudo apt upgrade

If this is not possible, the affected component can be targeted:

sudo apt update && sudo apt install --only-upgrade ca-certificates 'libnss3*'

The unattended-upgrades feature is enabled by default for Ubuntu 16.04 LTS onwards. This feature:  

• Applies new security updates every 24 hours automatically.
• If you have this enabled, the patches above will be automatically applied within 24 hours of being available.

Ubuntu 26.10, 26.04 LTS, 24.04 LTS, and 22.04 LTS receive these fixes as part of standard support. If you are using Ubuntu 20.04 LTS or older, you can apply this fix with an Ubuntu Pro subscription via the Expanded Security Maintenance (ESM) service. Ubuntu Pro is free for up to 5 machines, or up to 50 machines for community members. Ubuntu Pro also provides access to Landscape which enables you to control the roll-out of security fixes across your estate. Learn more. 

Updating the Java root CA store

The instructions in this section are only necessary if you use any Java applications.

The Java root CA store is normally synchronized from the ca-certificates package containing the system root CA store. However, this synchronization is currently affected by an unresolved issue. This means that at present, removing the compromised certificates requires additional manual action after the ca-certificates package has been updated according to the section above.

If the Java root CA store contains locally-provisioned CA certificates that are not part of the system root CA store, these will need to be re-added after the following commands are executed.

First, delete the existing Java root CA store:

sudo rm -f /etc/ssl/certs/java/cacerts

Then, regenerate the Java root CA store from the system CA store:

sudo update-ca-certificates --fresh

Note for Ubuntu Desktop users

On Ubuntu Desktop, the most common TLS client would be a browser. They are typically installed as snap packages on Ubuntu desktop, and do not use the system trust store provided by the ca-certificates package. Snap packages are refreshed four times a day by default. If you have disabled automatic updates, ensure that you refresh your snaps manually.

References

• https://ubuntu.com/security/notices/USN-8944-1
• https://ubuntu.com/security/notices/USN-8944-2
• https://ubuntu.com/security/notices/USN-8947-1
• https://emudhra.we-have-a-problem.com/