• Using a Certificate Revocation List (CRL) with Icinga 2
• Building a Python 3 compatble Debian package for Pynag

Using a Certificate Revocation List (CRL) with Icinga 2

Before you start: There is a bug in Icinga 2 (at least up to version 2.6.2) that prevents a CRL from being loaded, so you have to ensure that you use a newer version or patch the bug yourself.

Icinga 2 makes managing the CA easy by using the icinga2 pki commands. However, it does not provide any commands for generating a CRL. This means that the regular openssl tool needs to be used for that. The functions for generating a CRL are part of the ca module, so one first has to create a CA configuration for OpenSSL. For the rest of this tutorial, we assume that the certificates for Icinga 2 are stored in the default location (/var/lib/icinga2/ca).

First, we create the directory /var/lib/icinga2/ca/crl and a number of files needed in this directory:

Next, we create the configuration file for OpenSSL as /var/lib/icinga2/ca/crl/openssl.cnf:

Finally, we want two shell scripts. One for generating the CRL and one for revoking a certificate.

/var/lib/icinga2/ca/crl/gen-crl.sh:

/var/lib/icinga2/ca/crl/revoke.sh:

Do not forget to make the shell scripts executable:

You might also want to change the owner of these files, though this step is entirely optional:

Now in order to revoke a certificate, you call revoke.sh with the certificate file as the parameter. For example:

After revoking a certificate, you have to regenerate the CRL in order to include the revoked certificate in the CRL:

In order to actually use the CRL, you have to distribute it to the Icinga 2 nodes. How to do this is outside of the scope of this tutorial. One might simply use scp or one could use a configuration management tool like SaltStack.

One thing to consider when distributing the CRL is its validity period: When using a CRL, Icinga 2 will start to reject all certificates (even the ones which have not expired yet and have not been revoked either) when the CRL has expired. This means that a new CRL has to be distributed before the old one expires. Choosing a longer validity period (by changing the crldays and crlhours options in the OpenSSL configuration) might help so that you can distribute the CRL less often. For example, the certificiates generated by Icinga 2 are valid for 5475 days (approximately 15 years). However, in contrast to certificates, there is no way to revoke a CRL. This means that if an attacker got hold of a CRL (which is not unlikely because a CRL is generally considered public information) and found a way to inject that CRL in the distribution process, he might be able to make a node use an old version of the CRL, thus accepting certificates that have been revoked in the meantime. When using a secure channel (like SSH) for distributing the CRL, you might not be worried too much about this scenario.

In order to make Icinga 2 use the CRL, it has to be registered with the API listener. The following configuration (typically stored in /etc/icinga2/features-available/api.conf) assumes that the CRL is stored in /etc/icinga2/pki/crl.pem.

Building a Python 3 compatble Debian package for Pynag

Ubuntu 18.04 includes the python-pynag package, but only for Python 2. There is no python3-pynag package, because the upstream version of Pynag is not compatible with Python 3. Luckily, there is a fork that is compatible with Python 3. The following shell script can be used to build a Debian package of this fork. This package should be compatible with Ubuntu as well.