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

[Monviech (Cedrik)]

Da ist irgendwas falsch konfiguriert. Mache alles so wie in der Anleitung:

https://docs.opnsense.org/manual/how-tos/caddy.html#prepare-opnsense-for-caddy-after-installation

Ich vermute es fehlte eine Firewallregel die Port 80 erlaubt.

Aber Caddy ist sehr Fehlertolerant und würde auch port 443 nehmen für TLS-ALPN

https://caddyserver.com/docs/automatic-https#errors

Wenn beides nicht geht gehe ich stark von einer policy based routing oder geoblocking Regel aus, oder einer Port Forward Regel (auf dem WAN zb) die Anfragen umleitet.

[viragomann]

Es gab nun einen Erfolg.

Ich hatte das ACME Client Plugin nicht aktiviert gehabt. Ich hatte gedacht, dass dies für den Testmodus nicht nötig wäre. Ich hatte ACME schon auf zwei anderen OPNsense Instanzen eingerichtet, doch hier wohl erstmalig die Test CA verwendet, was auch gut war. :-/
Muss sagen, das Fehlerbild dieser Misskonfiguration ist aber ziemlich seltsam. Warum da Let's Encrypt keine Antwort bekommt, eine andere Quelle aber schon...?
Und warum der ACME-Client dennoch Let's Encrypt kontaktiert hatte?

Dann hatte ich in meiner Verzweiflung noch für den letzten Test einen Reverse-Proxy Handler mit meinem Backend-Webserver hinzugefügt. Damit hatte ACME auch nicht funktioniert. Ich musste ihn wieder entfernen.
Warum eigentlich? Sollte Caddy nicht den "/.well-known/acme-challenge/" Pfad automatisch umleiten?

[Monviech (Cedrik)]

Caddy braucht kein Acme Client Plugin, es macht Acme selber mit einem eingebauten client (certmagic). Das benötigt port 80 und 443 offen auf WAN mit target This Firewall. Caddy kann mit mehreren challenge typen Zertifikate erlangen (je nach Konfiguration 3 verschiedene Challenges zu 2 default ACME Providern).

/well-known wird reserviert, aber wenn du z.B. http domains reverse proxiest, werden alle Pfade durchgereicht. Hier ein beispiel:

https://docs.opnsense.org/manual/how-tos/caddy.html#redirect-acme-http-01-challenge

https://github.com/opnsense/plugins/blob/d3cbedaa8e405a72fc8317d0b4d4aed9c96a63c3/www/caddy/src/opnsense/service/templates/OPNsense/Caddy/Caddyfile#L268

Das oben zeigt ganz klar was passieren würde wenn man einen handle / auf eine http domain setzt, auch der http01 pfad wird nach hinten durchgereicht. Da wird für die selbe Domain nichts reserviert.

Im Grunde benötigt man eigendlich /nie/ das http frontend, mit dem https frontend pro domain macht Caddy schon eine automatische weiterleitung und reserviert sich /well-known/.... für sich selbst.

-------

Das Acme sh script plugin (Also os-acme-client) benutzt PF Anchors um einen upper port in der firewall zu öffnen und darüber die challenge zu machen. Das ist ein anderer mechanismus. Die HTTP01 challenge kann auch über einen anderen port als 80 erfolgen.

Ich denke hier werden ein paar Konzepte miteinander vermischt und das ergibt Verwunderung.

[viragomann]

Caddy braucht kein Acme Client Plugin, es macht Acme selber mit einem eingebauten client (certmagic).

Gelesen hatte ich den Absatz, so verstanden aber nicht. :-/

/well-known wird reserviert, aber wenn du z.B. http domains reverse proxiest, werden alle Pfade durchgereicht. Hier ein beispiel:
https://docs.opnsense.org/manual/how-tos/caddy.html#redirect-acme-http-01-challenge

Eben genau dieses hätte ich gedacht, müsste konfiguriert werden, damit Caddy die HTTP-01 Challenge durchreicht. Und daher hatte ich angenommen, dass er es sonst nicht tut.

Im Grunde benötigt man eigendlich /nie/ das http frontend

Ich nutze jedoch HTTP, bspw.  für Audio-Streams. Muss ich dann nur diese Domains für HTTP konfigurieren und http-Anfragen auf andere Domains werden automatisch auf https umgeleitet?

Das Acme sh script plugin (Also os-acme-client) benutzt PF Anchors um einen upper port in der firewall zu öffnen und darüber die challenge zu machen. Das ist ein anderer mechanismus. Die HTTP01 challenge kann auch über einen anderen port als 80 erfolgen.

Ja, so etwas hatte ich schon vermutet. Jedoch zeigte pcap Port 80 Zugriffe von LE, weswegen ich angenommen hatte, dass Caddy diese handeln müsste.

Ich denke hier werden ein paar Konzepte miteinander vermischt und das ergibt Verwunderung.

Und die hält immer noch an...

Ich muss also ins kalte Wasser springen, auch sämtliche https Domains auf Coddy einrichten und dann schauen, was passiert.

Werden die Zertifikate von Coddy eigentlich auch im Trust Store von OPNsense abgelegt, so dass man dies auch verifizieren kann?