Caddy + ACME Client mit HTTP-01 Challenge - Let's Encrypt erhält keine Antwort

[viragomann]

Hallo,

auf meiner Heiminstallation von OPNsense habe wollte ich nun Caddy versuchen, weil es hier im Forum vielfach als einfach zu konfigurierender Reverse-Proxy bejubelt wird und meinen Anforderungen hier wohl genügt.
Bislang macht mein primärer Webserver (Apache) den Reverse-Proxy für die wenigen Anfragen, die auf andere Hosts gehen sollen. Und auf diesem läuft auch der ACME-Client. Funktioniert eigentlich alles zu gut, als dass ich mich allzu lange mit Alternativen beschäftige. Aber jetzt ist gerade Zeit und auf der OPNsense wäre das auch vielleicht schöner gelöst.

Mit dem Reverse-Proxy muss aber auch der ACME-Client auf die OPNsense übersiedeln. Doch der Client meldet einen Timeout beim Versuch, ein Zertifikat anzufordern.
Mir auch nicht klar, wie HTTP-01 Challenge zusammen mit Caddy überhaupt funktionieren soll. Dieser bekommt ja die HTTP Anfragen und müsste sie dahin weiterleiten, wo der ACME-Client die Challenge deponiert. Hinweise darauf, dass das auch passiert, konnte ich nicht finden.

Nun der ACME-Client bietet hierfür nur "OPNsense Web Service (automatic port forward)". Anders als das HAproxy Plugin stellt Caddy hier ja kein eigenes Service bereit.
Wie soll das nun funktionieren? Ist hier eine entsprechende Weiterleitung manuell in Caddy zu konfigurieren? Wenn ja, wie?

Im Web konnte ich dazu nichts finden. Ich bin nur mehrfach auf Loblieder gestoßen, dass Caddy alles automatisch machen würde. So dachte ich mir, vielleicht trifft das hier auch zu, ist ja wohl keine seltene Herausforderung, und habe mal versucht, ein Zertifikat anzufordern, aber da kommt nichts.
Der ACME-Client loggt

Code Select Expand

Invalid status. Verification error details: <WAN IP>: Fetching http://host.mydomain.tld/.well-known/acme-challenge/yvQjtqi_r-FZsC6gsmn1QWQx389QJ3OkCFsbJOk0MHU: Timeout during connect (likely firewall problem)Auch im 'debug 2' Level findet sich kein genauerer Anhaltspunkt.
Und Hinweise im Web deuten meist auf ein Firewall-Problem hin, das hier wohl nicht zutrifft. Die Firewall-Regeln habe ich überprüft, Geo-Blocker habe ich deaktiviert und auch den Zugriff von außen getestet.

Letztendlich habe ich während der Zertifikatsanforderung Pcap am WAN laufen lassen. Da sehe ich die Pakete von Let's Encrypt auf meine WAN-IP Port 80 mit der Länge 0, es kommt aber keine Antwort.
Rufe ich selbst den o.g. Pfad von außen auf, sehe ich die Antwortpakete.
Ja, das riecht nach Geo-Blocking. Die Regel hatte ich aber deaktiviert. Die Qell-IP (USA) sollte ohnehin nicht im Alias enthalten sein.
Was ist es dann??
Ich habe das Logging sämtlicher Regeln am WAN aktiviert, ebenso das der Default-Deny Regel und sehe den versuchten Zugriff nicht im Log.
So stellt sich die Frage, was kann die Pakete nach dem Pcap und vor den Filter-Regeln blockieren?

Was mir in diesem Zusammenhang auch ziemlich seltsam erscheint: Caddy beantwortet jede Anfrage auf http://host.mydomain.tld/<egal-was> mit 200.
Die Zusatzfrage wäre also: Kann vielleicht jemand den Sinn dieses erklären?

Vielleicht sollte ich auch noch erwähnen: Caddy funktioniert ansonsten offenbar. Services, die nicht TLS nutzen, habe ich bereits vor Tagen migriert und sind von intern und extern erreichbar. Diese laufen auf Port 80, was mir sagt, dass dieser auf Caddy ankommt. Den zuständigen Reverse-Proxy auf meinem Webserver habe ich deaktiviert.

Hat jemand eine Erklärung für dieses Phänomen?

Grüße