Linux- Security- Create System Certificate Bundle

What the Linux TLS trust bundle Worklet does

This Automox Worklet™ enforces a single canonical TLS trust bundle path on Linux endpoints. The Worklet creates a stable symlink at /etc/pki/tls/certs/cabundle.pem that points to whichever CA bundle the distribution actually maintains. It then writes /etc/profile.d/cabundle.sh so every login shell exports REQUESTS_CA_BUNDLE, CURL_CA_BUNDLE, and SSL_CERT_FILE to the same canonical path.

The Worklet probes three known bundle locations in order: /etc/pki/tls/certs/ca-bundle.crt for RHEL, CentOS, Rocky, Alma, Amazon Linux, and Fedora; /etc/pki/ca-trust/extracted/pem/tls-ca-bundle.pem for endpoints running the ca-trust framework; and /etc/ssl/certs/ca-certificates.crt for Debian, Ubuntu, and SUSE. The first bundle that exists wins. The script does not generate, rebuild, or merge certificate files. It points the canonical link at the bundle the OS already maintains through update-ca-trust or update-ca-certificates.

Because the evaluation phase is idempotent, the Worklet can run on a recurring policy and re-pin the symlink whenever an image refresh, package upgrade, or admin error drifts the path. The remediation script uses set -euo pipefail, so any unexpected error surfaces in Automox activity logs rather than failing silently.

Why enforce a canonical TLS trust path

Linux distributions disagree on where the system CA bundle lives. RHEL writes /etc/pki/tls/certs/ca-bundle.crt, the ca-trust framework adds /etc/pki/ca-trust/extracted/pem/tls-ca-bundle.pem on top, and update-ca-certificates on Debian, Ubuntu, and SUSE writes /etc/ssl/certs/ca-certificates.crt. Applications that hard-code one path fail SSL validation on every other distribution, and a fleet built from mixed base images carries that breakage forward. Python requests, curl, and OpenSSL each honor different environment variables, so a developer who fixes curl on one host has not fixed requests on the next.

A stripped /etc/profile.d entry or a missing symlink under /etc/ssl/certs is enough to break curl, pip install, and git clone for an entire CI cluster, and the symptom rarely points at the root cause. Run this Worklet across the RHEL, Ubuntu, Debian, and container-host fleet to write the canonical CA bundle path and export SSL_CERT_FILE through /etc/profile.d in a single policy pass, then keep it on a recurring schedule so the next evaluation rebuilds the trust path before a CI job fails or a developer files a broken-TLS ticket. The configuration covers servers, container hosts, and developer workstations under a single trust baseline.

How TLS trust path enforcement works

1. Evaluation phase: The Worklet checks that /etc/pki/tls/certs/cabundle.pem exists as a symlink. It resolves the link with readlink -f and confirms the target matches one of /etc/pki/tls/certs/ca-bundle.crt, /etc/pki/ca-trust/extracted/pem/tls-ca-bundle.pem, or /etc/ssl/certs/ca-certificates.crt. The script then opens /etc/profile.d/cabundle.sh and grep-tests for REQUESTS_CA_BUNDLE, CURL_CA_BUNDLE, and SSL_CERT_FILE pointing at the canonical link. Any missing file, missing line, or wrong target returns exit 1 and the endpoint is flagged non-compliant.

2. Remediation phase: The remediation script walks the same three candidate bundle paths and selects the first one that exists on disk. It creates the parent directory with mkdir -p, then runs ln -sf to point /etc/pki/tls/certs/cabundle.pem at the chosen bundle. The script writes /etc/profile.d/cabundle.sh containing three export lines: REQUESTS_CA_BUNDLE, CURL_CA_BUNDLE, and SSL_CERT_FILE, each set to the canonical link path. If no candidate bundle exists, the script writes a message to stderr and exits non-zero so the failure is visible in policy logs.

TLS trust bundle requirements

• Linux endpoint running RHEL, CentOS, Rocky, Alma, Fedora, Amazon Linux, Debian, Ubuntu, or SUSE

• At least one of the candidate CA bundles already maintained by the distribution: /etc/pki/tls/certs/ca-bundle.crt, /etc/pki/ca-trust/extracted/pem/tls-ca-bundle.pem, or /etc/ssl/certs/ca-certificates.crt

• The ca-certificates package on Debian and Ubuntu, or the ca-certificates RPM on RHEL family endpoints, so the underlying bundle is kept current by update-ca-certificates or update-ca-trust

• Root or sudo privileges for writing to /etc/pki/tls/certs/ and /etc/profile.d/ (the default Automox agent context already meets this)

• Bash with set -euo pipefail support; the Worklet does not require additional packages beyond a standard distribution install

Expected TLS trust state after enforcement

On RHEL family endpoints, /etc/pki/tls/certs/cabundle.pem resolves to /etc/pki/tls/certs/ca-bundle.crt or to /etc/pki/ca-trust/extracted/pem/tls-ca-bundle.pem when the ca-trust framework is active. On Debian, Ubuntu, and SUSE endpoints, the same canonical link resolves to /etc/ssl/certs/ca-certificates.crt. The file /etc/profile.d/cabundle.sh exports REQUESTS_CA_BUNDLE, CURL_CA_BUNDLE, and SSL_CERT_FILE, all pointing at /etc/pki/tls/certs/cabundle.pem, so every new login shell on the endpoint resolves TLS trust through the same path.

Subsequent Automox policy runs report the endpoint as compliant without re-applying remediation, because the evaluation phase finds the symlink, the target, and all three profile exports already in place. Distribution package updates that refresh the underlying bundle continue to flow through the canonical link without further action, since the Worklet does not duplicate or freeze certificate content. The canonical path holds across reboots and kernel upgrades and is only disturbed when an administrator or a competing configuration script removes the symlink or the profile file. The next evaluation flags that endpoint and the Worklet restores both artifacts.