Update Root Certificates

What the Linux root CA refresher does

This Automox Worklet™ refreshes the ca-certificates package on Linux endpoints, which is the package that populates the system root CA trust store used by openssl, curl, wget, gnutls, python's ssl module, the JVM cacerts truststore (on most distributions), and every other TLS client that reads /etc/ssl/certs/ca-certificates.crt or /etc/pki/tls/certs/ca-bundle.crt. The Worklet detects the package manager in use and runs the right command for that distribution family, so the same policy works on RHEL, CentOS, Rocky, Alma, Fedora, Amazon Linux, Debian, and Ubuntu endpoints without per-host branching.

On RPM-based endpoints, the Worklet runs yum update ca-certificates -y -q (or the dnf equivalent on Fedora and modern RHEL) to pull the latest certificate bundle from the distribution repository. On Debian and Ubuntu endpoints, it first runs apt-get update -y -qq to refresh package metadata, then apt-get --only-upgrade install ca-certificates -y -qq so only the trust store package moves, with no other packages dragged along. The package post-install hook invokes update-ca-certificates (Debian family) or update-ca-trust (RHEL family) automatically, which rebuilds the consolidated PEM bundle and the symlinks under /etc/ssl/certs/.

The Worklet does not replace certutil -addstore (Windows) or security add-trusted-cert (macOS), which are platform-specific trust store APIs. On Linux, the canonical path is the ca-certificates package plus update-ca-certificates / update-ca-trust, and that is what this Worklet operates against. Custom local CAs dropped into /usr/local/share/ca-certificates/ (Debian) or /etc/pki/ca-trust/source/anchors/ (RHEL) are preserved across the refresh.

Why keep the Linux root CA trust store current

Public certificate authorities rotate their roots on a multi-year cadence, distrust each other's intermediates after compromise events, and ship new roots whenever a major TLS provider crosses an audit milestone. A Linux endpoint running a stale ca-certificates package eventually fails to validate the chain on routine TLS handshakes. The failure typically surfaces as x509: certificate signed by unknown authority in Go services, SSL: CERTIFICATE_VERIFY_FAILED in Python, or SSL certificate problem: unable to get local issuer certificate from curl. Distrusted CAs are also still trusted on stale endpoints, which means a compromised legacy root can sign a certificate that the endpoint will accept long after the rest of the internet has stopped accepting it.

The ca-certificates package is one of the first things that goes stale on a long-running Linux host. A build server pinned to a distribution snapshot from two years ago can quietly fail to pull from a private container registry whose certificate now chains through a newer Let's Encrypt or DigiCert root. A developer workstation kept off the network for a quarter surfaces SSL: CERTIFICATE_VERIFY_FAILED on a TLS handshake nobody can reproduce. The Worklet calls yum update or apt-get --only-upgrade install ca-certificates on every cycle, lets the package post-install hook rebuild the consolidated PEM bundle, and reports the package version delta in the activity log so the trust store stays aligned with CIS Linux Benchmark guidance and the cryptographic protocol requirements of PCI-DSS v4.0 Requirement 4.2.

How root CA trust store refresh works

1. Evaluation phase: The evaluation script exits 1 unconditionally, which is intentional. Determining whether an update is actually available without invoking the package manager would require parsing repository metadata by hand on every distribution, so the script defers that work to the remediation phase, which calls yum check-update ca-certificates or apt-get --simulate --only-upgrade install ca-certificates internally. If the package is already at the repository version, the package manager is a no-op and the run is cheap. If an update is staged, the Worklet applies it.

2. Remediation phase: The remediation script uses which yum and which apt-get to detect the available package manager. If yum is on PATH, it runs yum update ca-certificates -y -q, which pulls the latest bundle and triggers the update-ca-trust post-install hook to rebuild /etc/pki/ca-trust/extracted/. If apt-get is on PATH, it runs apt-get update -y -qq followed by apt-get --only-upgrade install ca-certificates -y -qq, which pulls the latest bundle and triggers update-ca-certificates to rebuild /etc/ssl/certs/ca-certificates.crt. Exit code 0 means the package manager returned success; non-zero surfaces in Automox activity logs with the package manager's stderr attached.

Root CA refresh requirements

• Linux endpoint running RHEL, CentOS, Rocky, Alma, Fedora, Amazon Linux, Debian, or Ubuntu with yum, dnf, or apt-get on PATH

• Root or sudo privileges for the Automox agent; the default agent context already meets this

• Network reachability from the endpoint to the configured distribution repository (or an internal mirror that proxies it)

• ca-certificates package already installed on the endpoint; this Worklet refreshes an existing install rather than performing a first install

• Repository GPG key trusted by the local package manager so the metadata refresh and package install do not fail signature verification

• FixNow compatible, so the Worklet can be triggered on a single endpoint or a group on-demand when a TLS failure is actively breaking a workflow

Expected trust store state after refresh

After remediation, rpm -q ca-certificates (RHEL family) or dpkg-query -W -f='${Version}\n' ca-certificates (Debian family) reports the latest version available in the configured repository. The consolidated bundle at /etc/ssl/certs/ca-certificates.crt (Debian) or /etc/pki/tls/certs/ca-bundle.crt (RHEL) is rewritten with the new CA set, and the per-CA symlinks under /etc/ssl/certs/ are refreshed. Custom CAs you previously dropped into /usr/local/share/ca-certificates/ or /etc/pki/ca-trust/source/anchors/ are preserved because the post-install hook merges them back into the consolidated bundle.

Validate the refresh from the endpoint with openssl s_client -connect example.com:443 -CAfile /etc/ssl/certs/ca-certificates.crt, which should report Verify return code: 0 (ok) on a server whose chain is signed by a publicly trusted CA. curl -v https://example.com should print SSL certificate verify ok and complete the handshake. For audit evidence, capture the output of awk -v cmd='openssl x509 -noout -subject -issuer -dates' '/BEGIN CERT/{close(cmd)};{print | cmd}' < /etc/ssl/certs/ca-certificates.crt and store it with the policy run identifier. No service restart is required; TLS clients pick up the new bundle on their next connection, except for long-running daemons that cache the trust store in memory, which need a reload to see the change.