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 RHEL, 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:
Trust anchors belong to
Distrusted certificates are stored in
Certificates in the extended BEGIN TRUSTED file format are located in
In a hierarchical cryptographic system, a trust anchor is an authoritative entity that other parties consider 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
Even though the Firefox browser can use an added certificate without a prior execution of
update-ca-trust, enter the
update-ca-trust command after every CA change. Also note that browsers, such as Firefox, Chromium, and GNOME Web cache files, and you might have to clear your browser’s cache or restart your browser to load the current system certificate 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 ...