Hallo,
ich habe von der alten Landingpage ohne Docker auf die Neue im Docker umgestellt.
Jetzt sollte das für mehrere Subdomains geltende Let’s Encrypt Zertifikat erneuert werden. Leider schlägt das für die Subdomain der Landingpage (intranet.afs-engen.de) fehl.
Da wie gesagt mehrere Subdomain in einem Zertifikat (server.afs-engen.de) zusammengefasst sind, wäre damit nach Ablauf der Gültigkeit des Zertifikats auch kein anderer Dienst mehr per SSL erreichbar.
Ich habe nun das Zertifikat für die Subdomain der Landingpage von den Subdomains der anderen Dienste getrennt: intranet.afs-engen.de
Das löst aber nicht das Problem für die Erreichbarkeit der Landingpage, da das Erstellen dieses Zertifikats zur Subdomain intranet.afs-engen.de weiter fehl schlägt:
/usr/bin/dehydrated -c
# INFO: Using main config file /etc/dehydrated/config
Processing intranet.afs-engen.de
+ Creating new directory /etc/dehydrated/certs/intranet.afs-engen.de ...
+ Signing domains...
+ Generating private key...
+ Generating signing request...
+ Requesting new certificate order from CA...
+ Received 1 authorizations URLs from the CA
+ Handling authorization for intranet.afs-engen.de
+ 1 pending challenge(s)
+ Deploying challenge tokens...
+ Responding to challenge for intranet.afs-engen.de authorization...
+ Cleaning challenge tokens...
+ Challenge validation has failed :(
ERROR: Challenge is invalid! (returned: invalid) (result: ["type"] "http-01"
["status"] "invalid"
["error","type"] "urn:ietf:params:acme:error:unauthorized"
["error","detail"] "79.220.161.187: Invalid response from https://intranet.afs-engen.de/links: \" \u003c!DOCTYPE html\u003e\\n \u003chtml\u003e\\n\\n \u003chead\u003e\\n \u003cmeta name=\\\"viewport\\\" content=\\\"width=device-width, initial-scale=1\\\"\u003e\\n\\n \u003c!-\""
["error","status"] 403
["error"] {"type":"urn:ietf:params:acme:error:unauthorized","detail":"79.220.161.187: Invalid response from https://intranet.afs-engen.de/links: \" \u003c!DOCTYPE html\u003e\\n \u003chtml\u003e\\n\\n \u003chead\u003e\\n \u003cmeta name=\\\"viewport\\\" content=\\\"width=device-width, initial-scale=1\\\"\u003e\\n\\n \u003c!-\"","status":403}
["url"] "https://acme-v02.api.letsencrypt.org/acme/chall-v3/247901297067/eqMyRg"
["token"] "lyVR3GeHf4NtCoCeZVihFLRmpQ_dY06D88nGXYNQhck"
["validationRecord",0,"url"] "http://intranet.afs-engen.de/.well-known/acme-challenge/lyVR3GeHf4NtCoCeZVihFLRmpQ_dY06D88nGXYNQhck"
["validationRecord",0,"hostname"] "intranet.afs-engen.de"
["validationRecord",0,"port"] "80"
["validationRecord",0,"addressesResolved",0] "79.220.161.187"
["validationRecord",0,"addressesResolved"] ["79.220.161.187"]
["validationRecord",0,"addressUsed"] "79.220.161.187"
["validationRecord",0] {"url":"http://intranet.afs-engen.de/.well-known/acme-challenge/lyVR3GeHf4NtCoCeZVihFLRmpQ_dY06D88nGXYNQhck","hostname":"intranet.afs-engen.de","port":"80","addressesResolved":["79.220.161.187"],"addressUsed":"79.220.161.187"}
["validationRecord",1,"url"] "https://intranet.afs-engen.de/"
["validationRecord",1,"hostname"] "intranet.afs-engen.de"
["validationRecord",1,"port"] "443"
["validationRecord",1,"addressesResolved",0] "79.220.161.187"
["validationRecord",1,"addressesResolved"] ["79.220.161.187"]
["validationRecord",1,"addressUsed"] "79.220.161.187"
["validationRecord",1] {"url":"https://intranet.afs-engen.de/","hostname":"intranet.afs-engen.de","port":"443","addressesResolved":["79.220.161.187"],"addressUsed":"79.220.161.187"}
["validationRecord",2,"url"] "https://intranet.afs-engen.de/links"
["validationRecord",2,"hostname"] "intranet.afs-engen.de"
["validationRecord",2,"port"] "443"
["validationRecord",2,"addressesResolved",0] "79.220.161.187"
["validationRecord",2,"addressesResolved"] ["79.220.161.187"]
["validationRecord",2,"addressUsed"] "79.220.161.187"
["validationRecord",2] {"url":"https://intranet.afs-engen.de/links","hostname":"intranet.afs-engen.de","port":"443","addressesResolved":["79.220.161.187"],"addressUsed":"79.220.161.187"}
["validationRecord"] [{"url":"http://intranet.afs-engen.de/.well-known/acme-challenge/lyVR3GeHf4NtCoCeZVihFLRmpQ_dY06D88nGXYNQhck","hostname":"intranet.afs-engen.de","port":"80","addressesResolved":["79.220.161.187"],"addressUsed":"79.220.161.187"},{"url":"https://intranet.afs-engen.de/","hostname":"intranet.afs-engen.de","port":"443","addressesResolved":["79.220.161.187"],"addressUsed":"79.220.161.187"},{"url":"https://intranet.afs-engen.de/links","hostname":"intranet.afs-engen.de","port":"443","addressesResolved":["79.220.161.187"],"addressUsed":"79.220.161.187"}]
["validated"] "2023-07-22T09:44:25Z")
Es wird ein unvollständiges Zertifikat erstellt. Danach startet der Apache nicht mehr, wenn im virtuellen Host auf das Zertifikat intranet.afs-engen.de verwiesen wird (siehe unten) .
Der virtuelle Host im Apache, um die Landingpage im Docker erreichbar zu machen, ist unter sites-available im Apache angelegt und aktiviert (sites-enabled). Mit dem alten Sammel-Zertifikat server.afs-engen.de (erstellt vor der Umstellung auf Docker) funktioniert das auch. Nur wenn - wie hier dargestellt - das nicht fehlerfrei angelegte neue Zertifikat für intranet.afs-engen.de eingetragen wird, startet der Apache nicht mehr.
<VirtualHost *:80>
ServerName intranet.afs-engen.de
RewriteEngine On
RewriteCond %{HTTPS} off
RewriteRule (.*) https://%{SERVER_NAME}/ [R=307,L]
</VirtualHost>
<VirtualHost *:443>
ServerName intranet.afs-engen.de
ProxyPreserveHost On
ProxyPass / http://127.0.0.1:5080/
ProxyPassReverse / http://127.0.0.1:5080/
SSLEngine on
SSLProxyEngine on
SSLCipherSuite ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-DSS-AES128-GCM-SHA256:kEDH+AESGCM:EC$
SSLCertificateFile /etc/dehydrated/certs/intranet.afs-engen.de/fullchain.pem
SSLCertificateKeyFile /etc/dehydrated/certs/intranet.afs-engen.de/privkey.pem
</VirtualHost>
Ändere ich im virtuellen Host auf das noch gültige Zertifikat für alle Subdomains (server.afs-engen.de), startet der Apache wieder und die Landingpage ist erreichbar.
Lange Rede kurzer Sinn: Seit intranet.afs-engen.de auf die Landingpage im Docker verweist, lässt sich das Let’s Encrypt Zertifikat für diese Subdomain nicht mehr anlegen / erneuern.
Leider werde ich aus den Fehlermeldungen trotz der Suchmaschine meines Vertrauens nicht so schlau, dass ich herausfinde, warum die Erstellung des Zertifikats fehlschlägt.
Daher hoffe ich mal wieder auf das geballte Wissen und die Schwarmintelligenz hier.
Viele Grüße
Steffen