Trust is important. You can't blindly trust everybody and everything; instead, you should base trust on experience and reputation. In the world of networking, a certificate authority (CA) is an organization that vouches for Secure Sockets Layer (SSL) certificates, which indicate that a web server can be trusted.
Red Hat Enterprise Linux uses the ca-certificates
package, which includes the Mozilla Foundation's set of CA certificates for use with the internet public key infrastructure (PKI). At the time I'm writing this, the ca-certificates
package has around 140 CAs in it. This bundle of certificates is essentially the default "people to trust" list. The RHEL documentation covers handling shared system certificates in further detail. The article Making CA certificates available to Linux command-line tools also covers CA certificates.
This article covers accepting additional CAs (adding more people to your trusted list) and then digs deeper into rejecting CAs and why you may want to do that.
Adding a trusted CA
Adding additional CAs is a common practice. To do this, you need to get the certificate and copy it to one of the approved directories, such as /etc/pki/ca-trust/source/whitelist/
.
[ Improve your skills managing and using SELinux with this helpful guide. ]
Any time you add something to either the blacklist
or whitelist
directories, you must update the trust list:
$ update-ca-trust
Verifying trust status
You can verify whether a CA can be trusted by looking at the "anchor" value in the trust key:
$ trust list --filter=ca-anchors | grep Example -i -A 2 -B 3
pkcs11:id=%ff%f9%eb%97%be%21[...]%e9;type=cert
type: certificate
label: EXAMPLE Secure Certification Authority 1
trust: anchor
Category: authority
pkcs11:id=%ff%9f%88%df%a1%cd%2c%[...]%4b;type=cert
Type: certificate
Label: EXAMPLE Global Root Certification Authority
Trust: anchor
Category: authority
Defining an untrusted CA
Limiting trust to only what is required is a longstanding good security practice. The ca-certificates
package provides a method to reject a CA by placing it in /etc/pki/ca-trust/source/blacklist/
.
Be careful in what you mark as untrusted. Don't blindly reject all CAs without first considering what's required in your environment. You can verify a CA with the openssl
command:
$ openssl s_client -connect example.com:443
[ Download now: A sysadmin's guide to Bash scripting. ]
In organizations that dictate strict security policies, you may want to cut up the default security bundle, /etc/pki/tls/certs/ca-bundle.crt
, and block the use of CAs you don't require. You can split the bundle into individual certificates with the csplit
command:
-
Cut bundle into individual files:
$ csplit -z ca-bundle.crt /#/ '{*}'
-
Remove blank lines:
$ sed -i '/^$/d' xx*
-
Rename files:
$ for file in xx*; do mv $file $(head -n 1 $file | tr -d \#" "); done
You can then move any of the individual certificates into the /etc/pki/ca-trust/source/blacklist/
directory.
When you add something to either the blacklist
or whitelist
directories, you must update the trust list:
$ update-ca-trust
To verify the trust status:
$ trust list --filter=ca-anchors | grep Example -i -A 2 -B 3
pkcs11:id=%ff%22%0b%82%99%24%01%[...]%2a;type=cert
type: certificate
label: Example RootCA 2015
trust: blacklisted
category: authority
For more information about CA trust lists, read Red Hat Enterprise Linux root certificate authority frequently asked questions.