(Un)-Sicherheitsfaktor LetsEncrypt & ACME DynNS & Nginx

Started by neuling10, February 09, 2025, 08:46:39 PM

Previous topic - Next topic
Hallo an die Runde,

ich habe mich die letzten Tage intensiv mit dem Thema LetsEncrypt Zertifikate für interne Hosts auseinandergesetzt.

Mein Ziel ist es, die nervenden "Ihre Verbindung ist nicht sicher"-Meldungen durch ein LetsEncrypt Wildcard Zertifikat für diverse interne Hosts (Synology NAS, Openhab Smart Home, Grafana Dashboards etc.) zu eliminieren. Mir geht es rein um interne Hosts, ich möchte keinen externen Zugriff ermöglichen und habe hierfür aktuell auch keinen Anwendungsfall. Für den Zugriff auf meine Hosts von Außerhalb nutze ich ausschließlich Wireguard VPN (Site to Site oder am Smartphone).

Mein Plan wäre es nun, mir mittels ACME Plugin ein Wildcard LetsEncrypt Zertifikat zu generieren über eine DNS Challenge eines DNS Providers. Nur für die Opnsense würde ich einen A-Record beim DNS Anbieter anlegen (in meinem Fall z.B. bei IPv64). Den TCP Port der Opnsense Weboberfläche würde ich von 443 auf einen anderen Port ändern.
Mittels Nginx Plugin würde ich das Zertifikat den internen Hosts zur Verfügung stellen. Für diese Host Domains würde ich anstatt DNS A-Records beim DNS Provider den Unbound Dienst mit DNS Host Overrides nutzen und dies im Nginx HTTP-Server erfassen. 

Soweit zum Plan. Nun stellen sich mir als Laie jedoch noch ein paar Fragen in Bezug auf die Sicherheit meines Vorhabens:
1. Wenn ich es richtig verstanden habe, wird für die DNS Challenge durch das ACME Plugin die Opnsense von extern zugreifbar. Könnte das nicht ein durchaus kritisches Einfallstor in Bezug auf die Sicherheit sein (Zugriff auf die Opnsense GUI), z.B. falls der DynDNS Provider gehackt wird?
2. Könnte nun jemand, der meine externe IP und die internen Host Domains kennt, von außen auf die Weboberfläche der Hosts zugreifen?

Ich hoffe ihr könnt mir ein paar Ratschläge zu meinem Vorhaben geben. Immerhin möchte ich durch den Komfort-Gewinn nicht eine unnötige Sicherheitslücke aufmachen, dann lasse ich das lieber doch bleiben...

Grüße
neuling10

Machs dir doch einfacher: In der OPNsense eine eigene CA anlegen, das öffentliche Cert der CA auf den Clients und internen Systemen installieren.
Anschließend alle internen Systeme mit eigenen Zertifikaten aus der CA konfigurieren. Dabei darauf achten das man eine "interne" DNS-Zone hat. Zum Beispiel "zuhause.internal". Ein nas könnte dann "NAS01.zuhause.internal" als DNS Namen erhalten. Das Zertifikat für das NAS muss dann den FQDN im CN als auch im "Alt" erhalten.

Also eine konbination aus z.B. Unbound DNS und OPNsense als CA.
i want all services to run with wirespeed and therefore run this dedicated hardware configuration:

AMD Ryzen 7 9700x
ASUS Pro B650M-CT-CSM
64GB DDR5 ECC (2x KSM56E46BD8KM-32HA)
Intel XL710-BM1
Intel i350-T4
2x SSD with ZFS mirror
PiKVM for remote maintenance

private user, no business use

February 09, 2025, 09:04:29 PM #2 Last Edit: February 09, 2025, 09:11:01 PM by Patrick M. Hausen
Quote from: neuling10 on February 09, 2025, 08:46:39 PMWenn ich es richtig verstanden habe, wird für die DNS Challenge durch das ACME Plugin die Opnsense von extern zugreifbar

Nein - wieso denn das? Das ACME-Plugin stellt über ein API des DNS-Providers die Response auf die Challenge in dessen DNS.

Aber trotzdem zwei Alternativen:

Ich hab hier eine eigene CA auf der Sense und ein Wildcard-Zertifikat für alle internen Geräte.
Außerdem zu beachten: die Laufzeit von Zertifikaten einer privaten CA darf auch mit aktuellen Browsern immer noch bei 825 Tagen liegen. Spart Arbeit ;-)

Oder:

Für alle internen Geräte auf dem Caddy Reverse-Proxy anlegen, und den über die externe IP-Adresse mit HTTP-Challenge Letsencrypt spielen lassen. Dazu muss man natürlich alle Geräte, die darüber bedient werden, ins öffentliche DNS eintragen, notfalls mit CNAMEs die auf einen DynDNS-A-Record zeigen.
Aber man kann dann im Caddy-Plugin den Zugriff per HTTP(S) auf die internen Netze einschränken. Somit hat man zwar global sichtbare Namen aber den Zugriff trotzdem nur von innen.

Ich hab wie geschrieben die private CA gewählt. Caddy benutze ich für alles, was auch global erreichbar sein soll.

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

Vielen Dank für Eure Inputs, das hilft mir schon mal weiter. Vor allem dass ich mir keine Sicherheitslücke mit dem beschriebenen Vorgehen aufmache, ist schon mal eine sehr relevante Info für mich :-)

Euer Vorschlag, direkt auf der Opnsense eine CA zu nutzen mit einem Wildcard-Zertifikat, klingt für meinen Anwendungsfall völlig ausreichend. Kann man dieses Zertifikat dann direkt auf der Opnsense den Geräte-Adressen zuordnen (mit Unbound Override und Nginx Server) oder muss ich dann doch auf allen internen Geräten das Zertifikat manuell installieren? Das würde ich mir gerne ersparen und nehme dafür etwas mehr Konfigurationsaufwand auf der Opnsense in Kauf.

QuoteFür alle internen Geräte auf dem Caddy Reverse-Proxy anlegen, und den über die externe IP-Adresse mit HTTP-Challenge Letsencrypt spielen lassen. Dazu muss man natürlich alle Geräte, die darüber bedient werden, ins öffentliche DNS eintragen, notfalls mit CNAMEs die auf einen DynDNS-A-Record zeigen.
Aber man kann dann im Caddy-Plugin den Zugriff per HTTP(S) auf die internen Netze einschränken. Somit hat man zwar global sichtbare Namen aber den Zugriff trotzdem nur von innen.

Wäre es dann so, dass zwingend eine Internet-Verbindung bestehen muss, wenn ich über die DNS-Adresse (z.B. raspberry.myhome.net) auf die internen Geräte aus dem internen Netz zugreifen möchte?
Wäre es dann nicht einfacher mit der DNS Challenge das Wildcard Zertifikat anzulegen und dann dieses mittels Nginx an die internen Host-Adressen zuzuweisen? Somit würde man sich ja das öffentliche Eintragen der Geräte beim DNS Provider ersparen? Ganz nach dem Gedanken, nur so wenig wie möglich öffentlich beim DNS Provider Preis zu geben...

Grüße
neuling10