Lets Encrypt Zertifikate erneuern mit Apache Reverse Proxy - Versionsgeschichte

BLinz: /* Lösung acme.sh */

2025-07-08T19:41:28Z

Lösung acme.sh

← Nächstältere Version		Version vom 8. Juli 2025, 21:41 Uhr
Zeile 52:		Zeile 52:
	----		----
	==Lösung acme.sh==		==Lösung acme.sh==
			Mit acme.sh funktioniert das - nicht mehr wie ich meine.<br>
			https://github.com/acmesh-official/acme.sh/wiki/Using-pre-hook-post-hook-renew-hook-reloadcmd
			Die hooks werden nur bei {{code\|issue}} ausgeführt und er speichert sich das dann in einer Conf.
			Beim Renew kann er aber nicht mit {{code\|--standalone}} umgehen. Ich meine das ging mal.
			<br>
			<br>
			'''Funktioniert nicht (mehr)''' Stand Juli 2025
	/root/.acme.sh/acme.sh --cron --home /root/.acme.sh --standalone --pre-hook "systemctl stop apache2.service" --post-hook "systemctl start apache2.service"		/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>		Einen Schalter <code>-q</code> scheint es nicht zu geben, also:<br>

BLinz: /* Lösung acme.sh */

2025-07-08T18:56:42Z

Lösung acme.sh

← Nächstältere Version		Version vom 8. Juli 2025, 20:56 Uhr
Zeile 53:		Zeile 53:
	==Lösung acme.sh==		==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"		/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>		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		/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

BLinz: /* Hinweis */

2023-10-19T19:15:56Z

Hinweis

← Nächstältere Version		Version vom 19. Oktober 2023, 21:15 Uhr
Zeile 18:		Zeile 18:
	----		----
	==Hinweis==		==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		Ich installieren den <code>certbot</code> immer direkt von
	https://github.com/certbot/certbot		https://github.com/certbot/certbot

BLinz: /* Lösung */

2023-10-19T19:15:14Z

Lösung

← Nächstältere Version		Version vom 19. Oktober 2023, 21:15 Uhr
Zeile 29:		Zeile 29:
	----		----

	==Lösung==		==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>		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>		<br>
Zeile 50:		Zeile 50:
	<br>		<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==		==Auf Port 80 beschränken==
	Nun wurde es bei einer meiner Subdomänen noch komplizierter:<br>		Nun wurde es bei einer meiner Subdomänen noch komplizierter:<br>

BLinz: BLinz verschob die Seite Lets Encrypte Zertifikate erneuern mit Apache Reverse Proxy nach Lets Encrypt Zertifikate erneuern mit Apache Reverse Proxy: Textersetzung - „Lets Encrypte Zertifikate erneuern mit Apache Reverse Proxy“ durch „Let…

2021-03-15T14:01:26Z

BLinz verschob die Seite Lets Encrypte Zertifikate erneuern mit Apache Reverse Proxy nach Lets Encrypt Zertifikate erneuern mit Apache Reverse Proxy: Textersetzung - „Lets Encrypte Zertifikate erneuern mit Apache Reverse Proxy“ durch „Let…

← Nächstältere Version	Version vom 15. März 2021, 16:01 Uhr
(kein Unterschied)

BLinz: /* Zertifikat manuell anfordern */

2020-01-17T11:23:14Z

Zertifikat manuell anfordern

Neue Seite

[[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. 
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 <code>certbot</code> 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 <code>certbot-auto</code> 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 <code>--dry-run</code> 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 <code>service apache2 stop</code> und <code>service apache2 start</code>}}
 
----
==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 <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. 
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==
<comments />