[gelöst] Fragen zu Letsencrypt, FQDNs, HA Proxy

[mzurhorst]

Hallo zusammen,

ich fräse mich seit vielen Wochen erfolglos durch Beiträge, Tutorials und Youtube-Videos, und ich bekomme bei mir Letsencrypt einfach nicht gescheit ans Laufen. Irgendwo habe ich evtl. einen Denkfehler.

Was ich habe:

• OPNsense 22.7.2 verbunden mit dem Internet
• meine dynamische IP wird korrekt bei DuckDNS aktualisiert
• Intern verwende ich eine Domain (zurhorst.baerl).
• Extern habe ich eine Domain (die-zurhorsts.de)
• Da habe ich eine Subdomain (baerl.die-zurhorsts.de) eingerichtet; CNAME zeigt auf DuckDNS

Was ich möchte:
Die OPNsense selbst sowie diverse Server hinter der Firewall möchte ich mit Letsencrypt Zertifikaten absichern.
Manche Dienste sind rein intern, wenige andere sollen auch von extern erreichbar sein.


Problem 1:
Was sind geeignete Hostnamen für mein internes Netwerk?

• Ich habe begonnen mit zurhorst.baerl.  Die Maschinen heißen dann opnsense.zurhorst.baerl,  database.zuhorst.baerl, ...   Alle Maschinen werden über den Unbound DNS aufgelöst und das klappt alles.
• Dann habe ich die Maschinen umbenannt in FQDNs:  opnsense.baerl.die-zurhorsts.de, database.baerl.die-zurhorsts.de, ... etc.,  weil ich dachte, dass ich nur so ein LE Zertifikat erhalten könnte. Das hat aber nicht geklappt.
• Ich habe wieder alles zurück geändert per Rat aus dem administrator.de Forum, und bin nun wieder bei der zurhorst.baerl  internen Domain.  Aber egal wie ich es mache, ich bekomme die LE Zertifikate nicht hin.
• Nach noch mehr lesen glaube ich inzwischen auch, dass ich doch nochmal auf die FQDNs umbauen muss.  Aber das möchte ich wirklich erst machen, wenn ich sicher weiß, dass das nötig ist.  Zumal die Namen dann unpraktisch lang werden.

Gibt es da noch einen Trick, wie ich intern mit den LE Certs arbeiten kann, und gleichzeitig die Namen kurz sind? -- Evtl. eine Umschreibung im Unbound DNS?

Problem 2:
LE Zertifikat-Erzeugung mit DNS-01 Challenge oder HTTP-01 Challenge?

Hier habe ich inzwischen eine Idee, aber ich bin auch hier verunsichert inzwischen:

• Für nur interne Server würde ich wohl die DNS-01 Challenge benötigen, um den TXT-Record bei DuckDNS per API zu ändern.
• Für von extern erreichbare Server kann ich nun entweder:
  
  
  
  • OPNsense alles erledigen lassen und SSL Offloading im HA Proxy nutzen.
  • Oder ACME-Client direkt auf dem Server laufen lassen.  (evtl. bei Bitwarden vorteilhaft, damit die "letzte Meile" auch noch verschlüsselt ist)
• Ich denke, dass ich doch umbedingt auf die FQDN Benennung zurück muss, damit LE-Zertifikate ausgestellt werden können. Es gibt viele Tutorials zum Thema "LE für interne Server", aber die sagen nicht explizit, dass es nur mit einem FQDN klappt.

Was ich hier nicht verstehe:  wenn OPNsense die Zertifikate zentral besorgt:  wie bekomme ich diese auf die jeweiligen Server drauf?
Und stimmt das so, was ich hier zusammen gesammelt habe?


Problem 3:
Ich habe einen Apache laufen unter testweb.baerl.die-zurhorsts.de.  Der antwortet sowohl auf http als auch https://
Allerdings fällt mir auf, dass er trotz SSL-Verschlüsselung (mit der LE Test CA) nur die unverschlüsselte Webseite anzeigt.  (Ich habe die index.html geändert, da steht "Port 80" im Text;   und für https eine zweite Datei angelegt.)

Meine Interpretation:  das SSL-Offloading im HA-Proxy verschlüsselt die Verbindung nur bis zum HA-Proxy, und von da aus geht es über :80 weiter zum Server.

Wie würde ich das Zertifikat nun bis auf den Webserver drauf bekommen?


Problem 4:
Ich suche noch einen Weg, wie ich die OPNsense gerne weiterhin per Port 443 erreichbar halten könnte, ausschließlich aus dem LAN heraus, aber nicht über WAN.
Das Umbenennen des Ports gefällt mir nicht.

Kann ich im HA Proxy eine Regel einrichten, welche mich weiterleitet zum Web Interface auf der Firewall selbst? -- Oder muss ich wirklich bei dem "umgebogenen" Port bleiben, sobald der HA-Proxy sich für den Port 443 verantwortlich fühlt? -- Die OPNsense soll auf keinen Fall von extern erreichbar sein.



Jeder Tipp ist willkommen. Ich würde das Thema so gerne hinter mir lassen, aber je länger ich mich damit auseinander setze, desto verwirrter bin ich nur noch.


Herzlichen Dank und viele Grüße,
  Marcus

[mt]

Ich les mal gespannt mit, das Thema kommt auf mich auch noch zu. Ich hab leider noch keine großartige Erfahrung diesbezüglich, mit OPNSense, kann dir aber allgemein ein paar Fragen beantworten, wie das allgemein oder bei meinem jetzigen, strukturell ähnlichen System funktioniert.
Vorweg: Die LE Zertifikate sollen dem Client/Browser bestätigen, dass Domainname und Seitenbetreiber zusammengehören. Wenn sie das nicht mehr tun, wird dein Browser das für ungültig/Betrug halten. Du kannst z.B. nicht ein Zertifikat für hanswurst.de beantragen und dich dann als Sparkasse-Hamburg.de bezeichnen.
Insofern sollten die internen Maschinen unter den Domains, die in ihren Zertifikaten stehen, erreichbar sein.
Ausschlaggebend ist, was im DNS steht, nicht der Hostname der Maschine.
Zu Problem 1 und 2:
Es gibt (meiner Meinung nach mindestens) 2 Wege, um den Traffic bis zu den Internen zu verschlüsseln:
1. Alles mit FQDN (intern und extern gleich) und die Zertifikate vom Proxy aus bei LE anfordern und auf die Internen kopieren (Cron-Job). Pro: Alle Clients akzeptieren auch intern automatisch die Zertifikate. Con: Cron-Jobs nicht immer möglich, dann muss man Zertifikate kopieren und je nach Vertrauenswürdigkeit der internen Maschinen auch den Zugriff auf andere Zertifikate unterbinden usw.
2. eigene Domain intern lassen und selbst CA erstellen, selbst für die Internen Zertifikate erstellen und mit der CA signieren (z.B mit XCA). CA-Cert bei OPNSense hinterlegen. Von Proxy dann LE Certs für Verbindungen nach außen anfordern.
Pro: Keine Kopiererei, Zertifikate länger gültig (einstellbar). Zertifikate auch für nur interne Server erhältlich. Con: Alle Clients/Browser müssen erstmal einmalig das CA-Zertifikat importieren, bevor sie die damit signierten Zertifikate akzeptieren.
Zu 3: Das wäre jetzt raten. Hast du https:// genommen? Fehlt ein redirect 80->443? Hast du mod_ssl aktiviert? Was sagen die Logs, ist das hier überhaupt das richtige Forum?
Zu 4: Ohne das je mit OPNSense gemacht zu haben, würde ich behaupten: Ja das geht, sofern du darauf verzichten kannst, den Proxy am LAN Interface lauschen zu lassen. Deine OPNSense bekommt einen Namen und ein zugehöriges Zertifikat, einen internen DNS-Eintrag und eben keine Regel im Proxy. Wenn du die Admin-Seite aus dem LAN besuchen willst, antwortet OPNSense, von WAN kommt keiner dran, weil es keine Proxy Regel gibt. Du solltest beim Admin Interface einstellen, dass es nur aus dem LAN erreichbar ist. Sicherheitshalber von außen (Handy...) mit an- und abgeschaltetem Proxy prüfen.

[micneu]

@mzurhorst ich hatte vor ein paar jahren ein gutes howtoo über google gefunden wie man LE & HAProxy einrichtet (einfach googlen mit den richtigen schlüssel worten) das ding war sogar in deutsch.

zu der frage wie du die zertifikate von LE auf deinen webserver bekommst: garnicht da kümmert sich der HAProxy drum, denn der macht das alles (selbst den redirect von 80 —> 443

ich denke du hast das Konzept dahinter noch nicht verstanden

zu den host fqdn ist bei mir so gelöst:

intern: in.meine.de
extern: so wie es für mich sinnvoll war .meine.de
und dienste die intern und extern sind habe einen
host overwrite angelegt der auf die interne ip zeigt

Gesendet von iPad mit Tapatalk Pro

[Patrick M. Hausen]

Man kann auch für interne Hosts ohne Verbindung nach außen Let's Encrypt automatisieren. Dazu sind zwei Dinge nötig:

1. Man muss DNS-01 verwenden, da es ja keine Verbindung zu dem internen Host gibt.
2. Für den FQDN des internen Hosts muss es einen Eintrag im Internet geben, der z.B. auf einen selbstbetriebenen acme-dns Server zeigt.

Machen wir in der Firma so. Es gibt jede Menge Einträge unter punkt.hosting im weltweiten DNS, die nur einen CNAME-Eintrag auf den acme-dns haben.

Zuletzt: ich empfehle für private Domains nicht irgendwelche Fantasie-TLDs zu benutzen. Man weiß ja nie, wann die ICANN mit .baerl als neuer Toplevel-Domain um die Ecke kommt.

Besser man nimmt eine Domain, die man tatsächlich besitzt, bei meiner Firma z.B. punkt.de - und packt dann alles im Hausnetz und das Windows-AD etc. pp. in die Domain intern.punkt.de - da gibt es nie einen Konflikt und die kommt im Internet garantiert nicht vor.

HTh,
Patrick

[mzurhorst]

Ok, das habe ich fast befürchtet. Das bedeutet, ich ändere die Hostnamen nochmal alle in FQDNs um.
Die Frage, ob oder ob nicht ein Dienst dann erreichbar ist von außen, das hängt dann ja lediglich an der HA Prox Konfiguration, welcher eben drauf reagiert oder es nicht tut.

Dann fange ich mal an.  ;-)

[mzurhorst]

Insofern sollten die internen Maschinen unter den Domains, die in ihren Zertifikaten stehen, erreichbar sein.
Ausschlaggebend ist, was im DNS steht, nicht der Hostname der Maschine.

Hi mt, diesen Satz verstehe ich nicht.
Der Hostname ist "database", und er wird doch dann ergänzt um eine Domain.
Meine Fantasie-Domain zuhorst.baerl, die wird doch von meinem Unbound DNS Server beantwortet.  Im Falle der echten Subdomain baerl.die-zurhorsts.de wäre der DNS Server von Netcup zuständig.

Wie kann da der Hostname nicht relevant sein?

[mt]

Ok, das liegt an der Mehrfachbelegung des Begriffs "Hostname".
Irrelevant ist, was der Befehl hostname oder hostname -fqdn auf dem Host ausgibt (macht es aber übersichtlicher). Wichtig ist, dass der DNS-Eintrag für den Host mit dem FQDN im Zertifikat übereinstimmt. Sowohl intern als auch extern.
Zu dem weiteren Teil meiner Aussagen, muss ich einschränken, dass ich von einem Szenario ausgegangen bin, wo der Traffic aus dem LAN nicht über den HAProxy läuft. Folglich kann auch der HA-Proxy nicht auf magische Weise gültige Schlüssel an die Server verteilen.
Wer spricht mit wem:

Code Select Expand


        WAN
           |
         OPNSEnse und HAProxy
           |         |
      Clients----Server

Was micneu mit

wie du die zertifikate von LE auf deinen webserver bekommst: garnicht da kümmert sich der HAProxy drum, denn der macht das alles (selbst den redirect von 80 —> 443

glaube ich meinte würde eher so aussehen

Code Select Expand


        WAN
           |
         OPNSEnse und HAProxy
           |         |
      Clients    Server

Der Unterschied ist, ob dein lokales DNS die FQDN vom LAN aus auf den HAProxy auflöst oder auf deine Server.
Wenn auf HAProxy, pro: musst dir um anerkannte Schlüssel auf den Servern keine Gedanken machen, machst CA, signierst selbst Certs und importierst CA-Cert im Proxy. Con: gesamter HTTPS-Traffic aus LAN über Proxy.
Wenn du FQDN auf die Server auflöst, dann brauchen die alle ein gültiges Zertifikat, dafür LAN HTTPS Traffic direkt zwischen Client und Server.

[mzurhorst]

Oh weh, nun hast du mich komplett abgehängt.    :o
Ich muss da langsamer ran gehen, damit ich mit komme.

Ich habe nun erst mal meine VMs alle umbenannt auf  <hostname>.baerl.die-zurhorsts.de
Das hat auch einigermaßen zügig geklappt, und die Verbindungen untereinander nutzen nun die neuen FQDNs.

Dann habe ich HA Proxy konfiguriert.  Dieser ist aber insgesamt sehr zickig. Ich hatte mindestens 2x das Problem, dass er die Konfig zerschossen hat, und ich das auch nicht mehr gelöst bekommen habe im Webfrontend.

Aber jedenfalls habe ich nun erfolgreich zwei VMs auf Port 80 erreichbar.
Die OPNsense ist aber "leider" ebenfalls von außen erreichbar. Das möchte ich ganz sicher nicht!

Kann ich die OPNsense selbst auf einen anderen Port legen, und dann über den HA Proxy darauf zugreifen, so dass ich mir den Port nicht merken muss?  --- Oder klappt das nur mit Weiterleitungen an externe Services?

Und sobald ich Letsencrypt nutzen möchte, dann klappt jedes Mal gar nichts mehr.
Da werde ich nicht schlau draus.  Selbst eine vermeintlich einfachere HTTP-01 Challenge klappt nicht für diese VMs, obwohl sie ja aus dem Internet schon erreichbar sind.  >:(

[mzurhorst]

Ich habe eine interessante Beobachtung gemacht zu HAProxy:

• Aus dem Internet ist mein EVCC Server direkt erreichbar ohne Portangabe:  evcc.baerl.die-zurhorsts.de.  HAProxy leitet dass dann an mein Backend an den Port 7070 weiter.
• Aber hier daheim im Netzwerk klappt das nicht, da muss ich noch  :7070 dahinter hängen.

Das bedeutet wohl, dass mein Netzwerk am HAProxy vorbei kommuniziert.
Und das ist extrem verwirrend, weil ich nun mit dem Namen durcheinander komme.  Bei diesem Namensschema bin ich auf einem Holzweg, scheint mir.   :-\

[mt]

Oh weh, nun hast du mich komplett abgehängt.    :o

Du hast ja auch mit einer ganzen Liste von Problemen mit vielen unbekannten Faktoren losgelegt.

Die OPNsense ist aber "leider" ebenfalls von außen erreichbar. Das möchte ich ganz sicher nicht!

Kann ich die OPNsense selbst auf einen anderen Port legen, und dann über den HA Proxy darauf zugreifen, so dass ich mir den Port nicht merken muss?  --- Oder klappt das nur mit Weiterleitungen an externe Services?

Schau doch als erstes mal unter System->Settings->Administration nach, ob Listen Interface auf LAN gesetzt ist.

Als nächstes entscheidest du dich, ob deine Clients aus dem LAN direkt auf die Server zugreifen sollen oder über HA Proxy.

[mzurhorst]

Ok. Das Listen Interface steht auf "All (Recommended)" in der Voreinstellung.  Hier habe ich jetzt die DMZ und das WAN-Interface ausgeklammert.  Das funktioniert schon mal.

Mir scheint, dass intern ein Zugriff ohne HAProxy sinnvoller ist, damit dieser sich ausschließlich um eingehenden WAN-Traffic kümmert und es nicht noch komplizierter wird.

[Patrick M. Hausen]

Dann hast du intern und extern aber unterschiedliche URLs, da du intern die Portnummern dran kleben musst. Gibt es einen speziellen Grund dafür? Weshalb betreibst du deine Anwendungen nicht intern wie extern auf 80/443?

Ich habe meine ganzen Anwendungen übrigens ohne SSL auch auf jeder Menge verteilter Ports und greife auch von intern über einen Reverse-Proxy auf Port 443 zu. Die OPNsense unterstützt im "Hairpin NAT", d.h. du greifst von intern auf die externe Adresse zu und wirst wieder nach innen geleitet.

Du kannst also beides tun. Ich würde im LAN dann aber gucken, die "komischen" Ports wegzukriegen, wenn das ohne HA-Proxy laufen soll.

[mzurhorst]

Das ist ein guter Punkt.

Das Thema ist beliebig komplex und wächst mir gerade über den Kopf.
Habe mich gestern Abend nochmal hin gesetzt und überlegt, wozu ich überhaupt die ganze Gymnastik machen wollte.  Im Grunde störe ich mich in allererster Linie an der Warnung des selbst erzeugten Zertifikats.
Aber nun wird die Baustelle immer größer, nur weil ich zu bequem bin, um mir das Root-Zertifikat meiner CA auf eine handvoll Geräte zu packen.
Scheint irgendwie kein guter Deal zu sein wenn die Zeit ein kostbares Gut ist    ;D

Gibt es einen Weg, wie man diese Zertifikate in der Kommunikation "anbieten" kann? -- So nach dem Motto: "Mein Service --> meine Regeln!"   --- Dann könnte man auf den Endgeräten selbst entscheiden, ob oder ob nicht man meiner CA vertrauen möchte.
(ich betreibe ja nichts kommerzielles mit vielen Kunden, sondern was privates mit einer handvoll Besucher auf einem Web-Service)

[Patrick M. Hausen]

Jag doch alles, auch von innen, durch den Proxy mit Letsencrypt. Das schadet doch nicht.

[mzurhorst]

Mir ist noch nicht mal klar, wo genau ich das einstelle, ob oder ob nicht etwas durch den HA Proxy durch geht.
Ein Listening Interface hat der ja in seinen Settings nicht.
Würde ich dann weitere Conditions und Rules auf das gleiche Backend routen?

Insgesamt ist mir der HA Proxy auch etwas "wackelig".  Gerade funktionierten meine beiden Test-Server nicht, ohne dass ich was aus dem Log entnehmen konnte.  Einmal abschalten, wieder anschalten, alles klappt wieder.
Die Server waren aber parallel mit ihrer "komischen" Adresse + Port erreichbar.