Class UnixSystemTrustKeyStoreUtil

java.lang.Object
ghidra.net.UnixSystemTrustKeyStoreUtil
public final class UnixSystemTrustKeyStoreUtil NEW extends Object
Builds a trust KeyStore backed by the host Linux (and BSD variants) operating system's known CA trust-store locations.

Rationale: Java ships no native "OS trust store" KeyStore provider on Linux/BSD (unlike "Windows-ROOT" on Windows or "KeychainStore" on macOS). Nearly every distro instead maintains one or more PEM bundle files (and/or a directory of individual PEM certs) kept in sync with the system's trust configuration by tooling such as update-ca-certificates, update-ca-trust, or p11-kit. This class scans the well-known locations for those bundles, parses every certificate it finds, de-duplicates by fingerprint, and loads the result into an in-memory KeyStore that is handed to a TrustManagerFactory.

Desktop environments (GNOME, KDE, XFCE, Cinnamon, etc.) don't keep a separate trust store for TLS -- they consume the same system bundle (often via p11-kit / NSS, which is itself synced from the paths below), so no desktop-manager-specific handling is required beyond this.

Only the trust configuration the OS has actually put into effect is used. The locations scanned are those which the OS tooling produces -- the extracted bundles of BUNDLE_FILES and the enabled-certificate directories of BUNDLE_DIRS -- and never the source/anchor directories which feed that tooling. Those source directories retain certificates which an administrator has since disabled: Debian and Ubuntu disable a CA by prefixing it with ! in /etc/ca-certificates.conf (the file itself remaining under /usr/share/ca-certificates), and RHEL and Fedora distrust one through /etc/pki/ca-trust/source/blocklist while it may still sit in source/anchors. Reading a source directory would therefore re-trust exactly those authorities the administrator removed, so it is not done.

Known limitations:

  • Requires read access to the relevant system paths (usually world-readable, but not guaranteed in hardened/minimal images).
  • Minimal container images (e.g. distroless, scratch) may not have any CA bundle installed at all -- no OS trust store is produced in that case and the caller falls back to the Java default trust store.
  • Distros that route trust exclusively through a PKCS#11/NSS token rather than exporting a PEM bundle are not covered; nearly all mainstream distros do export a PEM bundle as of this writing.