Netz - Rettung - Recht

In der Folge stelle ich die Vorgehensweise ausgehend von einem Debian-Jessie-System aus vor.

Erhalt des Zertifikats

Am einfachsten ist das, wenn unter jedem Hostnamen auch ein Webserver erreichbar ist; dann kann nämlich einfach das webroot-Plugin verwendet werden. Ist das nicht der Fall, kommen bspw. das manual-Plugin oder das external-Plugin in Betracht.

Installation des Zertifikats

Das bereits - für den Webserver - vorhandene oder neu erhaltene Zertifikat und der zugehörige Schlüssel ( Key), die üblicherweise im Verzeichnis /etc/letsencrypt/live/domain.example/ liegen, können nun eingebunden werden - entweder das Zertifikat und die ganze Zertifikatskette mit allen Zwischenzertifikaten zusammen in einer Datei (fullchain.pem), oder das Zertifikat (cert.pem) und die Zwischenzertifikate (chain.pem) getrennt, je nachdem, was die Applikation unterstützt.

Nicht immer ist es aber ohne weiteres möglich, unmittelbar auf die Dateien in /etc/letsencrypt/live/domain.example/ zuzugreifen, die root:root gehören und aufgrund der Verzeichnisrechte auch nur für root lesbar sind. Manche Programme (bspw. der Mailserver Exim) greifen nämlich auf die Zertifikate zu einem Zeitpunkt zu, zu dem sie bereits keine Root-Rechte mehr haben; und es erscheint wenig tunlich, sie in die Gruppe root aufzunehmen oder gar Zertifikat und Key weltweit lesbar zu machen. Andere Programme wiederum haben ausgesprochen strikte Vorstellungen darüber, welchem Benutzer und/oder welcher Gruppe die Dateien “gehören” müssen und wie die Zugriffsrechte auszusehen haben (so z.B. der Newsserver INN, der erwartet, dass der Key ausschließlich für den User news lesbar ist). In diesen Fällen wird es m.E. unausweichlich sein, Kopien der Zertifikate und des Keys mit den passenden Rechten anzulegen.

Dovecot

Der POP3- und IMAP-Server Dovecot greift als root auf die Zertifikate zu und kann - jedenfalls in seiner in Debian Jessie enthaltenen Version 2.2.13 - die Zertifikatskette (fullchain.pem) verarbeiten. Es genügt also, Zertifikat und Key einzubinden und die Serverkonfiguration neu einzulesen (service dovecot reload).

Exim

Anders sieht es mit dem SMTP-Server Exim aus. Dieser gibt seine Root-Rechte auf, bevor er auf die TLS-Zertifikate zugreift. Immerhin kommt auch er mit fullchain.pem klar.

Eine Möglichkeit ist es, Zertifikat und Key in ein passendes Verzeichnis zu kopieren und dann Eigentümer und Rechte (644!) anzupassen, bspw. so:

cd /etc/exim4
mkdir certs 
cp /etc/letsencrypt/live/domain.example/fullchain.pem /etc/exim4/certs/
cp /etc/letsencrypt/live/domain.example/privkey.pem /etc/exim4/certs/
service exim4 restart
chown Debian-exim:Debian-exim /etc/exim4/certs/
chown Debian-exim:Debian-exim /etc/exim4/certs/*
chmod 644 /etc/exim4/certs/*

Ein solches Vorgehen wird dann auch bei jeder Erneuerung der Zertifikate erforderlich (s.u.)!

Danach genügt es, die Serverkonfiguration neu zu laden (service exim4 reload) und sich dann zu Testzwecken auf Port 25 zu verbinden und nach dem EHLO ein STARTTLS abzusetzen.

INN

INN stellt - jedenfalls in der in Debian Jessie enthaltenen Version 2.5.4 - ganz besondere Ansprüche: jedenfalls der Key muss für den Benutzer news lesbar sein, und er benötigt cert.pem und chain.pem getrennt.

Umsetzen könnte man das bspw. so:

cd /etc/news
mkdir certs 
cp /etc/letsencrypt/live/domain.example/cert.pem /etc/news/certs/
cp /etc/letsencrypt/live/domain.example/chain.pem /etc/news/certs/
cp /etc/letsencrypt/live/domain.example/privkey.pem /etc/news/certs/
chown news:news /etc/news/certs/*
chmod 600 /etc/news/certs/*

Auch hier muss man dieses Vorgehen für eine Erneuerung der Zertifikate im Blick behalten (s.u.).

Ein Einlesen der inn.conf später (service inn2 restart) sollte dann alles funktionieren wie geplant.

Zertifikat-Updates

Die nunmehr im Dateisystem verstreuten Zertifikatskopien müssen nach jeder Erneuerung des Zertifikats gleichfalls erneuert werden, damit nicht ein ungültiges Zertifikat ausgeliefert wird. Sinnvollerweise geschieht das ebenso automatisiert wie die Erneuerung des Zertifikats; hilfreich dabei die Möglichkeit, letsencrypt (bzw. certbot) mittels --post-hook nach einem Zertifikatsaustausch ein Script ablaufen zu lassen.

Exim

Man könnte sich daher bspw. eine Datei /usr/local/bin/certbot-exim4-renew.sh mit folgendem Inhalt anlegen:

#!/bin/dash
cp /etc/letsencrypt/live/domain.example/fullchain.pem /etc/exim4/certs/
cp /etc/letsencrypt/live/domain.example/privkey.pem /etc/exim4/certs/
service exim4 reload

Dazu passt dann ein Cron-Eintrag der folgenden Art:

certbot certonly --quiet -n --webroot -w /var/www/domain.example -d domain.example --keep-until-expiring --post-hook /usr/local/bin/certbot-exim4-renew.sh

Damit wird versucht, das Zertifikat für diesen Hostnamen (domain.example) zu erneuern, jedoch nur, wenn es der Erneuerung bedürftig ist.

Der Aufruf sollte in der Crontab zeitlich vor dem allgemeinen Aufruf certbot renew --quiet erfolgen, damit erst das spezielle Zertifikat aktualisiert (und ggf. umkopiert) wird und danach die übrigen.

INN

Für den INN sähe diese Lösung analog mit einer Datei /usr/local/bin/certbot-inn2-renew.sh so aus:

#!/bin/dash
cp /etc/letsencrypt/live/domain.example/cert.pem /etc/news/certs
cp /etc/letsencrypt/live/domain.example/chain.pem /etc/news/certs
cp /etc/letsencrypt/live/domain.example/privkey.pem /etc/news/certs
cd /etc/news/certs
chown news:news *.pem
chmod 600 *.pem
service inn2 reload

Der Cron-Eintrag wäre dann entsprechend:

certbot certonly --quiet -n --webroot -w /var/www/domain.example -d domain.example --keep-until-expiring --post-hook /usr/local/bin/certbot-inn2-renew.sh

Auch dieser Eintrag muss zeitlich vor dem allgemeinen Aufruf certbot renew --quiet liegen.

Und ihr?

So richtig optimal erscheinen mir diese Lösungen noch nicht. Gibt es bessere Ideen? Andere Erfahrungen?

Nutzt ihr letsencrypt noch für andere Dienste als die oben genannten?

An Euren Erfahrungen und Lösungen wäre ich interessiert und freue mich daher über Kommentare, Hinweise und Ergänzungen.