Lets Encrypt Zertifikate erneuern mit Apache Reverse Proxy
Aus znilwiki
Problem und Ursache
Ich nutze - weil ich faul bin - ISPConfig in der Version 3.1 um neue Domänen und Subdomänen zu erstellen.
Das schöne ist das ISPConfig ab dieser Version das Holen der SSL-Zertifikate von Let's Encrypt direkt mit einbaut hat - man muss nur den Haken in der Konfiguration der Webseite setzen.
Tja, leider mache ich wohl wieder viel anderes als andere - insbesondere nutze ich intensiv die Funktion des Apache Reverse Proxy.
Praktisch jedes Gerät hat heute eine Weboberfläche für die Konfiguration.
Und ich habe für jedes Gerät was ich auch aus der Ferne im Zugriff haben will eine Subdomain erstellt.
Diese hat eine Reverse Proxy Konfiguration und leitet den Datenverkehr - teilweise durch VPN Tunnel - zum eigentlichen Gerät weiter.
Bei der Erstellung einer Subdomain file mir auf das ISPConfig es nicht hinbekommt für diese ein Zertifikat auszustellen wenn der Proxy-Teil schon aktiv ist.
Es wird nämlich versucht über
subdomain.domain.ltd/.well-known/acme-challenge
auf einen Schlüssel zu zugreifen. Bei normalen Webseiten kein Problem, bei Reverse Proxy Seiten kommt dann aber eine Fehlermeldung weil mein AccessPoint damit nichts anfangen kann - und ISPConfig nichts davon weis.
Hinweis
Ich installieren den certbot immer direkt von
https://github.com/certbot/certbot
sonst heißt der Befehl nicht certbot-auto sondern nur certbot
cd /opt git clone https://github.com/certbot/certbot.git /opt/certbot/certbot-auto
Beim ersten mal kommen die Fragen nach Email und der Annahme der Lizenzbedingungen etc.
Lösung
Die Lösung ist einfach: zu irgendeiner nachtschlafenden Zeit wird der Apache2 angehalten, die Zertifikate über den im certbot-auto eingebauten Webserver erneuert und der Apache wieder gestartet.
Test (Ubuntu 16.04.x):
/opt/certbot/certbot-auto renew --standalone --no-self-upgrade --pre-hook "systemctl stop apache2.service" --post-hook "systemctl start apache2.service" --dry-run
führt das ganze aus - dank --dry-run nur als Test.
Er findet alle vorhandenen Zertifikate und testet deren Erneuerung.
Mit den Parametern
--pre-hook "systemctl stop apache2.service" --post-hook "systemctl start apache2.service"
stoppt und startet er den Webserver hierbei bei Bedarf(!). Er schaut also erst ob es etwas zu verlängern gibt - und falls dem so ist, dann stoppt er den Webserver dafür.
Damit kann die ganze Zeile also so in einen Cronjob:
30 5 * * * /opt/certbot/certbot-auto renew --standalone --no-self-upgrade --pre-hook "systemctl stop apache2.service" --post-hook "systemctl start apache2.service"
führt das ganze jeden Morgen um 05:30 Uhr einmal durch. Das Ergebnis bekommt der root als Email.
Wer nur eine Mail bei Fehlern haben möchte ergänzt den Aufruf um ein
-q
am Ende, das Unterdrückt alle sonstigen Meldungen.
service apache2 stop und service apache2 start
Auf Port 80 beschränken
Nun wurde es bei einer meiner Subdomänen noch komplizierter:
- Eigene externe IPv4
- Port 80 extern zeigt auf Port 80 des Webservers. Dort ist eine http-zu-https Weiterleitung hinterlegt
- Port 443 zeigt aber auf Port 3000 des Webservers (gogs-Service)
Bei dem Versuch das Zertifikat zu erneuern läuft es immer auf einen Timeout. Er hält zwar den Apache an - aber certbot-auto in der aktuellen Version versucht es immer über https, un der zeigt nun einmal auf den falschen Port für diese Domäne.
Die Lösung stand - wieder einmal - in der Hilfe zu dem Projekt: https://certbot.eff.org/docs/using.html
Mit dem Parameter
--preferred-challenges http
erzwingt man die Nutzung von schlichten http.
30 5 * * * /opt/certbot/certbot-auto renew --standalone --no-self-upgrade --preferred-challenges http --pre-hook "systemctl stop apache2.service" --post-hook "systemctl start apache2.service"
Zertifikat manuell anfordern
/opt/certbot/certbot-auto certonly --standalone --preferred-challenges http --rsa-key-size 4096 -d git.znil.net
SAN-Zertifikat für Mailserver
/opt/certbot/certbot-auto --standalone --preferred-challenges http --rsa-key-size 4096 -d mail.znil.org -d autodiscover.znil.org