How to Install Custom CA Certificates across Linux Families

Whether you are dealing with a corporate proxy or an internal service, adding a custom Certificate (CA) is a standard task. However, each Linux “family” handles the trust store differently. Here is how to manually add your certificates and force the system to trust them.

If you have a CA Bundle file (one file containing multiple certificates), some distributions – especially Alpine and Debian prefer that you split them into individual files before copying.

Quick Command to split a bundle:

Run this in the directory where your ca_bundle.pem is located:

awk 'BEGIN {c=0;} /BEGIN CERT/{c++} { print > "cert-" c ".crt"}' < ca_bundle.pem

This creates cert-1.crt, cert-2.crt, etc…

Splitting a bundle into Individual files is not mandatory on all distributions, but it is considered a best practice for consistency and troubleshooting.

For Alpine and Debian, use the update-ca-certificates script. This script creates a symbolic link in /etc/ssl/certs/ for every file it finds in the source directory. If you provide a bundle containing 10 certificates the script only creates a single link for that entire file. Because many Linux applications look for certificates using a unique ID (hash) based on individual entries, they may only “see” the first certificate in your bundle and ignore the rest. Splitting the bundle into individual files ensures every certificate gets its own link and hash.

For Red Hat and Arch, they use the more modern update-ca-trust utility. This tool is designed to be “bundle aware”. When you run the extract command, it scans the source files and correctly identifies every individual certificate within a single file. Splitting is not necessary; you can simply drop the bundle file into the anchors directory, and the system will correctly extract all included.

1. Alpine Linux (The Independent Family)

Alpine is an independent distribution built from the ground up for security and minimalism. It doesn’t follow the standard GNU rules, making it a unique “family” of its own. It is strict: your file must end in .crt or it will be ignored.

Target Directory: /usr/local/share/ca-certificates/

# 1. Move and rename your file
sudo cp your-bundle.pem /usr/local/share/ca-certificates/internal-ca.crt

# 2. Update the system trust store
sudo update-ca-certificates

2. Red Hat Family (RHEL, Fedora, Rocky, Alma)

Red Hat systems use a centralised tool that handles multiple formats, though .pem is standard.

Target Directory: /etc/pki/ca-trust/source/anchors/

# 1. Copy the file (no strict extension requirement)
sudo cp your-bundle.pem /etc/pki/ca-trust/source/anchors/

# 2. Extract and update the trust
sudo update-ca-trust extract

Note: On older systems like RHEL 6, you may need to run update-ca-trust enable once before the first use.

3. Arch Linux Family (Arch, Manjaro, SteamOS)

Arch uses a system similar to Red Hat but with different file paths.

Target Directory: /etc/ca-certificates/trust-source/anchors/

# 1. Copy the file (must end in .crt)
sudo cp your-bundle.pem /etc/ca-certificates/trust-source/anchors/my-ca.crt

# 2. Refresh the anchors
sudo update-ca-trust

4. Debian Family (Ubuntu, Debian, Mint)

This family is the most common and uses the same logic as Alpine.

Target Directory: /usr/local/share/ca-certificates/

# 1. Copy and ensure .crt extension
sudo cp your-bundle.pem /usr/local/share/ca-certificates/corporate-ca.crt

# 2. Run the update tool
sudo update-ca-certificates

What happens when you run the update

Verification and Selection: When you run these update commands, the system essentially performs a “synchronisation” to ensure all of its cryptographic libraries and applications are reading from a single, updated list of trusted entities.
Bundle Regeneration: Most Linux applications expect a single, large file containing all trusted CAs (a “bundle”). The update command:
- Combines the default system certificates provided by the OS
- Appends your custom certificates from the anchors directory
- Overwrites the master bundle file (typically ca-certificates.crt or ca-bundle.crt ) with this new, combined list.
OpenSSL Hashing: Tools like OpenSSL need a way to find a specific certificate quickly without reading every file. The update command creates symbolic links named after the certificate’s hash (e.g. a1b2c4d4.0) that point back to the actual certificate file. This allows the system to look up a CA instantly during a secure handshake.
Application Hooks: Finally, the command triggers “hooks” – scripts that update the trust stores for specific software that doesn’t use the standard system bundle.
- Java: Regenerates the cacerts Java Keystore (JKS)
- NSS/Browsers: Updates databases used by the browsers like Firefox or Chrome, though some browsers may still require a restart to pick up the changes.

Verify

You can verify that your certificate was successfully added by checking the Subject line of the certificates inside the system’s master bundle or by using a simple connection test.

1. Quick Method

The fastest way to see if your certificate made it into the combined system bundle is to search for it’s unique “Subject” name directly in the bundle file.

Alpine, Debian and Arch:

grep "Your CA Name" /etc/ssl/certs/ca-certificates.crt

Red Hat:

grep "Your CA Name" /etc/pki/tls/certs/ca-bundle.crt

If this returns a match, the system has successfully “seen” your certificate during the update.

2. The OpenSSL “Issuer Scan” (More Accurate)

Since certificates are binary but the bundle is text, you can use awk and openssl together to list every trusted issuer on your system.

awk -v cmd='openssl x509 -noout -subject' ' /BEGIN/{close(cmd)};{print | cmd}' < /etc/ssl/certs/ca-certificates.crt

Change the path to /etc/pki/tls/certs/ca-bundle.crt if on Red Hat

3. Live Connection Test

The “real world” test us to try and connect to a server that uses this CA. If the certificate is trusted, curl will succeed without a “self-signed” error.

curl -vI https://your-internal-service.local

Look for the line: * SSL certificate verify ok.

4. Listing Trust Anchors (Arch and Red Hat)

On systems that use the p11-kit tool, you can verify the trust status of all anchors with one command

trust list --filter=ca-anchors | grep "Your CA Label" -A 2 -B 3

This will confirm if the system has assigned the anchor category to your certificate. Which is what grants it “trusted” status.

To remove a Certificate

To remove a certificate, you essentially reverse the installation process. You remove the file from the source and run the update again.

Alpine and Debian: sudo rm /usr/local/share/ca-certificates/your-cert.crt
Red Hat: sudo rm /etc/pki/ca-trust/source/anchors/your-cert.crt
Arch: sudo rm /etc/ca-certificates/trust-source/anchors/your-cert.crt

Update the Trust store

Once the file is gone, you must trigger the system to regenerate its master bundle files.

Alpine and Debian: sudo update-ca-certificates --fresh (the --fresh flag is helpful as it wipes out stale symbolic links.
Red Hat and Arch: sudo update-ca-trust extract

Conclusion

While the “Linux way” of doing things varies by distribution, managing trust is consistent once you know your family’s specific path. By placing your certificates in the correct anchor directory and running the update utility, you ensure that your system utilities, like curl and wget, can communicate securely with your internal services.