This page describes how Debian manages its system-wide store of trusted SSL (or better X.509) certificates, and how a system administrator can tap into this system.
Debian and OpenSSL
A software who uses the OpenSSL library to implement secure communications typically "inherits" from OpenSSL the mechanics how certificates are verified and trusted. Because a lot of software uses OpenSSL, Debian adopts from OpenSSL the way of organizing its store of trusted certificates.
OpenSSL has two sources for trusted certificates:
- A file that contains a concatenated list of trusted certificates in PEM format. This is sometimes also known as the "CA file".
- A folder that contains files with trusted certificates, one certificate per file. This is sometimes also known as the "CA directory".
More details are available on the OpenSSL page, but the above information should suffice for the purposes of how Debian organizes its trust stores.
From the blurb of the package
This package includes PEM files of CA certificates to allow SSL-based applications to check for the authenticity of SSL connections. It includes, among others, certificate authorities used by the Debian infrastructure and those shipped with Mozilla's browsers.
Please note that certificate authorities whose certificates are included in this package are not in any way audited for trustworthiness and RFC 3647 compliance, and that full responsibility to assess them belongs to the local system administrator.
Populating the trust store
The CA certificates provided by the package are stored as .crt files that are located in a folder structure below
This is not the actual system trust store! The following configuration file lists the CA certificates in the above directory, defining for each certificate whether it should be used to populate the system trust store, or not. A certificate that should not be included in the system trust store must be listed with a prefix "!".
This is the program that actually populates the system trust store (and reads the above configuration file to do so):
This update program can be run manually, but usually it is invoked when a new version of the
ca-certificates package is installed on the system. As already stated, the update program populates the system trust store, which is a folder that has the OpenSSL CA directory format. The folder is located here:
The update program also generates a huge single file (bundle) that contains all trusted certificates. This file has the OpenSSL CA file format. It is located here:
General information about the CA directory format can be found on the OpenSSL page. Here is just an example that illustrates the symlink structure:
lrwxrwxrwx 1 root root 57 Nov 18 2012 Swisscom_Root_CA_1.pem -> /usr/share/ca-certificates/mozilla/Swisscom_Root_CA_1.crt lrwxrwxrwx 1 root root 22 Oct 28 21:54 667c66d4.0 -> Swisscom_Root_CA_1.pem
Note: Symlinks for certificates that have vanished from the Debian package are left dangling and should be cleaned out periodically.
From the blurb of the package
This package enables unattended installs of packages that need to create SSL certificates. It is a simple wrapper for OpenSSL's certificate request utility that feeds it with the correct user variables.
Besides this, I have found
ssl-cert to be useful because it demonstrates how the different parts of the certificate management process can be protected on the file system level with a sensible user rights concept.
User rights concept
The user rights concept is this:
- There is a system group
- This group has some limited rights to the directory
osgiliath:~# ls -ld /etc/ssl/private drwx--x--- 2 root ssl-cert 4096 Nov 29 03:16 /etc/ssl/private
- This allows users that belong to the group to read files inside the directory
- Daemons that do not start and/or run as
rootshould have the
ssl-certgroup assigned as a secondary group
- The owner of key files within
/etc/ssl/privatecan be changed to
ssl-cert; the read permission also needs to be changed accordingly:
osgiliath:~# ls -ld /etc/ssl/private/ldap.herzbube.ch.key.unsecure -r--r----- 1 root ssl-cert 887 Jan 10 2004 /etc/ssl/private/ldap.herzbube.ch.key.unsecure
- Unfortunately all daemons that belong to
ssl-certcan now read the key file; it is therefore sensible to further restrict the key file's group:
osgiliath:~# ls -ld /etc/ssl/private/ldap.herzbube.ch.key.unsecure -r--r----- 1 root openldap 887 Jan 10 2004 /etc/ssl/private/ldap.herzbube.ch.key.unsecure
Adding custom certificates into /etc/ssl/certs
A custom CA certificate (i.e. one that is not part of the
ca-certificates package) can be conveniently placed into
and it will be automatically picked up and processed by
update-ca-certificates. The directory should be protected when it is first created to prevent unauthorized users from placing certificates. The permissions should be the same as the package-provided certificate store
chown root:root /usr/local/share/ca-certificates chmod 755 /usr/local/share/ca-certificates
More cumbersome is to do this manually. The CA certificate file can be placed in
/etc/ssl/certs, then the following command should generate the symlink (assuming the subject hash is unique):
ln -s ca.herzbube.ch.crt "$(openssl x509 -subject_hash -in ca.herzbube.ch.crt | head -1).0"
A problem with this approach is that the certificate is not in the system-wide CA file (
/etc/ssl/certs/ca-certificates.crt). It is possible to manually add the certificate, but the change will be lost when
update-ca-certificates is run the next time. There is not much that can be done about this, so the manual approach should be avoided.
/etc/ssl/certs is mainly intended for CA certificates, there is nothing that prevents placing non-CA certificates (typically server certificates) into the same location. Server certificates are handed out by the system's own servers, which means they do not take part in the verification process and therefore do not need to be symlinked.
ca-certificates package is upgraded and the upgrade contains new certificates, or some certificates have been deactivated, then
update-ca-certificates will cause
c_rehash to be run over the
/etc/ssl/certs directory, which will lead to hash symlinks being generated even for my non-CA certificates. These symlinks can be removed if detected, but otherwise they do no harm.