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 
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,
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 
paresy
Hab ich mir fast gedacht 
ich schau mal, ob ich da durchsteige 
viele grüsse
Does this module still work? I couldn’t get the Let’s Encrypt module to fetch a SSL certifcate and assign it to a webserver instance.
Dennis.
Sometimes you need to update twice before you get the certificate.
And you need to restart IP-Symcon to get the certificate loaded.
paresy
I gave up and bought a certicate. The Let’s Encrypt module just gave an error when I tried to fetch a certificate.
Man sollte ggf die Doku des Moduls dahingehend ergänzen, dass man aus der webserverinstanz vorher ein eventuell vorhandenes selfcert zertifikat rauslöscht.
Denn wenn man das nicht macht, lädt das Modul auch nicht das lets encrypt Zertifikat rein und das Ganze funktioniert nicht.
Es gibt leider auch keine Fehlermeldung oder Hinweis dazu. Habe ich dann nur zufällig durch ausprobieren herausgefunden.
Was ich aber nicht gelöst bekommen habe, ist dass die console über /console im externen Zugriff OHNE passwortabfrage aufgerufen werden kann. Via Systray habe ich natürlich den Fernzugriff deaktiviert.
Die webfronts zeigen schön die passwortabfrage. Aber was nützt mir das, wenn jemand über die console alles ändern kann…
Jemand eine Idee, warum das so ist?
Habe natürlich die Ports erstmal wieder zugemacht…
Die Portweiterleitung geht hier über mehrere Etappen intern. Also nicht direkt vom Inrernetrouter, dazwischen sind noch zwei weitere firewalls die das Port mappen
Ich komme bzgl. der Erneuerung des Zertifikates hier auch nicht ans Ziel. Das schlägt fehl.
Hat jemand das gleiche Problem?
Solange ich IP-Symcon zum neuladen des Zertifikats neustarten muss, schaue ich mir das Modul nicht an. Finde ich etwas schade, denn Potenzial hätte es.
Mit welcher Fehlermeldung schlägt es fehl? Ohne mir das Modul genauer angesehen zu haben, zeitweise (beim ersten mal?, immer?) nutzt Lets-Encrypt zwangsweise Port 80 ohne SSL zur Überprüfung.
Genau war dort lag das Problem. Habe das Problem gestern Abend noch lösen können, indem ich in den Debug des Moduls geschaut habe. Es wird eine unverschlüsselte Verbindung über Port 80 aufgebaut, um das Zertifikat zu verlängern. Diese lasse ich natürlich nicht zu.
Ist natürlich ein riesiger Akt, jedes Mal die Verschlüsselung zu deaktivieren, zu verlängern, Verschlüsselung wieder aktivieren. Dazwischen gefühlt 8 Mal den Dienst neu starten. Alles nicht so flüssig.
Das in Arbeitszeit umgerechnet, da ist es „echtes“ Zertifikat vermutlich günstiger.