Chapter 4. Using shared system certificates
The shared system certificates storage enables NSS, GnuTLS, OpenSSL, and Java to share a default source for retrieving system certificate anchors and block-list information. By default, the trust store contains the Mozilla CA list, including positive and negative trust. The system allows updating the core Mozilla CA list or choosing another certificate list.
4.1. The system-wide trust store
In Red Hat Enterprise Linux, the consolidated system-wide trust store is located in the
/usr/share/pki/ca-trust-source/ directories. The trust settings in
/usr/share/pki/ca-trust-source/ are processed with lower priority than settings in
Certificate files are treated depending on the subdirectory they are installed to the following directories:
for trust anchors
for distrusted certificates
for certificates in the extended BEGIN TRUSTED file format
In a hierarchical cryptographic system, a trust anchor is an authoritative entity which other parties consider being trustworthy. In the X.509 architecture, a root certificate is a trust anchor from which a chain of trust is derived. To enable chain validation, the trusting party must have access to the trust anchor first.
4.2. Adding new certificates
To acknowledge applications on your system with a new source of trust, add the corresponding certificate to the system-wide store, and use the
ca-certificatespackage is present on the system.
To add a certificate in the simple PEM or DER file formats to the list of CAs trusted on the system, copy the certificate file to the
/etc/pki/ca-trust/source/anchors/directory, for example:
# cp ~/certificate-trust-examples/Cert-trust-test-ca.pem /usr/share/pki/ca-trust-source/anchors/
To update the system-wide trust store configuration, use the
While the Firefox browser is able to use an added certificate without executing
update-ca-trust, Red Hat recommends to use the
update-ca-trust command after a CA change. Also note that browsers, such as Firefox, Epiphany, or Chromium, cache files, and you might have to clear browser’s cache or restart your browser to load the current system certificates configuration.
4.3. Managing trusted system certificates
trust command provides a convenient way for managing certificates in the shared system-wide trust store.
To list, extract, add, remove, or change trust anchors, use the
trustcommand. To see the built-in help for this command, enter it without any arguments or with the
$ trust usage: trust command <args>... Common trust commands are: list List trust or certificates extract Extract certificates and trust extract-compat Extract trust compatibility bundles anchor Add, remove, change trust anchors dump Dump trust objects in internal format See 'trust <command> --help' for more information
To list all system trust anchors and certificates, use the
$ trust list pkcs11:id=%d2%87%b4%e3%df%37%27%93%55%f6%56%ea%81%e5%36%cc%8c%1e%3f%bd;type=cert type: certificate label: ACCVRAIZ1 trust: anchor category: authority pkcs11:id=%a6%b3%e1%2b%2b%49%b6%d7%73%a1%aa%94%f5%01%e7%73%65%4c%ac%50;type=cert type: certificate label: ACEDICOM Root trust: anchor category: authority ...
To store a trust anchor into the system-wide trust store, use the
trust anchorsub-command and specify a path to a certificate. Replace path.to/certificate.crt by a path to your certificate and its file name:
# trust anchor path.to/certificate.crt
To remove a certificate, use either a path to a certificate or an ID of a certificate:
# trust anchor --remove path.to/certificate.crt # trust anchor --remove "pkcs11:id=%AA%BB%CC%DD%EE;type=cert"
All sub-commands of the
trustcommands offer a detailed built-in help, for example:
$ trust list --help usage: trust list --filter=<what> --filter=<what> filter of what to export ca-anchors certificate anchors ... --purpose=<usage> limit to certificates usable for the purpose server-auth for authenticating servers ...
4.4. Additional resources