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

So Mai 29 11:05:57 CEST 2022

Hallo zusammen,

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.

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:

   2022-05-29 09:07:57 - starting dhydrated alpn server ...
   config_file    = /var/certs/dehydrated/dehydrated_alpn_responder.conf

   alpn_path      = /var/certs/dehydrated/alpn-certs
   fallback_cert  = /usr/local/ssl/certs/apache.pem
   fallback_key   = /usr/local/ssl/certs/apache.pem
   host_name      = 0.0.0.0
   listen_port    = 444
   proxy_protocol = False

   starting server ...
   Processing www.my.domain
    + Checking domain name(s) of existing cert... unchanged.
    + Checking expire date of existing cert...
    + Valid till Jun 24 22:13:25 2022 GMT (Less than 30 days). Renewing!
    + Signing domains...
    + Generating private key...
    + Generating signing request...
    + Requesting new certificate order from CA...
    + Received 1 authorizations URLs from the CA
    + Handling authorization for www.my.domain
    + Generating ALPN certificate and key for www.my.domain...
    + 1 pending challenge(s)
    + Deploying challenge tokens...
    + Responding to challenge for www.my.domain authorization...
   -> Executing hook script 'invalid_challenge' ...
   2022-05-29 09:08:05 - invalid challenge warning successfully sent to 'Postmaster <postmaster at bensch-net.de>'.
    + Cleaning challenge tokens...
    + Challenge validation has failed :(
   ERROR: Challenge is invalid! (returned: invalid) (result: ["type"]      "tls-alpn-01"
   ["status"]      "invalid"
   ["error","type"] "urn:ietf:params:acme:error:connection"
   ["error","detail"]      "46.12.34.196: Error getting validation data"
   ["error","status"]      400
   ["error"]       {"type":"urn:ietf:params:acme:error:connection","detail":"46.12.34.196: Error getting validation data","s
   ["url"] "https://acme-v02.api.letsencrypt.org/acme/chall-v3/113747283796/qbxbwg"
   ["token"]       "Hh6BZcHn4eMk7PtQ0PcSXxuLIH0YE1fv8z-v592Cshc"
   ["validationRecord",0,"hostname"]       "www.my.domain"
   ["validationRecord",0,"port"]   "443"
   ["validationRecord",0,"addressesResolved",0]    "46.12.34.196"
   ["validationRecord",0,"addressesResolved"]      ["46.12.34.196"]
   ["validationRecord",0,"addressUsed"]    "46.12.34.196"
   ["validationRecord",0]  {"hostname":"www.my.domain","port":"443","addressesResolved":["46.12.34.196"],"addressUsed"
   ["validationRecord"]    [{"hostname":"www.my.domain","port":"443","addressesResolved":["46.12.34.196"],"addressUsed
   ["validated"]   "2022-05-29T07:08:04Z")
   -> Executing hook script 'exit_hook' ...

   2022-05-29 09:08:09 - stopping dhydrated alpn server ...

Auffallend hier: "listen_Port" ist korrekt auf 444 gesetzt, "validationRecord" läuft weiterhin auf Port 443.

Zuletzt startete ich den Server manuell:

   # /etc/init.d/certs_dehydrated --start-alpn-server
   * Starting Dehydrated ALPN server ...                                 [  OK  ]

... und versuchte einen Zugriff per Browser auf http://www.my.domain:444, Der Server wurde nicht erreicht (Fehler: Gesicherte Verbindung fehlgeschlagen (PR_CONNECT_RESET_ERROR)). Im dehydrated-Logfile finde ich allerdings:

   Exception ignored in: <function SSLContext.set_servername_callback.<locals>.shim_cb at 0x7fc7cf6cdaf0>
   Traceback (most recent call last):
     File "/usr/lib64/python3.8/ssl.py", line 540, in shim_cb
       return server_name_callback(sslobj, servername, sslctx)
     File "/usr/sbin/dehydrated_alpn_responder.py", line 54, in load_certificate
   Exception ignored in: <function SSLContext.set_servername_callback.<locals>.shim_cb at 0x7fc7cf6cddc0>
   Traceback (most recent call last):
     File "/usr/lib64/python3.8/ssl.py", line 540, in shim_cb
       if not re.match(r'^(([a-zA-Z]{1})|([a-zA-Z]{1}[a-zA-Z]{1})|([a-zA-Z]{1}[0-9]{1})|([0-9]{1}[a-zA-Z]{1})|([a-zA-Z0-9][-_
     File "/usr/lib64/python3.8/re.py", line 191, in match
       return server_name_callback(sslobj, servername, sslctx)
     File "/usr/sbin/dehydrated_alpn_responder.py", line 54, in load_certificate
       return _compile(pattern, flags).match(string)
   TypeError: expected string or bytes-like object
       if not re.match(r'^(([a-zA-Z]{1})|([a-zA-Z]{1}[a-zA-Z]{1})|([a-zA-Z]{1}[0-9]{1})|([0-9]{1}[a-zA-Z]{1})|([a-zA-Z0-9][-_
     File "/usr/lib64/python3.8/re.py", line 191, in match
   ----------------------------------------
   Exception happened during processing of request from ('192.168.0.101', 47372)
       return _compile(pattern, flags).match(string)
   TypeError: expected string or bytes-like object
   got request for: www.my.domain
   got request for: www.my.domain

Der alpn-Server scheint also zu laufen, hat aber ein Problem mit dem Zertifikat.

Was fehlt hier zu meinem Glück? Ein Python-Modul? Kann der alpn-Server neben Apache auf Port 443 laufen? Habe ich einen Denkfehler?

Aktuell habe ich eine Zwangspause erwirkt (too many failed authorizations recently), weitere Tests müssen daher etwas warten.

Grüße

Rolf