How to update cURL CA bundle on RedHat?
For RHEL 6 or later, you should be using update-ca-trust, as lzap describes in his answer below.
--- For older versions of Fedora, CentOS, Redhat:
Curl is using the system-default CA bundle is stored in /etc/pki/tls/certs/ca-bundle.crt . Before you change it, make a copy of that file so that you can restore the system default if you need to. You can simply append new CA certificates to that file, or you can replace the entire bundle.
Are you also wondering where to get the certificates? I (and others) recommend curl.haxx.se/ca . In one line:
curl https://curl.haxx.se/ca/cacert.pem -o /etc/pki/tls/certs/ca-bundle.crt
Fedora Core 2 location is
The recommended way of doing that on RHEL 6+ systems is to use update-ca-trust tool, which is now installed by default.
# cat /etc/pki/ca-trust/source/README This directory /etc/pki/ca-trust/source/ contains CA certificates and trust settings in the PEM file format. The trust settings found here will be interpreted with a high priority - higher than the ones found in /usr/share/pki/ca-trust-source/. ============================================================================= QUICK HELP: To add a certificate in the simple PEM or DER file formats to the list of CAs trusted on the system: Copy it to the /etc/pki/ca-trust/source/anchors/ subdirectory, and run the update-ca-trust command. If your certificate is in the extended BEGIN TRUSTED file format, then place it into the main source/ directory instead. ============================================================================= Please refer to the update-ca-trust(8) manual page for additional information
Therefore, you only need to drop your crt file to the
/etc/pki/ca-trust/source/anchors/ and to run the tool. Work done. This is safe to do, you don't need to do any backups. Full manual page can be found here: https://www.mankier.com/8/update-ca-trust
Probably depends which version of Redhat. You can find which package actually updates the file by doing:
rpm -qf /etc/pki/tls/certs/ca-bundle.crt
My result was showing that openssl-0.9.8e-12.el5 needs to be updated.
If there is no updated certificates in your distribution, you have to manually update, as per Nada's answer.
RHEL provides the Mozilla CA certificates as part of the
ca-certificates package (install this with
yum if it's not already installed). To tell cURL to use these, use the
--cacert parameter like so.
curl --cacert /etc/ssl/certs/ca-bundle.crt https://google.com/
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
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
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.