da unser www.webfront.info Zertifikat Morgen abgelaufen wäre, habe ich endlich geschafft ein Let’s Encrypt Modul zu zaubern. Es ist eher ein Proof of Concept ob es geht… aber zum ersten Testen allemal gut geeignet. Ihr benötigt IP-Symcon 5.5, eine Domain die auf euer IP-Symcon zeigt (Port 80 gemappt auf 3777 für Non-SSL und Port 443 für SSL mit einer Web-Server Instanz, welche SSL aktiv hat).
[ul]
[li]IP-Symcon muss nach einer Aktualisierung vom Zertifikat manuell neu gestartet werden[/li][li]Das Zertifikat muss alle 90 Tage aktualisiert werden[/li][li]Es wird aktuell nur eine Domain unterstützt[/li][/ul]
Ich habe das Modul mal ein wenig modifiziert, sodass du im Debug die URL bekommst, welche Let’s Encrypt aufrufen will. Kannst du diese korrekt aufrufen?
Denn ein 0 Status Code klingt eher so, als wenn gar kein korrektes HTTP auf den Port anliegt. Ansonsten hätte ich eher ein 404 oder ähnliches erwartet.
Bekomme bei „Neues Zertifikat anfordern“ folgende Fehlermeldung:
<br />
<b>Fatal error</b>: Uncaught Rogierw\RwAcme\Exceptions\DomainValidationException: The local HTTP challenge test for ips.domain.com received an invalid response with a 406 status code. in /var/lib/symcon/modules/LetsEncrypt/libs/vendor/rogierw/rw-acme-client/src/Exceptions/DomainValidationException.php:16
Stack trace:
#0 /var/lib/symcon/modules/LetsEncrypt/libs/vendor/rogierw/rw-acme-client/src/Support/LocalChallengeTest.php(20): Rogierw\RwAcme\Exceptions\DomainValidationException::localHttpChallengeTestFailed('ips.paeper.com', '406')
#1 /var/lib/symcon/modules/LetsEncrypt/libs/vendor/rogierw/rw-acme-client/src/Endpoints/DomainValidation.php(73): Rogierw\RwAcme\Support\LocalChallengeTest::http('ips.domain.com', 'Sr-O1a-Pl6yVHMc...', 'Sr-O1a-Pl6yVHMc...')
#2 /var/lib/symcon/modules/LetsEncrypt/LetsEncrypt/module.php(73): Rogierw\RwAcme\Endpoints\DomainValidation->start(Object(Rogierw\RwAcme\DTO\AccountData), Object(Rogierw\RwAcme\DTO\DomainValidationData))
#3 /var/lib/symcon/scripts/__generated.inc.php(9271): LetsEncrypt->FetchCer in <b>/var/lib/symcon/modules/LetsEncrypt/libs/vendor/rogierw/rw-acme-client/src/Exceptions/DomainValidationException.php</b> on line <b>16</b><br />
Der Link den du mir geschickst hast sieht gut aus… Da kommt ein sauberes 200 OK. Es wundert mich, dass Let’s Encrypt ein 301 (was eine Weiterleitung ist) erkennt. Ich wüsste nicht, woher die kommen könnte/sollte.
Der 301 kam von der Firewall -> DNS rebind attack (Da ich versuche den internen Webserver quasi über das WAN mit externer URL wieder aufzurufen).
Zweites Problem war NAT Reflection. Die muss auf der FW eingeschaltet sein, um den internen Web Server aus dem LAN übers WAN zu erreichen.
Drittes Problem war die Webserver Instanz im Modul: Hier hatte ich die SSL Instanz angegeben. Die Default-Instanz auf Port 3777 kann ich nicht angeben, die ist ja quasi mittlerweile versteckt als default im System drin. Letsencrypt versucht auf Port 80 eine Verbindung aufzubauen, also über http. Ich hatte in meiner Firewall einen Portforward von 80 -> 3777 eingerichtet, ging trotzdem nicht. Habe testweise einmal eine extra Webserver Instanz auf Port 80 eingerichtet und das LE Modul darauf verweisen lassen. Dann ging es plötzlich ein Stück weiter. Aber:
<br /><b>Warning</b>: Illegal string offset 'newNonce' in <b>C:\ProgramData\Symcon\modules\LetsEncrypt\libs\vendor\rogierw\rw-acme-client\src\Endpoints\Directory.php</b> on line <b>16</b><br /><br /><b>Notice</b>: Uninitialized string offset: 0 in <b>C:\ProgramData\Symcon\modules\LetsEncrypt\libs\vendor\rogierw\rw-acme-client\src\Endpoints\Directory.php</b> on line <b>16</b><br /><br /><b>Notice</b>: Undefined index: Replay-Nonce in <b>C:\ProgramData\Symcon\modules\LetsEncrypt\libs\vendor\rogierw\rw-acme-client\src\Endpoints\Nonce.php</b> on line <b>13</b><br />
Im Debug ist der letzte Eintrag: Begin Private Key
So, bei mir läuft es jetzt. War eine Mischung aus FW settings und DNS settings, bzw. DNS Auflösungen im cache.
Renewed sich das Zertifikat automatisch?
Leider nein - bisher musst du dies alle 3 Monate per Hand machen und auch IP-Symcon danach neu starten.
Du kannst aber per Ereignis die LE_FetchCertificate Funktion einmal im Monat aufrufen und regemäßig IP-Symcon Updates machen wodurch der Dienst ja neu gestartet wird
häufig sind die Ports 80 und 443 bereits in irgend einer Form in Verwendung. Daher gestaltet sich Generierung eines Zertifikats für einen Symcon Server hinter einer Firewall mittels der HTTP-01 Challenge Methode in diesen Fällen als umständlich, unpraktisch oder unmöglich.
Der DNS-01 Challenge Typ ist da wesentlich einfacher und sehr viele Anbieter unterstützen diese Methode. Damit könnte man Symcon relativ einfach ein Let’s Encrypt Zertifikat verpassen, selbst wenn der Symcon Server von Extern hinter einer Firewall nicht erreichbar sein sollte.
Meiner Einschätzung nach könnten man mit der DNS-1 Challange Methode „fast“ eine Plug & Play Lösung schaffen und Bastelei umgehen.
Nur als ein Vorschlag, falls Du an Deinem Modul irgend wann mal weiter bauen solltest.
Ich wollte mal nachhören ob Ihr nicht lust habt, DNS Challenge hinzuzufügen? Ich würde gerne MQTT per TLS freigeben, da ich dies für eine spezielle Anwendung benötige. Da ich Port 80/443 bereits in Nutzung habe und ich ungern anfangen möchte, einen Reverse proxy zu bauen, wäre der DNS Challenge sehr brauchbar.
Die verwendete Lib von RogierW kann das nicht bzw steht auf der Todo-Liste aber hier ist es implementiert.
Ich befürchte, dass mir dafür schlichtweg die Zeit fehlt. Wenn du jedoch einen PR lieferst (du kannst gerne auf die andere Lib wechseln, sofern die alte Challenge auch geht) dann versuche ich den zeitnah zu reviewen
