SSLCertificatesOnDebian

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.

The package ca-certificates

Overview

From the blurb of the package ca-certificates:

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

/usr/share/ca-certificates

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 "!".

/etc/ca-certificates.conf

This is the program that actually populates the system trust store (and reads the above configuration file to do so):

update-ca-certificates

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:

/etc/ssl/certs

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:

/etc/ssl/certs/ca-certificates.crt

Content of /etc/ssl/certs

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.

The package ssl-cert

Overview

From the blurb of the package ssl-cert:

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 ssl-cert
• This group has some limited rights to the directory /etc/ssl/private

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 root should have the ssl-cert group assigned as a secondary group
• The owner of key files within /etc/ssl/private can 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-cert can 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

CA certificates

A custom CA certificate (i.e. one that is not part of the ca-certificates package) can be conveniently placed into

/usr/local/share/ca-certificates

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 /usr/share/ca-certificates:

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.

Non-CA certificates

Although /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.

When the 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.