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
Hallo Leute,

Ich suche jetzt schon Tage nach einer Lösung und komme einfach nicht dahinter, obwohl ich mir schon einige Videos usw. angesehen habe. Ich weiß auch nicht ob das eigentlich der richtige Weg ist da ich ja nichts darüber finde.
Ich möchte realisieren: Für alle meine internen Geräte ein Zertifikat mit dem ACME Client erstellen und über HAproxy verteilen.
(vorweg macht man das überhaupt so oder gibt's bessere Lösungen?)

Da ich für den Exchange2019 HAproxy + ACME Client eingestellt habe zwecks Zertifikate und das auch schon Jahre Top funktioniert wollte ich das auch für meine anderen WebGui/Geräte machen da dieses weck Klicksen lästig ist im Browser.
Für die OPNsense selbst einfach da braucht man kein HAproxy nur ACME Client und unter System-Einstellungen-Verwaltung das Zertifikat für die OPNsense angegeben und funktioniert auch sofort wenn ich ,,fw01.meineDomain.tld" aufrufe. Egal von welcher Schnittstelle ohne HAproxy -> okay passt denk ich mir.
So jetzt komme ich zum eigentlichen Problem wo ich keine lösung bis jetzt gefunden habe.
Wenn ich jetzt z.b für meine WebGui vom ,,mg01.meinDomain.tld" ein Zertifikat erstellen lasse und ich möchte das dies wie beim Exchange Server verwenden stosse ich auf das Problem das ich beim DC die DNS config so machen muss das ,,mg01" auf die externe IP zeigt wie bei ,,mail.meinedomain.tld" sonst erkennt das HAproxy nicht um das Zertifikat zu verwenden.
Das nächste problem kommt erst wenn ich das ganze für das NAS machen will da kann ich die externe nicht angeben da die ja in der AD hängt und die DNS Einträge selbst aktualisiert.
So jetzt würde ich eure Hilfe benötigen da ich irgendwie keine Ahnung/Idee habe wie ich das lösen könnte.

Quote from: MoChri on May 06, 2025, 03:29:02 PMIch möchte realisieren: Für alle meine internen Geräte ein Zertifikat mit dem ACME Client erstellen und über HAproxy verteilen.
(vorweg macht man das überhaupt so oder gibt's bessere Lösungen?)
Warum sollte man das machen, wenn man HAproxy hat.

Meiner Meinung die bessere Konfiguration ist, alle Zugriffe über HAproxy auf den Backends zu führen, auch von intern.

Auf der OPNsense besorgt der ACME Client öffentlich-gültige Zertifikate. Diese werden im HAproxy dem Public Service zugewiesen. Fertig.

Soll auch die Verbingung von HAproxy auf die Backends verschlüsselt werden, auf der OPNsense eine CA für interne Zertifikate erstellen und sehr langlebige Zertifikate damit generieren und diese auf den Backend-Servern installieren. Das könnte auch dasselbe für alle sein.
HAproxy kann dann per https zugreifen. Das Backend kann so konfiguriert werden, dass es die Zertifikate nicht überprüft. Also muss der CN nicht zur Domain passen. Auch müsste es zeitlich nicht gültig sein. Er kann es aber auch gegen eine angegebene CA überprüfen.

Grüße

Danke schon mal für die schnelle rückmeldung aber wie soll ich das jetzt verstehen?
HAproxy erstellt man zuerst den Tatsächlichen Server -> (Virtuelle) Backend-pool mit Frontend -> mit dem spreche ich eigentlich, wenn ich z.b. mg01.meinedomain.tld aufrufe.
Das geht aber nur weil ich im DNS Server die externe IP angegeben habe. Wie kann ich den Frontend den übergehen so das der haproxy das für die interne Geräte macht. Das ist ja gerade das was ich nicht kapiere.
Wenn du mir das näher erklären könntest bitte oder einen Link hast dazu wäre echt super.

Danke

Quote from: MoChri on May 06, 2025, 04:31:10 PMHAproxy erstellt man zuerst den Tatsächlichen Server -> (Virtuelle) Backend-pool mit Frontend -> mit dem spreche ich eigentlich, wenn ich z.b. mg01.meinedomain.tld aufrufe.
Das geht aber nur weil ich im DNS Server die externe IP angegeben habe. Wie kann ich den Frontend den übergehen so das der haproxy das für die interne Geräte macht.
Dafür ist nichts weiter nötig als den Zugriff auf die externe IP zu erlauben.

Du sollst also keine internen DNS Override für die Domains eingerichtet haben. Dann verbinden sich die Geräte auf die externe IP.
OPNsense ist vermutlich dein Standardgateway, also erhält es diese Anfragen. Dass die angefragte IP tatsächlich einem anderen Interface zugewiesen ist, als die Pakete ankommen, ist dabei egal.

May 06, 2025, 08:12:18 PM #4 Last Edit: May 06, 2025, 08:53:29 PM by meyergru
Also 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.


Intel N100, 4 x I226-V, 16 GByte, 256 GByte NVME, ZTE F6005

1100 down / 800 up, Bufferbloat A+

Quote from: meyergru on May 06, 2025, 08:12:18 PMAm 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.
Das setzt aber eine API voraus, die mit dem genutzten DNS zusammenarbeitet.
Also es empfiehlt sich das vorab zu überprüfen.

Ich hatte seinerzeit eigens das DNS zu einem vermeintlich unterstützten Provider migriert, natürlich in Handarbeit, um dann festzustellen, dass die verwendete API bereits seit einem halben Jahr nicht mehr funktioniert hatte. Angekündigt hatte der Provider die Änderung bereits ein Jahr zuvor.

Am Ende hatte ich Stunden für die DNS Migration, die ACME Konfiguration und das Troubleshooting aufgewendet und dann ein SAN Zertifikat bei einem Anbieter gekauft. War viel Aufwand für nichts.

Irgendwo einen günstigen Cloud-VPC mieten und die Distribution nach Wahl und acme-dns installieren.

Hab ich gemacht. Mit FreeBSD bei Vultr.
Deciso DEC750
People who think they know everything are a great annoyance to those of us who do. (Isaac Asimov)

Interessant.

Das wäre dann allerdings ein Single point of failure, den ich mir lieber nicht in eine Produktivumgebung einbauen möchte.
Für den Hausgebrauch aber sicher nett.

Wieso? Der liegt bei einem Cloud-Anbieter in der Infrastruktur, die hoffentlich halbwegs verfügbar ist, und wird nur dann benötigt, wenn die Zertifikate entweder erstmalig ausgestellt oder später dann verlängert werden. Monitoring drauf, das piept, wenn er ausfällt, und gut.
Deciso DEC750
People who think they know everything are a great annoyance to those of us who do. (Isaac Asimov)

May 06, 2025, 08:49:17 PM #9 Last Edit: May 06, 2025, 08:58:31 PM by meyergru
Quote from: viragomann on May 06, 2025, 08:29:53 PMDas setzt aber eine API voraus, die mit dem genutzten DNS zusammenarbeitet.
Also es empfiehlt sich das vorab zu überprüfen.

Ich hatte seinerzeit eigens das DNS zu einem vermeintlich unterstützten Provider migriert, natürlich in Handarbeit, um dann festzustellen, dass die verwendete API bereits seit einem halben Jahr nicht mehr funktioniert hatte. Angekündigt hatte der Provider die Änderung bereits ein Jahr zuvor.

Am Ende hatte ich Stunden für die DNS Migration, die ACME Konfiguration und das Troubleshooting aufgewendet und dann ein SAN Zertifikat bei einem Anbieter gekauft. War viel Aufwand für nichts.

@viragomann: Nicht wirklich - im verlinkten Thread ist erklärt, dass es bei ACME dank DNS-Alias-Mode nur eine einzige updatefähige Domain braucht, um ggf. mehrere mit DNS-01 zu bedienen. Angesichts der buchstäblich zig verschiedenen DNS-Update-Methoden in OpnSense sehe ich echt nicht, wo das Problem liegt. Um nur ein Beispiel zu nennen, ohne wirklich dafür werben zu wollen: Hetzner bietet eine eigene API, die unterstützt wird und bei denen eine .DE-Domain gerade mal 3,90€ im Jahr kostet - das ist mutmaßlich billiger als Dein SAN-Zertifikat, dem aktuelle Browser bald eh nicht mehr trauen, weil es zu lange läuft.

Und: die verwendete Domain für den DNS-Update kann, wie gesagt, auch eine ausschließlich für diesen Spezialzweck genutzte sein - die muss nicht einmal bei einem Hoster liegen, der das eventuell eben nicht kann. Man muss im DNS der Wildcard-Domains nur einen einzigen CNAME auf die updatefähige Domain eintragen... Patrick hat das gerade getan und es ist wirklich einfach. Er hat dafür keine zusötzliche  Domain genutzt, sondern eine Sub-Domain auf einen Cloud-Host-DNS mit ACME-DNS delegiert. 

Und was die Ausfallsicherheit angeht: Aktuell muss Du alle 90 Tage updaten. In baldiger Zukunft alle 30 Tage. Solange der Update also nicht monatelang ausfällt: kein Problem.
Intel N100, 4 x I226-V, 16 GByte, 256 GByte NVME, ZTE F6005

1100 down / 800 up, Bufferbloat A+

Quote from: meyergru on May 06, 2025, 08:49:17 PMMan muss im DNS der Wildcard-Domains nur einen einzigen CNAME auf die updatefähige Domain eintragen
Diesen Teil hatte ich bislang noch nicht verstanden. Ist das irgendwo ausführlicher erklärt?

Die DNS Challenge setzt ja einen TXT Eintrag in der Domain, für welche ein Wildcard-Zertifikat angefragt wird.
Also meine Domain: meineDomain.tld.
Der Zert-Aussteller sucht in tld nach dem zuständigen Nameserver und bekommt den von meinem DNS Provider. Diesen fragt er dann nach dem jeweiligen TXT Record in meineDomain.tld
Wie ein CNANE diesen überzeugen kann, einen anderen DNS Server abzufragen, ist mit nicht klar.

May 06, 2025, 09:12:00 PM #11 Last Edit: May 06, 2025, 09:15:37 PM by Patrick M. Hausen
Jein ...

Du konfigurierst bei deinem normalen Provider einen festen CNAME Eintrag:

$ dig _acme-challenge.hausen.com

[...]
;; ANSWER SECTION:
_acme-challenge.hausen.com. 14400 IN CNAME 9fb3ffc1-e14e-4971-bf5f-ef679b0a4d36.acme.hausen.com.

Und dann konfigurierst du deinen ACME-Client so, dass er auf dem ACME-DNS-Server in der gezeigten Domain die TXT-Records einträgt.

Und natürlich kannst du auch
_acme-challenge.viragomann.de. IN CNAME 9fb3ffc1-e14e-4971-bf5f-ef679b0a4d36.acme.hausen.com.
anlegen. Und dann denselben ACME-DNS-Server für N Domains benutzen. Mit ein und demselben Account (das ist diese GUID für die Subdomain) oder mit jeweils einem eigenen, ganz wie du willst.

Daher braucht der Provider, wo du deine "echte" Domain hostest, gar kein API. Du hast einen API-fähigen Server für alle deine Domains.

P.S. Eine Feinheit natürlich noch: acme.hausen.com ist eine eigene Zone, mit A, AAAA und NS-Records. Und die zeigen alle auf diesen Cloud-VPC mit dem acme-dns Dienst.
Deciso DEC750
People who think they know everything are a great annoyance to those of us who do. (Isaac Asimov)

Super! Danke. :-)

Habe in dem verlinkten Tread und auf Github schon weiter gelesen. Die Zone ist der Trick. Das sollte hinzubekommen sein.

Grüße

May 06, 2025, 09:23:09 PM #13 Last Edit: May 06, 2025, 09:25:58 PM by meyergru
Indem Du den CNAME für _acme-challenge.domain.xy auf irgendeine DNS-Update-Domain, z.B. update.update-domain.xy richtest. Mach mal eine nslookup auf _acme-challenge.congenio.de. Wenn Du vom Ergebnis weiter schaust, wirst Du sehen, dass die DNS-Update-Domain _acme-challenge.name2ip.net andere Nameserver hat als die übergeordnete Haupt-Domain name2ip.net (die ist bei Hetzner). In der DNS-Update-Domain musst Du übrigens nicht unbedingt _acme-challenge.update-domain.xy verwenden, der Name ist beliebig.

Der ACME.SH DNS-Alias Mode kann automatisch die DNS-Update-Domain per DNS finden, weil er einfach _acme-challenge.domain.xy abfragt.

Ist alles auch hier erklärt. In OpnSense sagst Du dann nur "DNS Alias Mode" bei der DNS-01 Verifikation und alles funzt.

Vielleicht wäre auch dafür ein Tutorial angezeigt...


Intel N100, 4 x I226-V, 16 GByte, 256 GByte NVME, ZTE F6005

1100 down / 800 up, Bufferbloat A+

Danke für die ausführliche Erklärung.

Hab es verstanden und merke es mir vor für den Fall, dass wieder mal der Bedarf da ist. Das gekaufte SAN-Zertifikat läuft ja auch mal aus. :-)