Adding a private CA to the system trust store on RHEL-family and Debian/Ubuntu

Goal

Make a private or internal CA certificate trusted system-wide by OpenSSL, curl, and other libraries that read the OS trust store, on both RHEL-family and Debian-family Linux.

Prerequisites

Root privileges; the CA certificate in PEM format (RHEL-family anchors also accept DER); the ca-certificates package installed (Debian/Ubuntu) or the ca-certificates package providing update-ca-trust (RHEL, Fedora, and derivatives such as Rocky/Alma, RHEL 7 and later).

Steps

RHEL-family:

1. Copy the CA certificate (PEM or DER; the file name and extension do not matter here) into /etc/pki/ca-trust/source/anchors/. Do not drop it into the parent /etc/pki/ca-trust/source/ directory: plain certificates there are treated as distrusted.
2. Run update-ca-trust extract as root (plain update-ca-trust without arguments does the same). It reads the anchors directory plus vendor defaults and regenerates the consolidated files under /etc/pki/ca-trust/extracted/ (PEM bundles, a Java keystore); NSS-based applications read the same sources through the p11-kit-trust module.
3. Non-interactive: the command takes no prompts; it is safe in unattended provisioning scripts.

Debian/Ubuntu:

1. Copy the CA certificate into /usr/local/share/ca-certificates/ (subdirectories are allowed); the file must end in .crt and must be PEM (BEGIN CERTIFICATE) — update-ca-certificates only picks up .crt files there, and a DER file renamed to .crt does not become a usable bundle entry; convert it with openssl x509 -inform der first.
2. Run update-ca-certificates as root. It refreshes the hash links in /etc/ssl/certs, regenerates /etc/ssl/certs/ca-certificates.crt, and then runs the hooks in /etc/ca-certificates/update.d/.
3. For unattended installs, DEBIAN_FRONTEND=noninteractive has no effect here since the tool itself is non-interactive; it only matters for the surrounding apt-get install ca-certificates step if the package is missing.

Expected result

openssl verify -CAfile /etc/ssl/certs/ca-certificates.crt mycert.pem (Debian) or openssl verify -CAfile /etc/pki/ca-trust/extracted/pem/tls-ca-bundle.pem mycert.pem (RHEL-family; older releases also expose it under the legacy path /etc/pki/tls/certs/ca-bundle.crt) reports OK for a certificate chaining to the new CA. On RHEL-family, trust list | grep -i "<CA common name>" (p11-kit) confirms the anchor was registered; on Debian/Ubuntu the trust command exists only if the p11-kit package is installed.

Limits and test basis

A .pem file dropped in the wrong directory, or a Debian file without the .crt extension, is silently ignored by both tools — there is no error, only a chain that still fails to verify. Distribution-packaged OpenJDK usually reads a keystore generated from this same store (/etc/pki/java/cacerts on RHEL-family; /etc/ssl/certs/java/cacerts via the ca-certificates-java hook on Debian/Ubuntu), but a vendor JDK unpacked from a tarball and a pip-installed certifi keep separate stores. Processes that already loaded the bundle keep the old set until restarted. To remove a CA, delete the file from the anchors or /usr/local/share/ca-certificates directory and rerun the same command (on Debian, update-ca-certificates --fresh rebuilds the links from scratch if a stale one remains).