Skip to main content

How to configure your CA trust list in Linux

Add and delete certificate authorities (CAs) from your default trust list to grant networking permissions on a case-by-case basis.
Image
Blue door with lock

Image by Omar González from Pixabay

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:

  1. Cut bundle into individual files:

    $ csplit -z ca-bundle.crt /#/ '{*}'
  2. Remove blank lines:

    $ sed -i '/^$/d' xx*
  3. 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.

Image
Key on a fence
A popular mantra in information security is, "Trust, but verify." Learn how to inspect a web server’s TLS certificate before trusting the site.
Topics:   Security   Networking  
Author’s photo

James Force

James Force is a Senior Consultant at Red Hat. After working in a handful of infrastructure engineering and consulting jobs, James joined Red Hat at the start of 2020. More about me

Try Red Hat Enterprise Linux

Download it at no charge from the Red Hat Developer program.