Lösung für HAproxy + ACME für interne Geräte

Started by MoChri, May 06, 2025, 03:29:02 PM

Previous topic - Next topic
Quote from: meyergru on May 06, 2025, 08:12:18 PMAlso erstens gibt es für den HAproxy Setup mal ein super Tutorial.
HAproxy ist zugegebenermassen schwieriger als Caddy, kann aber ein bisschen mehr. Auch dafür gibt es ein Tutorial.

Am Rande bemerkt würde ich aus gegebenem Anlass keine HTTP-01 Verifikation für von außen sichtbare Dienste mehr nutzen, sondern nur noch DNS-01. Die Gründe dafür sind hier erklärt. Wenn man ACME-Zertifikate für Services nutzen will, die nicht von außen erreichbar sind, führt an DNS-01 ja sowieso nichts vorbei. Es vereinfacht auch vieles, weil man dann nur ein einziges Wildcard-Zertifikat für alle DNS-Namen in der Domain benötigt.

Die kenne ich schon alle und gibt noch viel mehr dazu was mir aber nicht die richtige Antwort/Erklärung bringt.
Ich habe ja OPNsense mit HAproxy + ACME für denn Exchangeserver laufen und der ist von aussen & intern erreichbar weil am externen Domainprovider der A, MX, SPF, DKIM, DMARC, usw. Eintrag gemacht wurde auf "mail.meindomain.tld" und intern habe ich bei meinem internen DNS Server auch die ext. IP für den A eintrag von "mail.meindomain.tld" eingestellt.
Der frontend von HAproxy hört auf die externe IP:443

Das ist für mich total verständlich und funktioniert ja auch super.

Nur habe ich mir Gedanken gemach, um das so lästige Wegklicken von dem Zertifikatfehlern hinzubekommen, müsste das ja auch nur für die Interne Geräte auch funktionieren. Ja da ist aber jetzt der hacken wo ich es nicht mehr verstehe!!

Ich habe ein Netzwerksegment 172.20.20.1/24 wo alle meine Geräte laufen -> Domaincontroller/DNS-Server/Netzwerkspeicher/Mail-Gateway/Audio-Server/Drucker/usw. was alle eine HTTPS Seite zur Bedienung und Konfiguration besitzen. Da möchte ich jetzt, wenn ich intern von meinem PC am Browser z.b.:"NAS.meinedomain.tld" eingeben eine Zertifikatfehlerfreie verbindung haben.

Das ganze ohne das ich bei den Clienten ein Zertifikat hochladen muss da dies ja mein HAproxy übernehmen soll. Dies funktioniert ja auch beim Exchangeserver schon so nur da geht alles über die ext. IP wo der hacken ist! Da ich bei den Activ Directory Domaincontroller alle verbunden Geräte ja die Einträge selbst machen und das ist die interne IP z.b für nas.meinedomain.tld = 172.20.20.23.

Mein problem ist ich verstehe nicht wie ich OPNsense(HAproxy) einstellen muss das dies von intern funktioniert ohne das ich es über die externe IP mache.
Habe unter DHCPv4 keine DNS-Server & Domainname gesetzt
hätte bei Unbound DNS die Host Überschreibeung probiert mit HOST (*) Domain (meindomain.tld) auf die DNS-Server IP leider stürtz da Unbound DNS ab und kann es nicht mehr starten.

Quote from: MoChri on May 06, 2025, 11:06:29 PMDa möchte ich jetzt, wenn ich intern von meinem PC am Browser z.b.:"NAS.meinedomain.tld" eingeben eine Zertifikatfehlerfreie verbindung haben.

Das geht genau dann, wenn

- du eine HAproxy-Konfiguration für NAS.meinedomain.tld hast - den Teil hast du im Griff
- auch intern NAS.meinedomain.tld auf die externe (!) IP-Adresse deiner OPNsense auflöst

Das ist die einzige mir bekannte Methode. Wenn du Split-DNS haben willst, dann geht das halt fundamental nicht. Klar soweit?

Ist dann natürlich die Frage, ob Browser zum Administrieren die einzige Verwendung von NAS.meinedomain.tld ist. Wenn du das auch für die SMB-Verbindungen benutzt anstelle von NAS.local oder \\NAS ... dann wird es schwierig.

Ich hab mich dagegen entschieden und hab auf der Sense eine CA mit 20 Jahren Laufzeit für eine interne Domain - foo.meinedomain.tld - und alle Geräte hier sind in dieser. Dann ein Wildcard-Zertifikat mit 2 Jahren Laufzeit und ich hab nur alle 2 Jahre Aufwand.
Deciso DEC750
People who think they know everything are a great annoyance to those of us who do. (Isaac Asimov)

Quote from: Patrick M. Hausen on May 06, 2025, 11:24:31 PM
Quote from: MoChri on May 06, 2025, 11:06:29 PMDa möchte ich jetzt, wenn ich intern von meinem PC am Browser z.b.:"NAS.meinedomain.tld" eingeben eine Zertifikatfehlerfreie verbindung haben.

Das geht genau dann, wenn

- du eine HAproxy-Konfiguration für NAS.meinedomain.tld hast - den Teil hast du im Griff
- auch intern NAS.meinedomain.tld auf die externe (!) IP-Adresse deiner OPNsense auflöst

Das ist die einzige mir bekannte Methode. Wenn du Split-DNS haben willst, dann geht das halt fundamental nicht. Klar soweit?

Ist dann natürlich die Frage, ob Browser zum Administrieren die einzige Verwendung von NAS.meinedomain.tld ist. Wenn du das auch für die SMB-Verbindungen benutzt anstelle von NAS.local oder \\NAS ... dann wird es schwierig.

Ich hab mich dagegen entschieden und hab auf der Sense eine CA mit 20 Jahren Laufzeit für eine interne Domain - foo.meinedomain.tld - und alle Geräte hier sind in dieser. Dann ein Wildcard-Zertifikat mit 2 Jahren Laufzeit und ich hab nur alle 2 Jahre Aufwand.

Danke für deine Antwort! Die hat es auf den Punkt gebracht das dies nicht so lösbar ist so wie ich das haben möchte daher findet man ja auch nichts im Internet dazu!

Jetzt muss und werde ich entweder deinen Weg einschlagen oder mit den Zertifikatfehlern leben müssen. :)

Quote from: MoChri on May 06, 2025, 11:59:26 PModer mit den Zertifikatfehlern leben müssen.

Bau dir deine eigene CA und importier die auf allen Desktops mit denen du arbeitest als vertrauenswürdig.
Von einer privaten CA signierte Zertifikate dürfen eine Laufzeit von etwa 2 Jahren plus 3 Monaten haben.

HTH,
Patrick
Deciso DEC750
People who think they know everything are a great annoyance to those of us who do. (Isaac Asimov)

Quote from: Patrick M. Hausen on May 07, 2025, 12:10:14 AM
Quote from: MoChri on May 06, 2025, 11:59:26 PModer mit den Zertifikatfehlern leben müssen.

Bau dir deine eigene CA und importier die auf allen Desktops mit denen du arbeitest als vertrauenswürdig.
Von einer privaten CA signierte Zertifikate dürfen eine Laufzeit von etwa 2 Jahren plus 3 Monaten haben.

HTH,
Patrick

Hallo Patrick,

Ja werde ich machen nur kurz noch eine Frage
Wo würdest du die machen? Auf der OPNsense oder am Domaincontoller installieren?

Gruss
Christian

Ich hab sie auf der OPNsense. Ich habe aber auch keinen DC :-)
Deciso DEC750
People who think they know everything are a great annoyance to those of us who do. (Isaac Asimov)

May 07, 2025, 10:25:30 AM #21 Last Edit: May 07, 2025, 10:30:31 AM by meyergru
Quote from: Patrick M. Hausen on May 06, 2025, 11:24:31 PMIch hab mich dagegen entschieden und hab auf der Sense eine CA mit 20 Jahren Laufzeit für eine interne Domain - foo.meinedomain.tld - und alle Geräte hier sind in dieser. Dann ein Wildcard-Zertifikat mit 2 Jahren Laufzeit und ich hab nur alle 2 Jahre Aufwand.

Patrick hat vollkommen korrekt die Methode für ACME-Zertifikate für "interne" Zertifikate beschrieben. Die hat zwei Nachteile:

1. Die Namen müssen eine TLD enthalten, sind also länger als eigene Zertifikate (xxx.localdomain).
2. Da die Zertifikate aktuell nur 90 Tage gelten und üblicherweise nach 60 Tagen verlängert werden, müssen sie normalerweise alle 60 Tage wieder auf die Endgeräte eingebracht werden. In Zukunft sollen diese Zertifikate übrigens nur noch maximal 10 Tage gelten - so will es das CA/Browser Forum.

Die einzige Alternative zu 2 ist, eine zentrale Instanz (z.B. die OpnSense) ein Wildcard-Zertifikat ausstellen zu lassen und einen Reverse Proxy zu verwenden, der den Zugriff auf die internen Services macht. Ein Einbringen per SFTP o.ä. ist oft nicht möglich.

Ich mache es bisher genau wie Patrick: Ich habe meine eigene langlebige CA, deren Zertifikat ich auf meinen PCs einbringe und mit der ich die Zertifikate ausstelle. Das hat bis dato zwei Probleme:

1. 2020 wurde die maximale Gültigkeit von Zertifikaten begrenzt auf derzeit 397 Tage. Man kann heute also eigentlich keine Zertifikate mehr ausstellen, die lange laufen, was man aber für interne Services gern möchte.
2. Wildcard-Zertifikate werden ausschließlich bei CNs akzeptiert, die eine TLD aufweisen, also *.yyy.de, aber nicht *.yyy. Damit muss für jeden Service ein eigenes Zertifikat ausgestellt werden.

In naher Zukunft wird das nochmals schwieriger, weil auch die maximale Zertifikatsdauer auch für nicht-ACME-Zertifikate verkürzt werden soll, in Schritten bis auf 47 Tage (!).

Es gibt allerdings einen Trick, den Patrick nicht erwähnt hat: Die Gültigkeitsregeln gelten nicht für bereits ausgestellte Zertifikate.
Das macht sich am Laufzeitbeginn fest, den man aber setzen kann: der notwendige Parameter für "openssl ca" lautet "-startdate 20190630120000Z" (P.S.: Die CA muss natürlich auch davor "entstanden" sein). Leider geht das nicht mit der OpnSense-CA, wäre eventuell ein sinnvoller Feature-Request.
Intel N100, 4 x I226-V, 16 GByte, 256 GByte NVME, ZTE F6005

1100 down / 800 up, Bufferbloat A+

May 07, 2025, 10:52:50 AM #22 Last Edit: May 07, 2025, 10:55:12 AM by Patrick M. Hausen
Das mit der Laufzeit ist nicht ganz richtig.

Wenn du eine private CA in deinen Trust-Store importierst, erkennt das System richtig, dass das eine interne ist. Und für Zertifikate einer internen CA gelten andere Regeln.

Siehe z.B. hier:

https://support.apple.com/en-us/102028

QuoteThis change will not affect certificates issued from user-added or administrator-added Root CAs.

Dummerweise hat Apple es aber an anderer Stelle versaut und deshalb gilt zumindest unter Mac OS jetzt die vorherige maximale Gültigkeitsdauer von 825 Tagen. Das sind die rund 2 Jahre plus 3 Monate, die ich erwähnt hatte. Hab gerade nochmal den genauen Wert recherchiert.

Eigentlich könnten Zertifikate einer internen CA beliebig lang gelten aber wie gesagt nicht unter Mac OS ...

Mit "rund alle 2 Jahre" kann ich leben. Zumal mein Uptime Kuma mich warnt, wenn die auslaufen.

Gruß
Patrick

P.S. Und warum das ganze? Das hat @meyergru ja auch schon erwähnt: für das ganze Geraffel wie Switche, Drucker und USV, auf die man die Zertifikate nicht automatisch deployed bekommt. Es sei denn man will archaische Weboberflächen skripten 🤪
Deciso DEC750
People who think they know everything are a great annoyance to those of us who do. (Isaac Asimov)

Interessant, das muss neu sein. Macht ja auch Sinn, sonst gäbe es mit internen Zertifikaten ja immer Stress.

Firefox und Opera machen es jetzt auch so. Das war mal anders - ich habe das nämlich auf die harte Art gelernt, als ich 2020 mal ein neues Zertifikat ausgestellt habe, dass dann nicht funktionierte. Dann habe ich nachgeforscht und den Trick mit dem alten Startddatum gefunden.
Intel N100, 4 x I226-V, 16 GByte, 256 GByte NVME, ZTE F6005

1100 down / 800 up, Bufferbloat A+

Quote from: MoChri on May 06, 2025, 11:06:29 PMDas ganze ohne das ich bei den Clienten ein Zertifikat hochladen muss da dies ja mein HAproxy übernehmen soll. Dies funktioniert ja auch beim Exchangeserver schon so nur da geht alles über die ext. IP wo der hacken ist! Da ich bei den Activ Directory Domaincontroller alle verbunden Geräte ja die Einträge selbst machen und das ist die interne IP z.b für nas.meinedomain.tld = 172.20.20.23.

Mein problem ist ich verstehe nicht wie ich OPNsense(HAproxy) einstellen muss das dies von intern funktioniert ohne das ich es über die externe IP mache.
Habe unter DHCPv4 keine DNS-Server & Domainname gesetzt
hätte bei Unbound DNS die Host Überschreibeung probiert mit HOST (*) Domain (meindomain.tld) auf die DNS-Server IP leider stürtz da Unbound DNS ab und kann es nicht mehr starten.

Zwei Punkte:

1) Nur weil du intern den AD DNS hast, MUSS der nicht zwingend benutzt werden. Du kannst problemlos den Clients per DHCP den DNS der Sense geben und dort als Domain Override dein meinedomain.tld zum AD DNS verweisen lassen. Man kann da auch mehrere für Redundanz angeben. Damit würden dann alle erstmal über die Sense reden, nicht direkt mit der AD Zone.

2) In der Sense kannst du dann problemlos nas.meinedomain.tld umschreiben auf den HAProxy - entweder die Public IP oder du bindest HAproxy einfach zusätzlich noch auf die interne IP und dann kannst dus auf die interne IP umschreiben. Geht beides. Dann redet dein Client mit der Sense/Haproxy, die ruft dein NAS auf. Feddich.

Das GEHT. Ist nur nicht ganz so simpel und hängt stark von den Rahmenbedingungen ab, deshalb nutzt da kein "Howto" irgendwas, weil niemand weiß wie dein Netz intern aufgebaut und strukturiert ist.

Aber gehen tuts.

Cheers :)
"It doesn't work!" is no valid error description! - Don't forget to [applaud] those offering time & brainpower to help you!
Better have some *sense as no(n)sense! ;)

If you're interested in german-speaking business support, feel free to reach out via PM.