ACME Methode: Welche am einfachsten für Zuhause

pixel24

Hallo zusammen,

ich richte mit Zuhause gerade ein neues Netzwerk ein. Auf einer früheren Installation im Büro habe ich ACME + HA-Proxy eingerichtet. Dort habe ich im LAN einen extra FTP-Server aufgesetzt für ACME.

Zuhause würde ich mir das gerne sparen. Für Zuhause habe ich eine Domain bzw. Subdomains bei Strato. Die DDNS-Aktualisierung läuft nun soweit.

Nun fange ich an ACME und HA-Proxy einzurichten und würde gerne die einfachste Variante verwenden. Im Web finde ich diverse Anleitungen was die Methode betrifft: "Webroot local Folder" , "Standalone HTTP Server" ....

Welche ist denn ein guter Kompromiss zwischen Einfachheit & Sicherheit bzw. was für mein Setup zu empfehlen?

Beste Grüße
pixel24

JeGr

@pixel24 said in ACME Methode: Welche am einfachsten für Zuhause:

Zuhause würde ich mir das gerne sparen. Für Zuhause habe ich eine Domain bzw. Subdomains bei Strato. Die DDNS-Aktualisierung läuft nun soweit.

Braucht man auch nicht unbedingt :)

@pixel24 said in ACME Methode: Welche am einfachsten für Zuhause:

Welche ist denn ein guter Kompromiss zwischen Einfachheit & Sicherheit bzw. was für mein Setup zu empfehlen?

Standalone HTTP. Den baut man sich auf einen Fremdport, bspw. 4001. Dafür baut man sich dann in HAproxy ein Backend das nicht gecheckt wird und daher quasi always on ist. Dann baut man sich ein HTTP Frontend (oder hat schon eines) und baut sich da die Logik rein, dass eine ACME Anfrage erkannt wird (wenn Path /.well-known/...blablabla... enthält) und schickt das auf das konfigurierte ACME Backend.

Resultat ist, dass alle http/80 Anfragen gegen die externe IP beim HAproxy landen, der diese prüft und die ACME Anfragen mit /.well-known... an das ACME Backend auf 4001 weiterleitet. Wenn das ACME Plugin läuft, startet es den Server auf 4001 und der nimmt dann den request zum verify an - done deal. Läuft kein ACME Plugin ist der Port schlicht nicht in use und gibt keine Antwort - timeout für alle die es probieren. Da aber default nichts auf irgendwelche random high ports hört, macht man sich da nicht zufällig einen Dienst auf der nicht offen sein soll.

Alternative wenn man kein Port 80 haben will sondern alles NUR noch HTTPS only läuft (auch ohne redirects und Kram) und man deshalb HAproxy nur noch für 443 konfiguriert:

Immer noch Standalone aber Port 80 machen, eine Regel anlegen auf Port 80 von any, der Traffic zulässt. Dann ACME testen - sollte gehen. Anschließend den Cron von ACME aktivieren und nachschauen: der läuft normalerweise um 3:16 jede Nacht.
Dann einen Schedule erzeugen, der 3:15 bis 3:30 täglich definiert und diesen an die gerade gebaute Regel hängen.
Resultat: Port ist von 3:15 bis 3:30 offen, ACME kann laufen, danach ist der Port wieder zu.

Geht beides, kommt drauf an was man will/braucht :)

Cheers

pixel24

@jegr said in ACME Methode: Welche am einfachsten für Zuhause:

Alternative wenn man kein Port 80 haben will sondern alles NUR noch HTTPS only läuft (auch ohne redirects und Kram) und man deshalb HAproxy nur noch für 443 konfiguriert:

Kennt jemand zu der Umsetzung dieser Variante in pfSense eine Anleitung?

pixel24

@jegr said in ACME Methode: Welche am einfachsten für Zuhause:

Standalone HTTP. Den baut man sich auf einen Fremdport, bspw. 4001. Dafür baut man sich dann in HAproxy ein Backend das nicht gecheckt wird und daher quasi always on ist. Dann baut man sich ein HTTP Frontend (oder hat schon eines) und baut sich da die Logik rein, dass eine ACME Anfrage erkannt wird (wenn Path /.well-known/...blablabla... enthält) und schickt das auf das konfigurierte ACME Backend.

Also ist das der erste Schritt. Noch bevor ich im ACME irgendwelche Zertifikate erzeuge erstelle ich im HA-Proxy das Backend für die acme-challenge. Ist das korrekt?

pixel24

So bin ich jetzt vor gegangen:

++ HA-Proxy ++

Für ACME +

Dienste -> HA-Proxy

-> Backend
-> Hinzufügen

Name: acme-challenge

Server list +

Name: localhost
Address: 192.168.xx.254 (LAN IP der pfsense)
Port: 4001

-> Speichern

-> Frontend

-> Hinzufügen

Name: acme-challenge

Access Control lists +

Name: acme-challenge
Expression: Path contains within slashes
Value: .well-known/acme-challenge/

Aktion +

Action: Use Backend
Conditional: acme-challenge

pixel24

Zusätzlich habe ich an der Firewall noch folgende Einstellungen vorgenommen:

Wobei der DDNS-Eintrag für test.meinedomain.de bei Strato korrekt ist (37.xx.1x.169 = WAN-IP der pfSense)

test.meinedomain.de
Renewing certificate
account: test
server: letsencrypt-staging-2
/usr/local/pkg/acme/acme.sh --issue --domain 'test.meinedomain.de' --standalone --listen-v4 --httpport '4001' --home '/tmp/acme/test.meinedomain.de/' --accountconf '/tmp/acme/test.meinedomain.de/accountconf.conf' --force --reloadCmd '/tmp/acme/test.meinedomain.de/reloadcmd.sh' --log-level 3 --log '/tmp/acme/test.meinedomain.de/acme_issuecert.log'
Array
(
[path] => /etc:/bin:/sbin:/usr/bin:/usr/sbin:/usr/local/bin/
[PATH] => /etc:/bin:/sbin:/usr/bin:/usr/sbin:/usr/local/bin/
[port] => 4001
[ipv6] =>
)
[Fri Feb 4 14:41:09 CET 2022] Using CA: https://acme-staging-v02.api.letsencrypt.org/directory
[Fri Feb 4 14:41:09 CET 2022] Standalone mode.
[Fri Feb 4 14:41:10 CET 2022] Registering account: https://acme-staging-v02.api.letsencrypt.org/directory
[Fri Feb 4 14:41:13 CET 2022] Already registered
[Fri Feb 4 14:41:13 CET 2022] ACCOUNT_THUMBPRINT='8CJXL5TUGu2-FQwx2TCm-N2GqU6Imz8Igs25B2MqN2M'
[Fri Feb 4 14:41:13 CET 2022] Single domain='test.meinedomain.de'
[Fri Feb 4 14:41:13 CET 2022] Getting domain auth token for each domain
[Fri Feb 4 14:41:14 CET 2022] Getting webroot for domain='test.meinedomain.de'
[Fri Feb 4 14:41:14 CET 2022] Verifying: test.meinedomain.de
[Fri Feb 4 14:41:14 CET 2022] Standalone mode server
[Fri Feb 4 14:41:19 CET 2022] Pending
[Fri Feb 4 14:41:21 CET 2022] test.meinedomain.de:Verify error:Invalid response from https://test.meinedomain.de/.well-known/acme-challenge/sQcRcys0DkK94ji6VMwfNhYdcr26SvXaBYVHsiyN1OY [37.xx.1x.169]:
[Fri Feb 4 14:41:21 CET 2022] Please check log file for more details: /tmp/acme/test.meinedomain.de/acme_issuecert.log

pixel24

ok, es funktioniert. In diesem Setup passiert doch der Challenge ankommend auf Port 80 vom WAN-Interface der pfSense und wird durch das Backend auf den lokalen Webserver auf Port 4001 geleitet.

Habe ich das korrekt verstanden?

Ist die Verbindung dann unverschlüsselt?

pixel24

@jegr said in ACME Methode: Welche am einfachsten für Zuhause:

Alternative wenn man kein Port 80 haben will sondern alles NUR noch HTTPS only läuft (auch ohne redirects und Kram) und man deshalb HAproxy nur noch für 443 konfiguriert:
Immer noch Standalone aber Port 80 machen, eine Regel anlegen auf Port 80 von any, der Traffic zulässt. Dann ACME testen - sollte gehen.

Könntest Du mir das noch kurz erklären?

Ich ändere hier zunächst im Backend:

den Port 4001 auf 443

Und im Backend:

mache ich aus Port 80 auch 443?

JeGr

@pixel24 said in ACME Methode: Welche am einfachsten für Zuhause:

ok, es funktioniert. In diesem Setup passiert doch der Challenge ankommend auf Port 80 vom WAN-Interface der pfSense und wird durch das Backend auf den lokalen Webserver auf Port 4001 geleitet.

Habe ich das korrekt verstanden?

Ist die Verbindung dann unverschlüsselt?

Ja wie soll es sonst funktionieren? Du willst ja erst ein Zertifikat ausgestellt haben - wie sollst du dann auf GENAU der Domain ein bereits funktionierendes Zertifikat haben? Geht ja schlecht, da würde sich die Katze in Schwanz beißen. Natürlich sind die normalen ACME Zugriffe unverschlüsselt, es geht ja lediglich um die Verifizierung, dass die Domain die gerade angefragt wird auch "dir gehört" sprich den ACME Challenge Code zurückgibt der erwartet wird um zu bestätigen, dass das der zugehörige Service ist. Hier wird nichts übertragen, was auch nur irgendwie interessant ist, lediglich ein einziger Test-Hast in einer Datei die zufällig erzeugt wird. :)

@pixel24 said in ACME Methode: Welche am einfachsten für Zuhause:

Könntest Du mir das noch kurz erklären?

Da hast du was mißverstanden. Wenn du in HAproxy NUR noch TLS machst, dann machst du da auch kein HTTP Frontend und nix mehr. Dann darfst du aber auch wirklich nichts mehr mit HTTP auf der Kiste machen außer LetsEncrypt. Wenn das der Fall ist, kannst du den Standalone Port in der ACME Konfiguration von xxxx auf 80 ändern und machst einfach nur noch eingehend eine Firewall Regel, die von Any nach WAN_address Port 80 erlaubt. Da viele aber nicht einfach Port 80 einfach so aufmachen wollen, kann man diese Regel via einem Scheduler nur nachts beim LE Durchlauf aufmachen lassen - das war der Port mit dem Schedule erstellen - und dann ist da sonst außer 443 nix auf bis auf nachts für 15min kurz Port 80 für ACME LE Durchlauf.

in HAproxy musst du dann zum ACME Backend gar nichts mehr machen.

pixel24

@jegr ok, verstanden soweit.

Wo ich noch ein Problem mit diesem Testsetup habe ich das fehlende NAT-Reflection.

Beim alten Setup wo dies aktiv ist konnte ich 'subdomain.externedomain.de sowohl von außen wie von innen aufrufen. Ich habe immer das LE-Zertifikat "serviert" bekommen.

Nun ist NAT-Reflection ja aus. Ich komme von extern per HTTPS auf den Zielhost anhand der Subdomain & HA-Proxy.

Über: Dienste -> DNS-Auflösung -> Host Überschreibung habe ich ja für alle Subdomain die Zuordnung zur internen IP hergestellt.

Hier ist ja der HA-Proxy raus aber ich bekomme beim Zugriff auf den Host aus dem LAN ja auch ein selbstsigniertes Zertifikat präsentiert.

Ich könnte mir vorstellen dass dies bei mobilen Geräten die z.B. an externedomain.de angebunden sind und mal innen und mal außen sind Probleme geben könnte.

Oder habe ich da was falsch verstanden?

JeGr

@pixel24 said in ACME Methode: Welche am einfachsten für Zuhause:

Wo ich noch ein Problem mit diesem Testsetup habe ich das fehlende NAT-Reflection.

Wofür das?

@pixel24 said in ACME Methode: Welche am einfachsten für Zuhause:

Nun ist NAT-Reflection ja aus. Ich komme von extern per HTTPS auf den Zielhost anhand der Subdomain & HA-Proxy.

So gehört es sich auch, ja :)

@pixel24 said in ACME Methode: Welche am einfachsten für Zuhause:

Über: Dienste -> DNS-Auflösung -> Host Überschreibung habe ich ja für alle Subdomain die Zuordnung zur internen IP hergestellt.

Wo hast du dann ein Reflection Problem wenn du Split-DNS machst?

@pixel24 said in ACME Methode: Welche am einfachsten für Zuhause:

Hier ist ja der HA-Proxy raus aber ich bekomme beim Zugriff auf den Host aus dem LAN ja auch ein selbstsigniertes Zertifikat präsentiert.

Ah also hast du kein Reflection Problem, sondern das Problem, dass wenn du direkt auf die Kisten zugreifst, du bei Termination auf dem Proxy natürlich nicht mehr unbedingt ein valides Zert bekommst. Joa gut. Das kann sein, habe ich in meinem Setup so aber nicht.

Da ich via DNS-01 zertifizieren kann und daher keinerlei HTTP ACME Zugriff brauche, kann ich problemlos Zertifikate auf den Hosts innen wie auch ein Kombo-Zert für den Proxy (SAN) erstellen lassen, womit dann alles einzeln oder über Proxy intern funktioniert. Wäre natürlich am schönsten so.

Wenn das nicht geht und man zwingend auf HTTP-Auth angewiesen ist, würde ich einfach der Firewall intern eine zweite IP geben. In welchem Netzsegment/VLAN etc. ist da eigentlich nur interessant, wenn du das sinnvoll aufteilen oder den Zugriff beschränken willst. Aber intern oder in einem internen Servernetz o.ä. einfach der Firewall eine 2. IP geben und das HTTPS Frontend zusätzlich zur WAN IP auch auf diese neue 2. interne IP binden. Kann man problemlos dem Frontend einfach hinzufügen, dann lauscht das Ganze plötzlich auch nach innen und man kann den DNS Override intern für die Hosts dann alle auf die neue interne IP setzen. Dann läuft auch intern alles über den Proxy nach gleichen Regeln wie von extern - was dann auch Testing und Debugging einfacher durchschauen lässt wenn nicht manche Geräte am Proxy vorbei reden :)

Alternativ kann man auch versuchen die Overrides zu löschen, theoretisch sollte es auch schlicht mit der externen IP gehen. NAT Reflection ist ja hier nicht mehr im Spiel, da keinerlei NAT/Port Forwarding mehr stattfindet. Daher würde auch von intern die externe IP auf der Firewall eigentlich problemlos erreichbar sein. Einzig wenn der Zugriff auf die externe FW IP aus irgendeinem Netz untersagt wäre, müsste man da eine Regel zu bauen, aber wenn man von innen nach außen die default Regel (alles erlauben) drin hat, sollte es da eigentlich keine Probleme geben. Persönlich finde ich es mit dem internen Binding fast noch angenehmer aber das ist IMHO Makulatur, gehen müsste beides. Manchmal kopieren wir auch das externe Frontend und erstellen für intern auf einer extra IP ein zweites, wo man dann noch weitere interne Adressen drauf packen kann für Dienste, die nur intern erreichbar sein müssen. Da macht dann ggf. eine interne IP und ein extra Frontend auch mehr Sinn :)

Cheers

pixel24

This post is deleted!

pixel24

This post is deleted!

pixel24

Ja, hat funktioniert auch wenn ich die Overrides lösche.

Denke so habe ich eine gute Ausgangsbasis. Ich muss mich da noch viel tiefer mit beschäftigen.

Vielen Dank an der Stelle für deine Gedult! Ich habe viele hier gelernt :-)

pixel24

Ein Problem mit diesem Setup dass mich schon länger beschäftigt ist folgendes:

Meine pfSense hat ja neben der LAN-IP (192.168.83.254) noch eine virtuelle LAN-IP (192.168.83.253) damit der HA-Proxy auf dieser lauscht.

Als Beispiel soll der Media-Server dienen. Dieser hat intern den FQH: media01.lan.irgendwas.club und 192.168.83.10.

Bei Strato habe ich eine Subdoman media.irgendwas.club angelegt und lasse diese per Dienst auf der pfSense dynamisch aktualisieren. Das funktioniert auch. Ebenfalls habe ich auf der pfSense eine LE-ZErtifikat eingerichtet für diese Subdomain.

Auf dem Media-Server läuft Jellyfin dass unter: https://media01.lan.irgendwas.club:8920 lauscht. Im HA-Proxy sieht das wie folgt aus:

Ich kann von inter (LAN) meinen Jellyfin-Server unter: https://media.irgendwas.club erreichen und bekomme ein gültiges ZErtifikat. Soweit alles gut.

Nun ist mir aber aufgefallen dass ich den Server aus dem LAN nicht mehr erreiche sobald die Internetverbindung mal ausfällt.

Sollte dies nicht durch den HA-Proxy der auf der virtuellen LAN-IP lauscht funktionieren?

Beste Grüße
pixel24

JeGr

@pixel24 Kann ich gerade nicht nachvollziehen. Dein Proxy hat ja auch die interne IP und dein DNS sollte intern dann logischerweise einen Overwrite für media.blubb.club auf die .253er Adresse machen damit die Adresse weiter aufrufbar ist. Warum das bei Ausfall WAN nicht mehr funktionieren soll, ist mir daher nicht klar, außer du hast etwas vergessen zu konfigurieren :)

Cheers

pixel24

Ja, irgend etwas muss ich übersehen bzw. vergessen haben. Die externe Domain (bei Starto) ist:

irgendwas.club

Der lokale DNS-Server (UCS) ist mit der Domäne_

lan.irgendwas.club

installiert. Der Media-Server ist lokal unter:

https://media01.lan.irgendwas.club:8920

erreichbar. Wenn ich nun aus dem LAN:

https://media.irgendwas.club

aufrufe wird ja nicht der UCS-DNS gefragt da dieser für diese Domain nicht zuständig ist. Also geht es zur pfSense. Dort lauscht der HA-Proxy ja auf der virtuellen LAN-IP (.253):

Im HA-Proxy (siehe oben) wird diese ja auch so angezeigt. Auf der pfSense ist DNS wie folgt konfiguriert:

ich weiß nicht was ich übersehen habe.

Beste Grüße

JeGr

@pixel24 Du hast nur einen Host Override gemacht. War das beabsichtigt? Du schriebst ja dass du *.lan.blah.club auf dem UCS aufgelegt hast. Du hast jetzt aber nur lan.blub.club konfiguriert mit der internen IP. Wolltest du nicht eigentlich alles mit *.lan auf den UCS umleiten?

Ansonsten ist das gerade alles etwas wirr und wir müssten mal konkret festhalten, was von wo wie aufgerufen wird oder werden soll, und wo was geht und wo nicht :) Dann sieht man vielleicht einfacher wo das Problem herrührt. Ansonsten vielleicht einfach mal zur Usergroup mit dazukommen am nächsten Freitag (5.8.)? Oder wenns gar nicht geht vielleicht mal melden, vllt. kann ich ggf. direkt mal ein paar Minuten helfen.

Cheers