[Eisfair] [E64]: dehydrated: Wechsel zu tls-alpn-01 -> python3 -> invalid challenge

[Rolf Bensch]

Hallo Marcus,

Am 29.05.22 um 11:33 schrieb Marcus Röckrath:

> Hallo Rolf,
> 
> Rolf Bensch wrote:
> 
>> wegen anhaltender Probleme beim Letsencrypt-Zertifikat-Update über eine
>> Fritzbox möchte ich von https-01 nach tls-alpn-01-challenge wechseln.
>> Dabei treten 2 Probleme auf.
>>
>> 1. über das Konfig-Menü wurde einfach DEHYDRATED_CHALLENGE_TYPE nach
>> tls-alpn-01 umgestellt und die Konfig wurde gespeichert. Danach wurde
>> angemeckert, dass das Paket python3 fehlt. Ich betätigte die Rückfrage zur
>> Installation mit yes, weiteres flimmerte über den Bildschirm, das Update
>> der Challenge verlief mit Fehler. Ich öffnete erneut die Konfig, suchte
>> nach Fehlern, fand aber keine. Wieder speichern der Konfig -> erneut die
>> Warnung dass pathon3 fehlt. Package-Administration bestatigte, dass das
>> Paket (jetzt 2x) nicht installiert wurde. Ich installierte manuell, das
>> funktioniert tadellos.
> 
> Bei python3 haben sich größere Änderungen ergeben, über die sich besser
> Holger äußern kann.
> 
> Nur soviel: Es gibt inzwischen python38 und python310; python3 ist nur noch
> ein Pseudopaket für Pakete, denen egal ist, ob sie python38 und python310
> vorfinden.
> 
> Welches python ist bei dir auf der Kiste?

bisher nur python2 (mit diversen Modulen). Wie geschrieben, hatte ich manuell python3 nachinstalliert, damit kamen jetzt mehrere python38-Pakete ins System.

> 
>> 2. Dennoch schlägt weiterhin die Challenge fehl. Ich finde in der Konfig
>> in startup_hook den Parameter --start-alpn-server. Für mich
>> gleichbedeutend, dass hier ein weiterer Webserver gestartet werden soll.
>> Bei den bisher fehlgeschlagenen Tests sollte die Challenge über Port 443
>> laufen. Es läuft bereits ein Apache auf Port 443, weshalb ich
>> DEHYDRATED_ALPN_LISTEN_PORT auf Port 444 setzte und in der Fritzbox den
>> Port öffnete. Die Challenge funktioniert trotzdem nicht:
>>
>> Auffallend hier: "listen_Port" ist korrekt auf 444 gesetzt,
>> "validationRecord" läuft weiterhin auf Port 443.
> 
> Zum Verständnis:
> 
> Du musst natürlich den alpn-Server auf einen anderen als den Port 443 legen.

Das dachte ich mir.


> Der entfernte letsencrypt-Server benutzt aber natürlich weiterhin den Port
> 443 für seine Anfrage, die somit weiterhin beim Apachen landet.
> 
> Hier eine Beschreibung aus einem älteren Thread:
> https://groups.google.com/g/spline.eisfair/c/iAxr0c7AgBI/
> 
> ----------------- Zitat ------------------------------------------------
> Der ALPN-Responder-Dienst ist ein eigener Dienst, der natürlich lokal nicht
> auf dem https-Port des Apachen laufen darf - zwei Dienste auf gleichem Port
> geht nicht.
> 
> Benutzt man also einen lokalen Webserver auf dem Port 443, muss man
> DEHYDRATED_ALPN_LISTEN_PORT auf einen anderen freien Port setzen z. B.
> 8443 ...
> 
> Im Router ist dann der Port 443 nach intern 8443 weiterzuleiten.

wodurch der Apache während des Updates nicht mehr erreichbar ist.

> Falls natürlich im Regelfall eine Weiterleitung von 443 an den internen
> Webserver gewünscht ist, müsste man nun folgende Schritte über die Hooks
> auf dem Router realisieren:
> 
> 1. Löschen der Weiterleitung des 443 an den internen Webserver
> 2. Anlegen der Weiterleitung des 443 an den ALPN-Responder-Port

wenn hier wieder auf der Fritzbox die Portweiterleitung modifiziert werden müssen, bringt das gegenüber http-01 keinen Vorteil. Bisher wurde Port 80 nur während des Letsencrypt-Update geöffnet, über Port 443 war der Apache aber (bis auf den Neustart) unterbrechungsfrei erreichbar.

Irgendwie ist da kein Licht am Horizont :-(

Grüße

Rolf