Certmonger, in combination with FreeIPA is very handy for automatic management of TLS server certificates, if a little sparsely documented.

If you're using it with something like Apache httpd, which starts as root, reads its config/certificates/keys and then changes to a non-root user to process requests, then it all works very well out of the box.

It can be trickier to get other, less 'mature' services to consume its certificates, however. For instance, I ran into trouble when configuring iRODS to make use if Certmonger-managed certificates:

  1. Certmonger's certificate files are owned by and only readable by root; the irods user cannot read them

  2. Certmonger writues the server certificate and the CA certificate to separate files; iRODS wants them in a single combined chain.pem file

  3. iRODS can't be told to reload its configuration and/or certificates without restarting

As best I can tell, we must use a post-save command to change the owner/group/mode of the certificate files after Certmonger has created them. In addition, the command can combine the server certificate with the intermediate CA certificate to create a certificate chain file for iRODS to consume. As for reloading, there's only so much Certmonger can help us with :)

My first attempt was to do this as a one-liner by modifying the certificate tracking entry:

That's pretty ugly, but more importantly, it doesn't work!

The reason is because SELinux policy prevents Certmonger from monkeying around with the files in /etc/irods. This can be seen with:

i.e., certmonger_t can't remove the old /etc/irods/server.key before installing the new one.

I initially used semanage fcontext -a to set the context of server.key and chain.pem to cert_t; but the policy still prevented the file from being unlinked. That is because it lives in /etc/irods which has the etc_t context. Rather than overriding the context of that directory, I tried creating a dedicated /etc/irods/tls directory to contain both server.key and chain.pem inside it. The directory and all its files had the cert_t context.

The next hurdle was:

This time, the policy prevents certmonger_t from changing the owner of the file.

I wanted to avoid having to write an SELinux policy module to e.g., create a irods_cert_t domain and allow certmonger_t to change the ownership of files with it. And even if I did, I'd still probably have to figure out how to grant certmonger_t the ability to restart iRODS, so I looked for alternatives.

Reading the man page for certmonger_selinux revealed the existence of the certmonger_unconfined_t domain. Based on its name it sounds like it would allow a process to run unconfined, which is reasonably secure for the short and simple script which we're about to write. This domain can be entered be executing a file with the certmonger_unconfined_exec_t context.

I created a script, /etc/irods/tls-post-save.sh:

I changed the context of the script to certmonger_unconfined_exec_t and updated the tracking request to use it:


Thanks to a helpful comment on Red Hat's Bugzilla has lots of useful commands for exploring the active SELinux policy and determine exactly what certmonger_t is allowed to do.


robots.org.uk: CertmongerSELinux (last edited 2019-12-19 09:58:49 by sam)

© Sam Morris <sam@robots.org.uk>.
Content may be distributed and modified providing this notice is preserved.