Since Dan Pritts' comment, Red Hat has been updating the certificate bundles for supported RHEL releases more often; you can see this quite easily in the package changelog. RHEL 6's certificates were updated twice in 2013 and twice in 2014.
All RHEL and related / clone / derived distros provide a bundle file at /etc/pki/tls/certs/ca-bundle.crt
, and the same file at /etc/pki/tls/cert.pem
(on older distros cert.pem
is a symlink to ca-bundle.crt
; on newer distros both are symlinks to a file output by update-ca-trust
).
In RHEL 6 and newer, the bundle is part of the 'ca-certificates' package. In RHEL 5 and earlier it is part of the 'openssl' package.
In RHEL 6 with the update https://rhn.redhat.com/errata/RHEA-2013-1596.html and any newer RHEL, the 'shared system certificates' system is available (you must run update-ca-trust enable
to enable it) and the best method is that given by lzap. A benefit of this system is that it works for NSS and GnuTLS-based applications as well as OpenSSL-based ones. Note that you can also distrust a certificate by placing it in the directory /etc/pki/ca-trust/source/blacklist/
.
In RHEL 5 and older (and RHEL 6 if you do not wish to use the new system) you can trust extra CAs by placing their PEM formatted certificate files with the extension .pem
in /etc/pki/tls/certs and running c_rehash
(may also need yum install /usr/bin/c_rehash
). This will only work for software that uses OpenSSL's default trust stores. This is better than editing or replacing the bundle file because it allows you to continue receiving official updates to the bundle file.
Software that uses one of the bundle file locations directly (rather than asking OpenSSL to use the system default trust stores) will not respect the change; if you have such software you are stuck editing the bundle file (or improving the software). Software that doesn't use OpenSSL at all will not respect the added certificate.