Browser protections were an important first response to the eMudhra certificate authority incident. But they don't answer a harder question for organizations: which other tools and environments still trust the affected certificate chains?
Certificate trust can come from different places. A tool may use the operating system's trust store, a bundled certificate list, or a runtime-specific store such as a Java JDK's cacerts. One machine can therefore have different trust behavior across its browsers, developer tools, and runtimes. Updating one trust store doesn't update them all.
That makes eMudhra remediation a software supply chain problem. Teams need to find where trust is configured, identify which systems need attention, and confirm that updates reach the tools developers and build processes actually use.
Paul Horton, Sonatype's Open Source Program Office (OSPO) Global Director, created the open source eMudhra Audit and Fix script to help teams inspect selected developer tools on Unix-like machines.
The script checks tools such as Java, Node.js, Python, Go, and Git, along with system certificate bundles and other components. Where supported, it makes live HTTPS requests to two test hosts whose certificates chain to the affected intermediates, then checks GitHub as a control. The control helps distinguish certificate rejection from other connection problems, such as a lack of network access. The script also compares some tool versions with fixes listed in the incident reference. When a live probe and version check disagree, the live probe takes precedence.
By default, the audit does not install, change, or delete anything on the machine. It creates temporary probe programs and makes ordinary HTTPS requests. Those requests send no file contents. If network probes aren't appropriate for an environment, the --no-network option skips them and runs version checks only.
Teams can use the results to identify tools that need attention and decide what to investigate next. An audit result is a starting point for remediation, not confirmation that every system in the organization is protected.
Teams can use the script's output to:
Identify affected or potentially affected tools on a workstation.
Confirm how each tool is installed and which trust store it uses.
Apply the relevant operating system, runtime, or application vendor update.
Re-run the checks and record which systems still need remediation.
The script also has an optional --fix mode that can apply some changes it supports, asking before each change. Those actions can include upgrading a supported tool or changing a system or runtime trust store. Review the README and the proposed action before proceeding; the --dry-run option shows what a fix would do without changing anything. Prefer vendor updates where available, and test any workaround against the systems and services that depend on the trust store.
The script audits the machine where it runs. It does not scan remote hosts, containers, or per-project dependencies. Its coverage is limited to specified tools and installation paths. Some tools receive version checks rather than live probes. A result from a developer workstation therefore cannot establish the status of a CI runner, container image, production host, or another employee's machine.
Organizations should treat those environments as separate parts of the investigation. Update and verify container images, build agents, and managed systems through the processes and vendor guidance that apply to them. For Sonatype products, follow the current Help documentation for product-specific updates and instructions.
The eMudhra incident showed why browser status alone can't answer whether an organization is remediated. Trust stores are distributed across tools and environments, and each one needs an owner and a way to verify its status. Paul's script gives teams a practical way to examine part of that landscape. Completing the work still requires a broader inventory, vendor updates, and follow-up checks.
The script is part of the Sonatype Nexus Community. If you have feedback or would like to contribute, engage with the project by following its Contribution Guidelines. As a community project, it is not officially supported by Sonatype.
For background on the eMudhra incident and Sonatype's response, see our published blog post.