Hallo,
ich habe eine Problem mit einer Seite. Ich habe mehrere Seiten über OPNsense mit HAProxy veröffentlicht.
Soweit, so gut - nun möchte ich gerne Mailcow installieren auf einem Docker Container. Da ich jedoch nur eine öffentliche IP Adresse habe, muss nun Lets Encrpyt aus dem Container ausgeführt werden, da die Zertifkate auch für andere Dinge wie SMTPS, IMAPS usw. genutzt werden.
Wenn ich jedoch den ACME Client in dem Container starte, kommt ein internal Error - ich vermute mal, das das Deploy nicht durch kommt und vom HAProxy abgefangen wird.
Meine Frage ist nun, kann ich im HAProxy einstellen, das eine bestimmte Site durchgelassen wird und so der ACME Client durchläuft?
Danke für eure Unterstützung.
Wenn Du den Setup wie im HAproxy-Tutorial verwendest, dürfte in den Rules für den Public HTTP eine mit dem Namen "redirect_acme_challenges" vorhanden sein. Aktuell prüft die nur den Pfad ("/.well-known..."), Du müsstest die Regel mit UND verknüpfen mit einem Test auf Deine Domains, die hinter der OpnSense liegen.
Wenn das alle betrifft, kannst Du die Regel auch im HTTP-Frontend wegnehmen, die wird automatisch angelegt, wenn Du für das ACME-Plugin die HAproxy-Integration aktivierst.
Allerdings funktioniert das so pro Domain nur entweder-oder per HTTP-01, weil für die Domain eben entweder das ACME-Plugin auf der OpnSense den Request bekommt oder aber Dein Backend.
Eine andere Variante wäre, die Zertifikate nicht mit HTTP-01, sondern per DNS-01 zu verifizieren, wenn Dein Backend und Dein DNS-Provider das können. Dann kann sogar jeder sein eigenes Zertifikat bekommen.
Eine kleine Warnung: Dovecot und Postfix können kein OCSP-Stapling. Eine gemeinsame Nutzung eines Domain-Zertifikats für HTTPS und für STARTTLS geht dann also nur mit OCSP-Stapling "off".
Quote from: meyergru on February 29, 2024, 12:51:32 AM
Wenn Du den Setup wie im HAproxy-Tutorial verwendest, dürfte in den Rules für den Public HTTP eine mit dem Namen "redirect_acme_challenges" vorhanden sein. Aktuell prüft die nur den Pfad ("/.well-known..."), Du müsstest die Regel mit UND verknüpfen mit einem Test auf Deine Domains, die hinter der OpnSense liegen.
Wenn das alle betrifft, kannst Du die Regel auch im HTTP-Frontend wegnehmen, die wird automatisch angelegt, wenn Du für das ACME-Plugin die HAproxy-Integration aktivierst.
Allerdings funktioniert das so pro Domain nur entweder-oder per HTTP-01, weil für die Domain eben entweder das ACME-Plugin auf der OpnSense den Request bekommt oder aber Dein Backend.
Eine andere Variante wäre, die Zertifikate nicht mit HTTP-01, sondern per DNS-01 zu verifizieren, wenn Dein Backend und Dein DNS-Provider das können. Dann kann sogar jeder sein eigenes Zertifikat bekommen.
Eine kleine Warnung: Dovecot und Postfix können kein OCSP-Stapling. Eine gemeinsame Nutzung eines Domain-Zertifikats für HTTPS und für STARTTLS geht dann also nur mit OCSP-Stapling "off".
Vielen lieben Dank für die schnelle Hilfe - ich werde das mal ausprobieren.
Danke dir :).
@meyergru: Noch mal eine andere Frage - ich habe noch eine zweite OPNsense in einem Rechenzentrum, dort habe ich kein HAProxy am laufen, jedoch den ACME Client, damit das Webgui Zertifikat auch gültig ist (LE).
Nun habe ich eine WAN Alias IP und NAT forwarder für HTTP/HTTPS auf die Adresse.
Jetzt habe ich den OPNsense ACME Client (für das Webui) jedoch auf DNS umgestellt - jedoch bekomme ich weiterhin die Meldung in dem weitergeleiteten ACME Client im Docker Container "Confirmed A record with IP 84.19.x.x, but HTTP validation failed".
Woran könnte das liegen? Kann es immer noch sein, das der ACME Client der OPNsense immer noch die http Anfragen für das verify "schluckt"? Wird der Verify auch für die Alias Adressen verwendet?
Danke für deine/eure Hilfe :).
Wenn er Dir sagt, dass die HTTP Validation fehlgeschlagen ist, ist die Validierungsmethode offenbar nicht DNS-01.
Hast Du eventuell nur eine Aktualisierung anstelle einer Neuausstellung angefordert? Oder vergessen, den neuen Challenge Type dem Zertifikat zuzuordnen?
Sorry, hatte mich nicht genau ausgedrückt. Auf der OPNsense im RZ habe ich von HTTP auf DNS umgestellt. Das scheint auch geklappt zu haben, nun meinte ich das ich auf dem Docker Container (hinter NAT für Port 80 von der ext. Alias Adresse auf den internen Docker Container) verwenden zu können.
Ich kann auch die Seite von extern per HTTP und HTTPS (dann natürlich ohne gültiges LE-Zertifikat) zugreifen - jedoch kann der Container keine eigne ACME HTTP Challenge ausführen (Meldung oben).
Da der HTTP Zugriff möglich ist, gehe ich davon aus das immer noch das Challenge von der OPsense "schluckt".
Ich hoffe, ich könnte mich verständlich ausdrücken.
Danke für deine/eure Hilfe.
Wenn das noch durch den HAproxy läuft und die ACME Integration noch eingeschaltet ist, dann wird da noch die Regel drin sein, die den Pfad /.well-known abfängt.
Danke für deine schnelle Antwort.
Es sind zwei Konfigurationen - die eine, war die ganz oben mit dem HAProxy und die, die danach folgte mit dem Rechenzentrum (um die es hier geht) ist eine andere Konfiguration. In dieser war niemals ein HAProxy, nur die Webgui mit ACME Client und umgestellt von HTTP auf DNS Challenge - womöglich sind jedoch Einstellungen nicht ganz bereinigt.
Ich bin in diesem Thread nicht 100% auf Stand und hab ehrlicherweise gerade auch keine Zeit, ins Detail zu gehen, aber werfe mal eine Sache rein, die auch zu berücksichtigen ist.
Hat die OPNsense nach außen mehrere öffentliche IP-Adressen um z.B. per HAproxy unterschiedliche Kundensysteme hinter der Firewall zu bedienen, muss man zumindest für die HTTP-Challenge auch ausgehende NAT-Regeln haben, die zu den eingehenden IP-Adressen für $HOSTNAME passen.
Ich baue gerade so ein Setup für einen größeren Kunden.
Wenns am Thema vorbei ist, sorry - ignorieren.
Hallo Patrick,
jeder Strohhalm ist willkommen. In diesem Falle ist es aber so, das das HTTP Challenge von einem Docker Container hinter der OPNsense kommt - beim Test ist alles in Ordnung:
29.02.2024, 21:32:12 mail.xxx.de - Use SKIP_LETS_ENCRYPT=y in mailcow.conf to skip it permanently.
29.02.2024, 21:32:12 mail.xxx.de - Cannot validate any hostnames, skipping Let's Encrypt for 1 hour.
29.02.2024, 21:32:12 mail.xxx.de - Confirmed A record with IP 84.19.x.x, but HTTP validation failed
29.02.2024, 21:32:12 mail.xxx.de - Found A record for mail.xxx.de: 84.19.x.x
29.02.2024, 21:32:12 mail.xxx.de - Confirmed A record with IP 84.19.x.x, but HTTP validation failed
29.02.2024, 21:32:12 mail.xxx.de - Found A record for autoconfig.xxx.de: 84.19.x.x
29.02.2024, 21:32:12 mail.xxx.de - Confirmed A record with IP 84.19.x.x, but HTTP validation failed
29.02.2024, 21:32:12 mail.xxx.de - Found A record for autodiscover.xxx.de: 84.19.x.x
29.02.2024, 21:32:11 mail.xxx.de - OK: 84.19.x.x, 0000:0000:0000:0000:0000:0000:0000:0000
29.02.2024, 21:31:52 mail.xxx.de - Detecting IP addresses...
29.02.2024, 21:31:52 mail.xxx.de - Using existing Lets Encrypt account key /var/lib/acme/acme/account.pem
29.02.2024, 21:31:52 mail.xxx.de - Using existing domain rsa key /var/lib/acme/acme/key.pem
29.02.2024, 21:31:52 mail.xxx.de - Initializing, please wait...
29.02.2024, 21:31:52 mail.xxx.de - OK
Aufruf raus ist in Ordnung (richtige NAT Adresse), IP Adressen / DNS (A und CNAME) sowie Reverse Lookup alles ok. Die NAT Anfragen kommen auch rein, da ich mich an dem Webinterface anmelden kann. Ich vermute hier, das hier "nur" die ACME Challenge geschluckt wird.
Dabei habe ich nun beim ACME Client der OPNsense von HTTP auf DNS umgestellt.
Nachtrag: Lag definitiv an der OPNsense - habe nun mal eine andere Firewall verwendet und siehe da, dort funktioniert es einwandfrei. Wäre aber schön, wenn ich doch wieder auf die OPNsense zurückschwenken könnte.
Quote from: meyergru on February 29, 2024, 07:57:34 PM
Wenn er Dir sagt, dass die HTTP Validation fehlgeschlagen ist, ist die Validierungsmethode offenbar nicht DNS-01.
Hast Du eventuell nur eine Aktualisierung anstelle einer Neuausstellung angefordert? Oder vergessen, den neuen Challenge Type dem Zertifikat zuzuordnen?
Hallo, mit der OPNsense im Rechenzentrum bin ich nun weiter - nun wollte ich mich wieder an die andere im Homeoffice machen (die ganz oben).
Dort habe ich HAProxy und dem WebUI ein LE Wildcard zugeordnet, zuerst hatte ich das mit HTTP Challenge - später nun auf DNS Challenge umgestellt. Da ich das Challenge umgestellt habe (Anzeigename und DNS), und mir auch der neue Anzeigename im Zertifikat angezeigt wird, gehe ich davon aus das auch dies übernommen wurde. Was muss ich nun tun, muss ich auf den runden Pfeil drücken (Issue or Renew Certificate)?
Kann man dann irgendwo sehen, das nun per HTTPS abgerufen wurde und nicht mehr mit HTTPS?
Ist dann automatisch gegeben, das LE HTTPS Challenges von einem ge-NAT-teten Client hinter der OPNsense durchläßt, oder muss ich dann noch was ändern?
Danke für deine / eure Hilfe :).
> Ist dann automatisch gegeben, das LE HTTPS Challenges von einem ge-NAT-teten Client hinter der OPNsense durchläßt, oder muss ich dann noch was ändern?
Vielleicht versteh ich deine Frage falsch, aber LE Challenges können NIE HTTPS sein, das wäre ja sinnbefreit. Da damit erst das Zertifikat ausgestgellt wird, kann ja keine Challenge via HTTPS reinkommen, die geht entweder eben per DNS01 Challenge oder per HTTP auf Port 80.
Und wenn du die auf DNS geändert hast, dann kommt da eh kein Request mehr via HTTP oder HTTPS rein.
Cheers