Lets Encrypt Zertifikate erneuern mit Apache 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.
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

Hinweis:Ene Lösung für acme.sh habe ich ebenfalls angefügt

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 certbot

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.

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 service apache2 stop und service apache2 start

---

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 -q scheint es nicht zu geben, also:


/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:

• 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

---

Kommentare

Loading comments...