Aug 02, 2022, updated at 12:50:47 (UTC)

5854

OPNsense mit Lets Encrypt Zertifikaten

Hallo IT Communitiy,

ich baue aktuell ein kleines Heimnetz mit einigen Sercices auf Basis von Docker Container auf. Als FW nutze ich OPNsense. Aktuell hader ich etwas mit dem Thema Zertifikaten, da ich auch im Heimnetz SSL verwenden möchte. Da ich einge Tablets, Smartphones aber auch diverse Notebooks etc. im LAN haben werde möchte ich nicht überall die Self-Sign Zerts. einspielen mit allem was dazu gehört. SSL möhte ich insb. für die OPnsense, AdGuard (direkt auf OPNsense), Portainer, Unifi, Nextcloud, Bitwarden nutzen. Aktuell Plane ich nicht irgendwelhe Service auch von Extern erreichbar zu machen. Dies soll später allerdings durch ein OPNvpn oder Wireguard erledigt werden.
Das bringt mich zu dem Gedanken Let`s Encrypt zu verwenden. Dazu habe ich allerdings noch einige Fragen die ich mir bisher nicht vollständig beantworten konnte.

Meine Idee ist:

TLD kaufen
Subdomain mit int.XYX.de oder lan.xyz.de etc. erstellen
Wild Card Zert für die TLD erstellen und dies auch intern nutzen
Brauche ich auch ein WIld Card für die Sub, als die int oder lan? Sollte doch eigtl. abgedeckt sein

Hier verstehe ich nicht ganz. Bei einer TLD würde ich als DNS Record meine Public IP eintragen was ich meinem Fall nciht mahen möchte / brauche da dieser case aktuell nicht vorhanden ist. Benötige ich überhaupt eine IP? Habe etwas von DNS challange gehört, was mit TXT records arbeitet, bekomme es aber nicht zusammen.

Dann ist noch die Frage wo erledige ich die Verwaltung und Verteilung der Zerts. Aufmerksam gerworden bin ich dadurch, dass OPNsense als Plugin ACME mitbringt mit dem ich die Verwaltung direkt auf der OPNsense erledigen könnte was natürlich super wäre.
Was ich eignetlich vorhattte war ein Nginx Proxy Manager insb. für die Docker Container Zerts zu nutzen. Dies hätte den "Vorteil", dass ich auf den COntainern keine Ports publizieren müsste. Nachteil aber, dass ich damit nicht die OPNsense und ADGuard versorgen kann, wenn ich es richtig verstanden habe. Erstellungs- Wartungsaufwand ist natürlich auch größer als mittels PlugIn direkt auf OPNsense.

Im Grunde stelle ich mir das so vor:

OPNsense hält alle Zerts (max. wohl 2)
Alle Anfragen laufen eh über die OPNsense
OPNsense übernimmt dann die "Vergabe" der Zerts für die Docker Container wie es der Nginx Proxy Manager tun würde

Vielleicht kann mir jemand etwas bei der Sortierung der Gedanken und richtigen Stichwörter helfen.

Please also mark the comments that contributed to the solution of the article

Kommentar vom Moderator colinardo am Aug 02, 2022 um 12:42:07 Uhr

Title eingedeutscht, deutlicher formuliert (für mehr Suchtreffer).

Content-Key: 3522202493

Url: https://administrator.de/contentid/3522202493

Printed on: April 26, 2024 at 15:04 o'clock

16 Comments

Latest comment

Servus @netzer2021 .

Zitat von @netzer2021:
Hier verstehe ich nicht ganz. Bei einer TLD würde ich als DNS Record meine Public IP eintragen was ich meinem Fall nciht mahen möchte / brauche da dieser case aktuell nicht vorhanden ist.

Musst du auch nicht. Bei einem Wildcard Zertifikat musst nur auf dem NS der Domain ein dynamisch generierter TXT Record für die Validierung hinterlegt werden, wofür aber eine API nötig ist.

Benötige ich überhaupt eine IP? Habe etwas von DNS challange gehört, was mit TXT records arbeitet, bekomme es aber nicht zusammen.

Wenn du Wildcard Zertifikate bei LE generieren willst brauchst du für die DNS-Validierungsmethode bei deinem DNS-Hoster eine API, denn Wildcard Zertifikate lassen sich nicht über die Web-Validierung ausstellen.
https://letsencrypt.org/de/docs/challenge-types/
Bietet dein Domain-Hoster keine API an bekommst du diese z.B. über https://desec.io/ kostenlos. Dabei leitest du dann deine Domain per NS Eintrag beim Anbieter bei den du die Domain hostest auf die DNS-Server von descec.io um und verwaltest dann dort die DNS-Einträge für diese Domain. Let's Encrypt hat die API von desec.io schon implementiert so das eine Validierung automatisch über das kurzzeitige Eintragen der TXT-Records bei desec.io geschieht. Gibt natürlich auch noch andere Anbieter wie Cloudflare & Co. die das anbieten.

Dann ist noch die Frage wo erledige ich die Verwaltung und Verteilung der Zerts. Aufmerksam gerworden bin ich dadurch, dass OPNsense als Plugin ACME mitbringt mit dem ich die Verwaltung direkt auf der OPNsense erledigen könnte was natürlich super wäre.

Wenn du sowieso auf ein Wildcard Zertifikat setzt, kannst du das das System deiner Wahl erledigen lassen du brauchst dann ja nur dieses eine Zertifikat, und nicht mehrere, denn du hast ja den privaten Schlüssel und kannst dieses dann auf so vielen deinen Systemen nutzen wie du willst.

Bedenke das ein Wildcard-Zertifikat nur für eine Subdomain Ebene gilt, also gültig für ein Wildcard von *.domain.tld wären
sub1.domain.tld = OKsub2.domain.tld = OK

Ungültig dagegen wären weitere Ebenen
deeper.sub1.domain.tld = UNGÜLTIG
Dafür bräuchtest du dann ein Wildcard für *.sub1.domain.tld.

Im Grunde stelle ich mir das so vor:

OPNsense hält alle Zerts (max. wohl 2)
Alle Anfragen laufen eh über die OPNsense
OPNsense übernimmt dann die "Vergabe" der Zerts für die Docker Container wie es der Nginx Proxy Manager tun würde

Wenn du die OPNSense als Reverse-Proxy nutzt musst du diese wie gesagt keine weiteren Zertifikate generieren lassen das Wildcard-Zertifikat kannst du problemlos auch intern auf so vielen Systemen einsetzen wie du willst. Private- und Public Key kannst von der OPNSense auf die Systeme deiner Wahl kopieren und auch dort einsetzen.
Ein ein internes Split-DNS leitet dann Anfragen an diese Domain direkt an die internen Systeme.

Hoffe das klärt einige deiner Fragen.

Grüße Uwe

Danke für das tolle Feedback Uwe.Hilft mir weiter. 👍

Kurz eine Frage zu der ReverseProx Funktion der OPNsense. Das wildcard Cert wird auf der opnsense gehalten. Wie bekommt denn ein Docker Container das Cert? Beispiel UniFi oder Nextcloud? Muss ich das dann dennoch unständlich einspielen? Wo wäre dann der Vorteil , außer keiner Browser Warnung? Ist wohl noch eine Wissenslücke 😉 wird z.B. auch eine Erneuerung automatisch ausgeführt?
Der Angina Proxy Manager übernimmt nach meinem Verständnis ja die Erneuerung und auch Verteiung der Certs an die Container.

Wie sieht das mit dem internen DNS aus? Aktuell arbeite ich mit Host overrides und Aliases da ich ja nur eine IP von Host habe aber mehrer Container laufen habe. Im LAN möchte ich eben mit DNS Namen statt IP arbeiten. Dieses Konzept und Vorgehen bleibt doch mit einem WildCard und Let’s Encrypt identisch oder ändert sich da was?

Zitat von @netzer2021:
Kurz eine Frage zu der ReverseProx Funktion der OPNsense. Das wildcard Cert wird auf der opnsense gehalten. Wie bekommt denn ein Docker Container das Cert? Beispiel UniFi oder Nextcloud?

Gar nicht, das ist ja der Vorteil eines Reverse Proxy der Client-Browser bekommt nur das Zertifikat des Reverse Proxies zu Gesicht, auf welchen Host dahinter weitergeleitet wird interessiert ihn nicht.
Der Proxy vermittelt nur anhand des Host-Headers zwischen Client und Hosts und das kann zwischen Proxy und Container/VM auch unverschlüsselt geschehen, was bei der Containerisierung in der Regel Standard ist.

wird z.B. auch eine Erneuerung automatisch ausgeführt?

Das ist Standard bei Let's Encrypt, ich will ja nicht alle 2-3 Monate immer wieder selbst Hand anlegen.

Der Angina Proxy Manager übernimmt nach meinem Verständnis ja die Erneuerung und auch Verteiung der Certs an die Container.

Es gibt viele Proxies-Varianten, welchen du nutzt bleibt dir überlassen 🙂.

Wie sieht das mit dem internen DNS aus? Aktuell arbeite ich mit Host overrides und Aliases da ich ja nur eine IP von Host habe aber mehrer Container laufen habe. Im LAN möchte ich eben mit DNS Namen statt IP arbeiten. Dieses Konzept und Vorgehen bleibt doch mit einem WildCard und Let’s Encrypt identisch oder ändert sich da was?

Bleibt gleich, du konfigurierst intern deine genutzte Domain, dazu deine A-Records die auf deine(n) Host(s) zeigen, fertig.
Die Verteilung an die Container übernimmt ja der Proxy anhand des Host-Headers (genutzter Domainname in der Adresszeile) wie gehabt.

Ok, super. Der Schuh formt sich 😂

Kann ich denn nicht eigentlich ein Wild Card direkt selber mit OPNsense erstellen und dennoch als Reverse Proxy nutzen? Dann blieben wohl die Browser Warnungen da der eigenen CA nicht vertraut wird?

Eine Domain will ja auch bezahlt werden und wirklich brauchen tue ich irgendwie nicht für den eigentlichen Zweck.

Zitat von @netzer2021:
Kann ich denn nicht eigentlich ein Wild Card direkt selber mit OPNsense erstellen und dennoch als Reverse Proxy nutzen?

Natürlich. Eine selbstsignierte CA kannst du jederzeit nutzen, den Aufwand sie bei den Clients vertrauenswürdig zu machen und die Erneuerung und Erstellung musst du dann aber in Kauf nehmen. Wenn das kein Problem ist, jederzeit. Der Common Name für das Server-Zertifikat lautet dann auf den Domain Namen (domain.de) und die SANs enthalten dann den Wildcard Eintrag(*.domain.tld) und zusätzlich auch den Common Name(domain.de).

Bsp.

Anders rum geht es natürlich auch

Wenn du den reinen Domain-Namen nicht nutzt kannst du diesen auch im SAN weglassen, nur wenn du ihn im Common-Name nutzt muss er auch in den SANs stehen, ansonsten ist das Zertifikat ungültig.

Dann blieben wohl die Browser Warnungen da der eigenen CA nicht vertraut wird?

Jepp, hier musst du dann das CA Zertifikat bei allen Geräten in die vertrauenswürdigen Stammzertifizierungsstellen importieren, dann ist die Meldung weg.

Die Frage ist doch, brauchst du intern SSL wirklich wenn du alles sowieso nur intern nutzt? Vertraust du deinem eigenen Netz nicht? Hast du intern Angst vor MitM und ARP Poisening? Willst du dich nur den Warnungen der Browser entledigen?
Denn nur für einen Zugriff über einen Domainnamen brauchst du logischerweise keine Zertifikate, hier reicht ein korrekt eingerichtetes DNS völlig aus.

Das ist genau die Frage die ich mir auch gerade stelle. Brauch ich es wirklich?

Ich denke ich schaue mir die Option mit den Self-signed wildcards mal näher an. Gerätschaften bei denen ich ein CERT brauche kann ich ggf auch überdenken. Problem ist glaube ich das z.B. iOS keine eigenen Root ca akzeptiert, wie man die dazu wohl nötige critical=true Option setzt habe ich noch nicht herausfinden können. Hauptnutzer sind allerdings 3,4 iOS Geräte.

Ich dachte immer, dass SSL auch im Home lan insb dann über wlan sicherer ist, aber dem scheint nicht so? Macht es denn bei einem geplanten VPN Access einen Unterschied? Public vs self-signed cert?

Gelernt habe ich aufjeden Fall das ich mit opnsense direkt einen Reverse Proxy nutzen kann. Würde hier nach HA Proxy oder Nginx via Plugin schauen. Hier zu noch eine Frage. Wenn ich den Nginx Proxy Manager nutzen würde kommt der in mein Docker Netz. Dort, so mein Verständnis kann er ja direkt mit den anderen Containern kommunizieren ohne dass ich dedizierte beim einzelnen Container Ports freigeben muss. Geht das mit den beiden Optionen auf der opnsense ebenfalls?

Zitat von @netzer2021:
Das ist genau die Frage die ich mir auch gerade stelle. Brauch ich es wirklich?

Tja das musst am Ende du mit deinen persönlichen Anforderungen wissen

.
Ich persönlich fahre schon lange mit der Devise, alles was über den auch "produktiv" genutzt wird wird auch per SSL/TLS abgesichert, der Aufwand ist heute so gering da stellt sich eigentlich die Frage nicht mehr ob ja oder nein.

Ich denke ich schaue mir die Option mit den Self-signed wildcards mal näher an. Gerätschaften bei denen ich ein CERT brauche kann ich ggf auch überdenken. Problem ist glaube ich das z.B. iOS keine eigenen Root ca akzeptiert, wie man die dazu wohl nötige critical=true Option setzt habe ich noch nicht herausfinden können. Hauptnutzer sind allerdings 3,4 iOS Geräte.

Doch auch bei iOS Geräten kann man selbstsignierte CAs nutzen, man muss sie dann aber über eigenes Device-Profile (.mobilconfig) importieren, auch wieder einmalige Mehrarbeit für jedes dieser Geräte bei einer eigenen CA.

Ich dachte immer, dass SSL auch im Home lan insb dann über wlan sicherer ist, aber dem scheint nicht so?

Wenn du dein LAN als protentiell unsicher betrachtest, klar, das schützt immer vor neugierigen Schnüfflern in deinem Netz. Der Traffic und damit persönliche Daten und Kennwörter werden damit immer PtP verschlüsselt übertragen. Ein Angreifer innerhalb deines Netzes der deinen Traffic über sich umleitet kann dann nichts mitlesen. Er müsste dann das Zertifikat des remote-Endpunkt fälschen was dann aber am Client sofort durch eine Warnung im Browser aufpoppen würde. Hat der Angreifer jedoch den privaten Key deiner CA ergattert kann er deine Kommunikation leise im Klartext mitschnüffeln ohne das du es mitbekommst, das sollte dir klar sein.

Macht es denn bei einem geplanten VPN Access einen Unterschied? Public vs self-signed cert?

Abgesehen vom Aufwand und der Fälschungssicherheit, nein. Den private Key deiner CA musst du natürlich sicher aufbewahren sonst ist das ganze nutzlos.

Gelernt habe ich aufjeden Fall das ich mit opnsense direkt einen Reverse Proxy nutzen kann. Würde hier nach HA Proxy oder Nginx via Plugin schauen.

os-nginx heist das Plugin.

Hier zu noch eine Frage. Wenn ich den Nginx Proxy Manager nutzen würde kommt der in mein Docker Netz. Dort, so mein Verständnis kann er ja direkt mit den anderen Containern kommunizieren ohne dass ich dedizierte beim einzelnen Container Ports freigeben muss. Geht das mit den beiden Optionen auf der opnsense ebenfalls?

Das geht auf vielfältige Weisen:

Proxy auf der OPNSense, Container dann bspw. in eigenem VLAN.
Proxy auf dem Virtualisierungshost.
...

In deinem Fall wohl auf dem Virtualisierungshost die einfachste Wahl, wenn sowieso alles containerisiert ist.

Einem Proxy ist es in der Regel egal wo die Systeme dahinter laufen, Hauptsache sie sind vom Proxy aus erreichbar.

Danke für das tolle Feedback!

Zu den iOS Geräten: Für mein synology nas hatte ich das mal probiert. CERT mit OpenSSL und entsprechend eigener CA. Ich habe dann beide Files als Profile auf den iOS Geräten installiert. Warnung kam trotzdem. Ist das von dir erwähnte Mobileconfig noch was anderes?

Zu den Reverse Optionen. Ich würde opnsevse und adguard (beide gleiche Maschine) ohne Reverse einrichten. Zugriff auf das Web Interface hat eh nur ein Rechner.
Mein „Service hub“ steht in einen eigenen vlan. Die Container haben aber keine eigene LAN IP per macvlan, sondern sind per eigenen Bridge Network von Docker versorgt. Daher würde hier wohl der Nginx Proxy Manager als Container am meisten Sinn machen , „sicherer“ auch noch da keine Ports direkt freigeben werden da Traffic nur per revers Proxy innerhalb des Bridge Networks lädt. Soweit meine Logik.

Bei einer public Tl Domain bin ich mir grad unsicher. Hab mit mal zwei deutsche Anbieter (einer heist H…er andere Io..s, darf man hier Namen nennen?) angeschaut. Whois protection bieten soweit ich weißle Anbieter in Standard. Bei einem kann ich noch einen Domain guard dazu buchen und bekomme direkt ein wildcard cert mit. Brauch ich ja eigentlich nicht. Reine Domain reicht, eine sub kann ich ja wohl erstellen, certs macht dann LE.

Zitat von @netzer2021:
Zu den iOS Geräten: Für mein synology nas hatte ich das mal probiert. CERT mit OpenSSL und entsprechend eigener CA. Ich habe dann beide Files als Profile auf den iOS Geräten installiert. Warnung kam trotzdem. Ist das von dir erwähnte Mobileconfig noch was anderes?

Ja das ist was anderes, die lassen sich per Apple Configurator erstellen, sind aber in Endeffekt am Ende nur XML-Dateien die die Zertifikate und Einstellungen in Textform enthalten. Die *.mobileconfig Dateien sind unter iOS aber ausführbar und konfigurieren das Endgerät nach Anweisung in der Config.

Das klingt kompliziert mit dem configurator. Nur ein iPhone wird zur konfig nicht reichen? Meinen Mac wollt ich eigentlich ausmustern.

Zitat von @netzer2021:
Nur ein iPhone wird zur konfig nicht reichen?

Nein. Außer du erstellst die Datei selbst per Text-Editor is wie gesagt nur eine XML-Datei, aber davon gehe ich bei dir erst mal nicht aus

Meinen Mac wollt ich eigentlich ausmustern.

Gibt auch noch eine Windows-Version des Configurator in den Untiefen des Web. Mit entsprechendem Wissen reicht aber auch ein Texteditor ;-P
Beispiel findest du hier

Den Aufwand treibt man ja ehrlich gesagt auch eher als Unternehmen denn als Privatmann. Die Mobileconfig-Files sind in erster Linie fürs Massendeployment von Geräten gedacht.

So. Danke für deine Hilfe. Es hat jetzt zum Groteil funktioniert. Der Tipp mit den WildCards auf OPNsense war der SChlüssel. Es nimmt langsam Form an

. 80% sind geschafft, bleiben wohl noch die 20% Kleinigkeiten mit 80% der Zeit

Nginy Proxy Manager läuft, Portainer, Nextcloud, Unifi werden über diesen versorgt. OPNsense ist ebenfalls mit SSL abgesichert. Aktuell kämpfe ich hier und da noch mit ein paar Firewall Rules der ufw auf dem Ubuntu host. Lieder hat es auch meine Unifi Config zerschossen. Devices sind alle nicht mehr erreichbar, ärgelrich aber korrigierbar.

Des Weiteren fehlt noch SSL für AdGuard, direkt auf OPNsense, keine Ahnung wie man da das Cert einspielen kann und der Nginx Proxy selbst, also der WebInterface kann ich auch noch nicht per SSL aufrufen. Und die Kommunikation zwischen Nextcloud und OnlyOffice Doc Server will noch nicht so recht.

Vielleicht noch eine Idee?

Ideen habe ich dazu viele im Kopf, ohne weitere Informationen zur Konfiguration ein Himmelsfahrtskommando. Das Sprengt jetzt aber den Rahmen dieses Threads. Bei spezifischen Fragen zu bestimmten Diensten/Produkten bitte einen neuen Thread erstellen.

Wenns das dann war, den Beitrag bitte noch auf gelöst setzen, und Lösungen markieren. Merci.

Grüße Uwe

Vielleicht noch eine Frage dazu. Passt noch knapp rein 😉.

Aktuell Expose ich keine Ports meiner Container. Traffic läuft ausschließlich über den NPM. Nun ist es ja häufig wenn nicht gar immer so, dass ein Container mehrere Ports benötigt. Beispiel UniFi 8443 für das Webinterface, 8080 und weitere für die Kommunikation der UniFi Geräte mit dem Controller. Öffne ich nun diesen Port 8080 nicht wird kein UniFi device mit den Controller kommunizieren können. In NPM kann ich ja lediglich auf einen Port (in diesem Fall auf 8443) umleiten aber nicht Gleichheit auch auf 8080. Heißt für mich, Port 8080 im Container exposen oder nicht?

Ein ReverseProxy kann selbstverständlich auch andere Ports verfügbar machen, das ist reine Konfigurationsfrage. Die Hauptaufgabe eines Reverse-Proxies ist es ja anhand der Domain (host-headers) der Anfrage die Requests intern an die container zu verteilen. Innerhalb des Docker-Network muss der Container natürlich den entsprechenden Port öffnen, auf die der proxy dann den Traffic routet. Nach extern muss der Proxy natürlich auch auf dem jeweiligen Port lauschen.
Befasse dich mal mit den NGINX Direktiven direkt dann siehst du auch die Möglichkeiten die es als Reverse-Proxy bietet. Also am besten gleich mal einen nginx manuell selbst aufsetzen und konfigurieren davon lernst du am meisten und deine Fragen lösen sich von selbst in Luft auf

. Diese fertigen Container-Lösungen waschen einem nur das Gehirn weil sie vieles automatisieren, aber was dahinter tatsächlich passiert ist viel interessanter als das man es verpassen sollte. Mit dem Wissen bewaffnet lassen sich dann auch Fehler in der Regel viel schneller verorten und beheben .

Viel Erfolg.

Grüße Uwe

Danke dir! Bin sehr gut weitergekommen.

German solved Question Networks