Debian Letsencrypt

Introduction

Letsencrypt bietet kostenloase SSL-Zertifikate, die von allen gängigen Webbrowsern und Emailprogrammen akzeptiert werden, da diese dem Letsencrypt Root Zertifikat vertrauen. Es ist erforderlich, ein Root Zertifikat manuell einzubinden. So lange die Domain zum Zertifikat passt, sollten keinerel Zertifikat Warnungen erscheinen. Die Zertifikate sind 90 Tage gültig und müssen dann erneuert werden. Mittels DNS-Validierung können auch Wildcard Zertifikate beantrag werden. DNS-Validierung funktioniert nur für DNS-provider, die entsprechende Schnittstellen bieten. Im folgeden wird http-01 Validierung via Web-Port 80 behandelt. Es existieren verschiedene Clients für die Beantragung von Zertifikaten. Certbot ist ein Python-Tool, das auf vielen Plattformen funktioniert und verschiedene Möglichkeiten bietet Zertifikate zu beantragen und zu verlänngern. Die Verlängerung erfolgt mittels Cron-Job vollautomatisch, ohne User-Eingriff.

Installation

apt-get install certbot

Zertifikate generieren

Die Zertifikate und private keys werden unter /etc/letsencrypt abgelegt. Die jeweils aktuell gültigen Zertifikate und keys werden im Subdirectory live/subdomain.domain.org abgelegt. . Fullchain.pem enthält das Server- und zusätzlich die Letsencrypt Intermediate Zertifikate, damit der Server die Gültigkeit des Zertifikats prüfen kann. cert.pem ist das reine Server Zertifikat und chain.pem enthält die Letsencrypt Intermediate Zertifikate. Je nach Server-SW ist das fullchain.pem oder cert.pem+chain.pem erforderlich. privkey.pem enthält den Private key. Im Unterordner archive sind alle Zertifikate abgelegt. Neben dem aktuellen auch alle abgelaufenen.

Standalone-Mode

Certbot bringt einen einfachen Webserver mit, der auf Port 80 lauschen kann, um die Validierungsanfrage von Letscrypt zu beantworten. Dies funktioniert nur, wenn kein Webserver auf Port 80 läuft. Es wird ein Zertifikat generiert, das in jedem SSL/TLS fähigen Server verwendet werden kann.

certbot --standalone --preferred-challenges http -d subdomain.domain.org

Zertifikat für Webserver

Falls ein Webserver auf Port80 läuft, wird ein Zertifikat folgendermaßen beantragt:

certbot --certonly --preferred-challenges http --webroot -w /var/www -d subdomain.domain.org

Hinweis:

der Pfad für den Webroot (hinter -w) muss evtl. angepasst werden. Der Webroot wird bestimmt durch die Konfiguration des Webservers, der auf Port 80 lauscht. Für Apache ist dies der Parameter DocRoot im entsprechenden VirtualHost. Evtl. wurde ein Konfigfile für letsencrypt unter /etc/apache2/conf-enabled/letsencrypt.conf angelegt. Darin ist dann ein Alisas für den Certbot acme-challenge Ordner aufgeführt. z.B. Alias /.well-known/acme-challenge /var/www/.well-known/acme-challenge Der Webroot ist der Pfad vor .well-known. in diesem Fall /var/www.

Zertifikat für Serverdienst auf anderem Host als der Webserver

In diesem Fall könnte ein Zertifikat wie unter Standalone beschrieben generiert werden und manuell auf den Zielserver (z.B. Mailserver) übertragen werden. Nachdem die Zertifikate lediglich 90 Tage gültig sind, müsste dies auch nach jeder automaitschen Verlängerung passieren. Als Abhilfe könnte ein Script erstellt werden, das dieses automatisch erledigt, die Zertifikate auf einem Netzwerk-Share (z.B. NFS-Share) abgelegt werden, oder auf folgede Art und Weise auf dem Zielserver selbst generiert werden. Der "Trick" besteht darin, dass die http:// acme-challenge auf Port 80 vom Webserver auf den Zielserver per Reverse-Proxy weitergeleitet wird. Auf dem Zielserver kann dann certbot ganz normal im Standalone-Mode, oder falls auf diesem ebenfalls ein Webserver läuft, mittels webroot generiert werden.

Auf dem Webserver einen Reverse-Proxy für z.B. mail.domain.org anlegen. In Beispiel wird ein Proxy angelegt, mit dem Zertifikate für den Mailserver mit der Ip-Adresse IP_des_Mailserver für die subdomains mail, smtp und imap.domain.org angelet werden können. Evtl. mehr oder weniger ServerAlias-Einträge vornehmen.

vi /etc/apache2/sites-available/mail-letsencrypt.conf

Folgende Zeilen einfügen:

  ServerName mail.domain.org
  ServerAlias smtp.domain.org
  ServerAlias imap.domain.org

  ProxyPreserveHost On
  ProxyPass "/" "http://IP_des_Mailserver:80/"
  ProxyPassReverse "/" "http://IP_des_Mailserver:80/"
</VirtualHost>

Falls ein Letsencrypt Konfigurations-File /etc/apache2/conf.enabled/letsencrypt existiert, dann folgenden Block auskommentieren:

#<IfModule mod_proxy.c>
#        ProxyPass /.well-known/acme-challenge !
#</IfModule>

ansonsten werden die letsencrypt challeges nicht zum Zielserver weitergeleitet.

Wenn allerdings letsencrypt auf dem Webserver selbst für andere https:// Reverse-Proxies Zertifikate beziehen soll, dann muss der auskommentierte Block vor den entpreshenden ProxyPass-Einträgen ergänzt werden.

z.B.

ProxyPass /.well-known/acme-challenge !
ProxyPass / http://Ziel_IP:Zielport/

Damit ist sichergestellt, dass der komplette hppt-Datenverkehr zum Zielserver weitergeleitet wird mit Ausnahme der acme-challenge Abfrage (! - Zeichen am Ende).

Apache neu starten

/etc/init.d/apache2 restart

Zertifikate für mehrere Domains

für alle 3 genannte Fälle können Zertifikate für mehrere Domains bezogen werden. Z.B. für einen Mailserver könten 2 getrennte Zertifikate für Postfix (smtp.domain.org) und Imap-Server (imap.domain.org) oder ein Zertifikat, das beide Fälle abdeckt

certbot --standalone --preferred-challenges http -d smtp.domain.org -d 'imap.domain.org

Zertifkate verlängern und Services neu laden

bei der Installation von certbot wurde ein Cronjob angelegt, der täglich prüft, ob Zertifkate zu verlängern sind und diese bei Fälligeit (2 Wochen vor Gültigkeits Ende) verlängert. Der Cronjob verlängert das Zertifikat, damit dieses dann verwendet wird, muss auch der jeweilige Serverdienst neu gestartet bzw. neu geladen werden, damit diesees auch verwendet wird. Ansonsten würde stur das alte weiterverwendet und die Clients würden sich nach Gültigkeitsende über das abgelaufene Zertifikat beschweren. Zu diesem Zweck stehen die sog. Deploy-Hooks zur Verfügung. Dieser Hook wird nur ausgeführt, wenn ein Zertifikat tatsächlich verlängert wurde (nicht beim täglichen Check). Derartige Deploy Hooks können auf 2 Arten angelegt werden. Entweder bereits beim Request eines Zertifikates mittels des Parameters --deploy-hook, oder als Script im Directory /etc/lets/encrypt/renewal-hooks/deploy z.B. Hook bereits beim Zertifikats Request (funktioniert für Standalone und Webroot-Methode):

certbot --standalone --preferred-challenges http -d subdomain.domain.org --deploy-hook service apache2 reload

Dieser Hook würde Apache nach dem Update des Zertifkates neu laden, um dieses zu verwenden

Mittels Hook-Script können mehrere Services neugestartet werden, oder die Zertifikate auf andere Server verteilt werden, oder ähnliches.:

vi /etc/letsencrypt/renewal-hooks/reload-mailserver

Folgende Zeilen starten Postfix und Cyrus neu

#!/bin/sh
/etc/init.d/postfix reload
/etc/init.d/cyrus2.2 restart

ausführbar machen:

chmod +x /etc/letsencrypt/renewal-hooks/reload-mailserver