Trusting additional CAs in Fedora / RHEL / CentOS: an alternative to editing /etc/pki/tls/certs/ca-bundle.crt (or /etc/pki/tls/cert.pem)

Around the internet, you can find various pages advising appending CA certificates to /etc/pki/tls/certs/ca-bundle.crt or /etc/pki/tls/cert.pem (they're the same file, one's a symlink to the other) as a good way to trust them.

This may be necessary, but it has drawbacks (the main one being that once you've edited the file, it will no longer be automatically updated; updates will appear as ca-bundle.crt.rpmnew and you'll have to remember to manually move it to ca-bundle.crt and re-append your custom certs). There's an alternative approach that may be better for you, even on really old RHEL / CentOS.

On Fedora since 19, RHEL / CentOS 7, and RHEL / CentOS 6 since this update, the Shared System Certificates feature is available. With that system, the correct method is to place the certificate to be trusted (in PEM format) in /etc/pki/ca-trust/source/anchors/ and run sudo update-ca-trust. (If the certificate is in OpenSSL's extended BEGIN TRUSTED CERTIFICATE format, place it in /etc/pki/ca-trust/source). On RHEL 6, you have to activate the system with update-ca-trust enable after installing the update; if you don't want to use it, you can try the approach below.

On RHEL / CentOS 5, that system isn't available. But it's still not a good idea to modify the distribution's bundle file unless you really have to, as explained above.

Instead of appending to the bundle file, you can try placing the certificate to be trusted (in PEM format with the extension .pem) in /etc/pki/tls/certs and run sudo c_rehash (you may need a yum install /usr/bin/c_rehash). The .pem extension is important, c_rehash will only process files with this extension.

Readers of my last post may grok what's going on there: /etc/pki/tls/certs is OpenSSL's 'default CApath' on RHEL/CentOS, and OpenSSL will trust both certificates found in the 'default CAfile' - /etc/pki/tls/cert.pem - and in the 'default CApath' - /etc/pki/tls/certs.

The caveat is that this only works for things that use OpenSSL and use its default trust store locations. It won't work for apps that use OpenSSL but directly use the bundle file instead of using OpenSSL's 'default trust store' function, and it won't work for anything based on GnuTLS (whereas editing the bundle file often will, as we often have those patched to load the bundle file directly).

So sometimes you just have to edit the bundle file - but in some cases you might be able to avoid it.


Umesh Sundareshan wrote on 2016-03-22 18:57:
Hi, How do we remove a CA from the ca-bundle.crt or cert.pem? By removing the certificate manually using an editor would work? Thanks, Umesh
Maciej wrote on 2016-05-09 13:55:
Yes, editor will do the work. Maicej,
Mauricio wrote on 2016-05-13 21:00:
Thank you very much for this!
CyberDummy wrote on 2016-08-05 20:28:
So... Should the certificates that were placed in /etc/pki/ca-trust/source/anchors/ be removed after this operation is completed? I am thinking that they should.
Andreas Schöneck wrote on 2016-08-12 06:26:
Nowadays, the place to put the pem files is /usr/share/pki/ca-trust-source/anchors For more information, read /usr/share/pki/ca-trust-source/README
John Peter Harvest wrote on 2016-09-22 11:41:
Both directories can be used! From the update-ca-trust man page: Files in subdirectories below the directory hierarchy /usr/share/pki/ca-trust-source/ contain CA certificates and trust settings in the PEM file format. The trust settings found here will be interpreted with a low priority. Files in subdirectories below the directory hierarchy /etc/pki/ca-trust/source/ contain CA certificates and trust settings in the PEM file format. The trust settings found here will be interpreted with a high priority.
adamw wrote on 2016-09-27 01:07:

By convention, software packages that needed to install anchors for some reason would put them in /usr/share/pki/ca-trust-source , while /etc/pki/ca-trust/source would be for the sysadmin to use.

Binh Thanh Nguyen wrote on 2017-02-22 09:57:
Thanks, nice tips
Matthew wrote on 2018-08-23 15:07:
Thank you for this article and the comments/tips below - cleared things up for me! I was wondering why there was more than one directory to use?!
in wrote on 2018-09-26 15:20:
I always get the error Failed to install certificate: A valid full certificate chain from the host certificate to the Certificate Authority's certificate must be provided. Help please
Paul Collins wrote on 2018-12-10 22:37:
@in, if asked for a full certificate chain, and pem (text) format files are allowed (as it appears to be in this context), you may be able to concatenate the needed certificates together (specific domain, intermediate, and root) into a single file and use that. General chain file creation for several scenarios: Mainly I'm here to add my thanks for the useful instructions.
alla wrote on 2019-06-18 09:32:
hmm I have a problem, can you pls help me? I have .crt cert-file from Windows, I export it in base64 format, and it looks like that: -----BEGIN CERTIFICATE----- MIIDojCCAoqgAwIBAgIQeqkpty5ghoxP8YfCRe+7qjANBgkqhkiG9w0BAQUFADBP some more strings FnpKVwAq6UcYOu4AoXweaqOOMsLNSw== -----END CERTIFICATE----- So i put this crt file in /etc/pki/ca-trust/source/anchors/cert.crt and execute "update-ca-trust extract". No error codes, nothing in /var/log/messages. So if I check ls -al /etc/pki/tls/certs/ca-bundle.crt I see what nothing changes - last change date of file is 2 months ago. Why this didn't work?
Gregory Young wrote on 2019-06-28 15:36:
Check /etc/pki/tls/certs/, it should be at the top. The question I have is why it gets put in this file, when the /etc/pki/tls/certs/ca-bundle.crt file is referenced by openssl and others?
adamw wrote on 2019-10-18 18:28:
it's been years since I looked at this stuff, but it *should* wind up in *both*, AFAIR. `ca-bundle-trust.crt` includes certificates in the extended 'BEGIN TRUSTED CERTIFICATE' format, `ca-bundle.crt` includes certificates in the basic 'BEGIN CERTIFICATE' format. If it doesn't wind up in *either*, the file may be invalid, I guess, but I'm not too sure.