[Modul] Let's Encrypt

Hi Leute,

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).

Link: GitHub - paresy/LetsEncrypt: Modul für IP-Symcon um passende SSL-Zertifikate automatisch zu beantragen

Limitationen

[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]

Das Ergebnis könnt ihr hier begutachten: SSL Server Test: www.webfront.info (Powered by Qualys SSL Labs)

paresy

Hmmmm…läuft bei mir nicht.
Webfront ist von aussen auf Port 80 -> intern 3777 und per https auf 443 (intern und extern) getestet erreichbar.

The local HTTP challenge test for xxx.xxx.de received an invalid response with a 0 status code. in

Letsencrypt Module zeigt auf den angelegten 443 SSL Webserver
Domäne ist eine subdomain aaa.bbb.de

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.

paresy

Im Debug steht als URL nur der directory token.

Also sowas wie:

URL jhLKJHOIULKJH7zi7zggiuzHIHkljHGkJh

Habe nicht gut gearbeitet :rolleyes: Magst du das neuste Update noch einmal testen?

Es sollte auf jeden Fall folgende URL sein:


http://DOMAIN/.well-known/acme-challenge/TOKEN

paresy

Die URL:

http://aaa.bbb.de/.well-known/acme-challenge/4Gxmx242jZX5rPVdjmpQJDjVxPqjkzOmWFPkGwWWRaY

lässt sich aufrufen.

Ergebnis:

4Gxmx242jZX5rPVdjmpQJDjVxPqjkzOmWFPkGwWWRaY.c6ozrf4Nfv4Vj9pBMy5yUEO5QvE4lq2KJhjyN05yHWI

Er liefert als Ergebnis den token, dann einen Punkt und noch einen Token

Der Token ist als Filename (Bis zum RaY) auch im well-known Dir abgelegt. Inhalt so wie oben gezeigt, mit Punkt und Code danach.

Warte mal, Fehler liegt glaube ich bei mir. Asymmetrisches Routing in meiner FW…

Routing passt und URL/Token ist definitv extern erreichbar. DNS nochmals überprüft. Fehler leider immer noch da.

Schick mir mal den vollständigen Link per PM. Dann schaue ich mal, ob ich auch darauf zugreifen kann.

paresy

Hallo Paresy,

spannende Geschichte! Vielen Dank dafür.

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

Joachim

Konntest Du schon schauen?

Bei mir ist es jetzt ein 301…

Neue URL per PN

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.

paresy

So, ich bin ein Stück weiter.

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

paresy

Hallo @paresy,

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.

Danke und Gruß
Dirk

1 „Gefällt mir“

Hi,

@paresy

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.

Viele Grüße

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

paresy

Hab ich mir fast gedacht :face_with_hand_over_mouth:

ich schau mal, ob ich da durchsteige :+1:

viele grüsse