Quelltext der Seite Lets Encrypt Zertifikate erneuern mit Apache Reverse Proxy

[[Kategorie:Apache2]]
[[Kategorie:ISPConfig]]
[[Kategorie:Reverse_Proxy]]
==Problem und Ursache==
Ich nutze - weil ich faul bin - ISPConfig in der Version 3.1 um neue Domänen und Subdomänen zu erstellen.<br>
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.<br>
<br>
Tja, leider mache ich wohl wieder viel anderes als andere - insbesondere nutze ich intensiv die Funktion des Apache Reverse Proxy.<br>
Praktisch jedes Gerät hat heute eine Weboberfläche für die Konfiguration.<br>
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.<br>
<br>
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.<br>
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.<br>
<br>
----
==Hinweis==
{{Hinweis|Ene Lösung für <code>acme.sh</code> habe ich ebenfalls angefügt}}<br>
Ich installieren den <code>certbot</code> immer direkt von
 https://github.com/certbot/certbot
sonst heißt der Befehl nicht '''''certbot-auto''''' sondern nur '''''certbot'''''<br>
<br>
 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.<br>
<br>
----

==Lösung certbot==
Die Lösung ist einfach: zu irgendeiner nachtschlafenden Zeit wird der Apache2 angehalten, die Zertifikate über den im <code>certbot-auto</code> eingebauten Webserver erneuert und der Apache wieder gestartet.<br>
<br>
<u>'''Test (Ubuntu 16.04.x):'''</u><br>
 /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 <code>--dry-run</code> nur als Test.<br>
<br>
Er findet alle vorhandenen Zertifikate und testet deren Erneuerung.<br>
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.<br>
<br>
Damit kann die ganze Zeile also so in einen Cronjob:<br>
 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.<br>
Wer nur eine Mail bei Fehlern haben möchte ergänzt den Aufruf um ein
 -q
am Ende, das Unterdrückt alle sonstigen Meldungen.<br>
{{Hinweis| Den Start und Stop Befehl für den Webserver müsst Ihr ggf. Anpassen, unter Ubuntu 14.04.x wäre es zum Beispiel <code>service apache2 stop</code> und <code>service apache2 start</code>}}
<br>
----
==Lösung acme.sh==
 /root/.acme.sh/acme.sh --cron --home /root/.acme.sh --standalone --pre-hook "systemctl stop apache2.service" --post-hook "systemctl start apache2.service"
Einen Schalter <code>-q<code> scheint es nicht zu geben, also:<br>
 /root/.acme.sh/acme.sh --cron --home /root/.acme.sh --standalone --pre-hook "systemctl stop apache2.service" --post-hook "systemctl start apache2.service" 2>&1 >/dev/null

----

==Auf Port 80 beschränken==
Nun wurde es bei einer meiner Subdomänen noch komplizierter:<br>
* 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 <code>certbot-auto</code> in der aktuellen Version versucht es immer über https, un der zeigt nun einmal auf den falschen Port für diese Domäne.<br>
Die Lösung stand - wieder einmal - in der Hilfe zu dem Projekt: https://certbot.eff.org/docs/using.html<br>
Mit dem Parameter<br>
 --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"
<br>
----

==Zertifikat manuell anfordern==
 /opt/certbot/certbot-auto certonly --standalone --preferred-challenges http --rsa-key-size 4096 -d git.znil.net
<br>
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
----

==Kommentare==
<comments />