Für das Heimnetzwerk bei vorhandener Public Domain selbstsign. SSL oder per Let's Encrypt?!

Chris81T

Member
Hallo zusammen,

ich hatte jüngst damit begonnen, mein Heimnetzwerk etwas "umzubauen" und bin nun am Schritt angelangt, auf einen guten Weg SSL mit zu integrieren.

Hier mein Setup:

Fritzbox als Router, welche bzgl. DNS Anfragen meinen Raspberry Pi (dort via Docker ein Bind9 DNS Server aktiv) befragt. Dort ist eine Zone hinterlegt, so dass ich zu meiner eigenen public Domain entsprechend SubDomains gepflegt habe, welche die IP von meinem NAS zurückgeben, um dort entsprechende Services aufzurufen (Nextcloud, Openhab, ...). All diese Services werden ebenfalls per Docker betrieben. Die eingehenden Anfragen (aktuell noch über Port 80) werden von einem Traefik Service entsprechend auf den zugehörigen Docker Service weitergereicht.

Das funktioniert soweit wie gewünscht.

Nun kommt die Flanke, dass ich dies mittels SSL absichern möchte.

Option 1)
Ich erstelle mir ein selbst signiertes Zertifikat, welches von Traefik genutzt werden kann. Die Laufzeit kann ich selbstständig etwas höher schrauben, so dass man nicht alle 3 Monate ran muss.
NACHTEIL: Jeder Client in meinem Netzwerk wird dies als nicht vertrauenswürdig ansehen, so dass auf jedem Client noch was konfiguriert werden muss, damit dem Zertifikat vertraut wird.

Option 2)
Traefik ist dafür ausgelegt, über Letsencrypt automatisch sich Zertifikate zu beziehen. Also in meinem Fall für meine Public Domain. Das Problem hier ist dann bei meinem Setup, dass ich einen Port für außen freischalten muss, damit die Letsencrypt Server dann mit meinen Services kommunzieren können. Den Port könnte man schnell wieder schließen, aber aufgrund der 3 Monatsgültigkeit darf man dann immer wieder ran.
VORTEIL: Jeder Client würde dem Zertifikat vertrauen ohne das da noch was konfiguriert werden muss - NACHTEIL: Alle drei Monate muss man hier selbst aktiv werden.

Das ist mein aktuelles Verständnis, was ich an Optionen habe. Nun frage ich mich, welcher Weg hier am meisten Sinn macht, einzuschlagen? Eventuell gibt es noch ganz andere Optionen, bzw. könnt ihr berichten, wie ihr das bei euch selbst pflegt?

Gibt es eventuell externe kostenlose Dienste, über die man für seine Domain ein Wildcard Zertifikat erhalten kann, welches man (idealerweise automatisiert) downloaden kann, um damit die Absicherung vorzunehmen?

Ich bin auf das Feedback gespannt und auf jeden Fall im Vorfeld besten Dank dazu! :)


Viele Grüße
Christian
 
Du kannst das auch selbst machen, in dem Du Dir einen generischen ACME-Client nimmst und dann Deinen Zertifikatstausch selbst macht. Ich nehme dafür z.B. den CertBot. Die Let's Encrypt Plugins haben alle ihren Grenzen.

Man kann Let's Encrypt Zertifikate nämlich auch beziehen ohne einen Port zu öffnen. Das geht über die DNS-Challenge. Da Du eh schon selbst einen DNS-Server betreibst wäre das eine Option für Dich. In dem Fall wird die Rechtmäßigkeit der Zertifikatsanfrage über einen spezifischen TXT-Record für die Domäne geprüft.

Das hier wäre ein Beispiel für so einen DNS-Record:
_acme-challenge.DeineDomäne.de. 3590 IN TXT "i4--69aEc6RbZHIGTJGH3565zGuzg87ttfWaZa0LR5WqViI0"

Das Ganze kannst Du Dir dann auf einer kleinen Linux-VM mittels Cron automatisieren. Das Vorgehen wäre: aktuelle Challenge anfragen, DNS-Zone updaten, etwas warten, Zertifikat anfragen, Zertifikate auf alle Systeme verteilen .... fertig. Das ganze lässt Du dann per Cron z.B. alle 80 Tage laufen.
 
...

Das hier wäre ein Beispiel für so einen DNS-Record:
_acme-challenge.DeineDomäne.de. 3590 IN TXT "i4--69aEc6RbZHIGTJGH3565zGuzg87ttfWaZa0LR5WqViI0"

...
Guten Morgen @Barungar :) und vielen Dank für die schnelle Antwort.

Das sind sehr gute Informationen, so dass ich mir das später in Ruhe genauer anschauen werde. Falls sich noch Fragen ergeben sollte, wäre ich so frei, die hier nochmal zu stellen. Ggf. kannst du (oder jmd. anders) gerne mir dann nochmal helfen ;-)
 
Da Du eh schon selbst einen DNS-Server betreibst wäre das eine Option für Dich.
So wie ich das gelesen habe, handelt es sich dabei aber um einen rein internen DNS, oder nicht? Wenn man da nicht von aussen dran kann und auch nicht auf diesen DNS-Server verwiesen wird (extern) wird das wohl eher nix.
In dem Fall wird die Rechtmäßigkeit der Zertifikatsanfrage über einen spezifischen TXT-Record für die Domäne geprüft.
Aber nicht vom Client selbst, sondern von LE und die werden ja wohl schwerlich an einen internen DNS-Server heran kommen (zumal auch erstmal von extern darauf verwiesen werden müsste). Bedingung für sowas wäre soweit - meines Wissens nach - auch, dass der Anbieter eine API bzgl. DNS bereitstellt.

Hier mal als Auszug von LE:
Nachdem Let’s Encrypt Ihrem ACME Client einen Token gegeben hat, erstellt Ihr Client einen TXT Eintrag abgeleitet von diesem Token und Ihrem Kontoschlüssel und fügt diesen Eintrag als _acme-challenge.<YOUR_DOMAIN>. Dann fragt Let’s Encrypt das DNS-System für diesen Eintrag. Wenn er gefunden wurde, können Sie mit der Ausstellung des Zertifikats fortfahren!
Muss also schon "öffentlich" erreichbar sein und und natürlich auch zuständig, da könnte man ggf. noch delegieren (wenn man das möchte). Wenn es via DNS-Challenge läuft, würde man vermutlich sowieso einfach direkt ein Wildcard-Cert für den Reverse-Proxy ausstellen und jut wär's. Im Gegensatz zur HTTP-Challenge muss man dafür eben keine Ports öffnen, allerdings halt via z.B. API an seinen öffentlichen DNS gelangen, damit der Client dort den generierten Token hinterlegen kann. Ein paar Anbieter mit API sind hier hinterlegt, vielleicht ist Deiner ja auch schon dabei: https://community.letsencrypt.org/t...egrate-with-lets-encrypt-dns-validation/86438 :)
 
Dort ist eine Zone hinterlegt, so dass ich zu meiner eigenen public Domain entsprechend SubDomains gepflegt habe, welche die IP von meinem NAS zurückgeben, um dort entsprechende Services aufzurufen (Nextcloud, Openhab, ...). All diese Services werden ebenfalls per Docker betrieben. Die eingehenden Anfragen (aktuell noch über Port 80) werden von einem Traefik Service entsprechend auf den zugehörigen Docker Service weitergereicht.

@blurrrr
Da es für von außen eingehende Dienste genutzt wird, muss diese Zone auch von außen erreichbar sein. Denn sonst konnten die DNS-Einträge für diese Systeme nicht genutzt werden. Aus diesen Punkten war für mich ein DNS-Server gegeben... der vollumfänglich ins DNS integriert ist.
 
Also für mich sieht das einfach nur so aus, als hätte man da auf dem NAS zusätzlich was laufen und jut ist. Da ist für mich mal so "garnichts" von aussen erreichbar (schon garnicht, wenn sowieso nur interne Einträge ausgeliefert werden). Mich wundert nur ein wenig folgendes:

Traefik ist dafür ausgelegt, über Letsencrypt automatisch sich Zertifikate zu beziehen. Also in meinem Fall für meine Public Domain. Das Problem hier ist dann bei meinem Setup, dass ich einen Port für außen freischalten muss, damit die Letsencrypt Server dann mit meinen Services kommunzieren können. Den Port könnte man schnell wieder schließen, aber aufgrund der 3 Monatsgültigkeit darf man dann immer wieder ran.
vs.
Die eingehenden Anfragen (aktuell noch über Port 80) werden von einem Traefik Service
Also ist sowieso schon http offen und https vermutlich auch direkt (unverschlüsselt von extern wäre ja auch irgendwo nicht so schön). Also steht der normalen http-Challenge ja eigentlich auch nix im Weg (wobei halt nur via DNS01-Challenge die Wildcard-Certs möglich sind). Ist eigentlich egal wie wo was, es sollte alles über den RP laufen und der sollte die Zertifikate haben... demnach ist es schon fast egal, ob es die HTTP oder DNS01-Challenge ist (wobei letzteres eben einen Anbieter mit API voraussetzt).
 
Mitunter wäre es evtl. hilfreicher, wenn @Chris81T sein Konstrukt mal etwas genauer erklärt und vor allem auch was von aussen erreichbar ist und was nicht... bisher hab ich da auch nur etwas von Port 80 gelesen und das kann ja irgendwo auch nicht der Weisheit letzter Schluss sein ☺️
 
Vermutlich habe ich mich etwas unglücklich ausgedrückt:

Der DNS Server läuft bei mir auf nem PI im internen Netzwerk. Ich hätte da auch ne Fake Domain oder so hinterlegen können, wollte aber auf meine vorhandene Domain zurückgreifen, um die Tür hier offen zu haben, dass ich etwas mit einem öffentlichen Zertifikat machen könnte.

In der eigenen DNS Zone habe ich sowas wie:
  • nextcloud.mydomain.de
  • openhab.mydomain.de
hinterlegt, welche die IP meines NAS zurück liefert. Auf dem NAS läuft Traefik, welcher
  • nextcloud.mydomain.de --> Nextcloud Docker Service
  • openhab.mydomain.de --> Openhab Docker Service
verweist.

Daher ist ein Zugriff von Außen aktuell nicht möglich. Auf die Seite Challenge Typen / Let's encrypt bin ich eben gestoßen, was @blurrrr in seinem Post via Auszug hinterlegt hat.

Das bedeutet, ohne hier einen Port zu öffnen, wird es schwierig mit Let's Encrypt?
 
Das bedeutet, ohne hier einen Port zu öffnen, wird es schwierig mit Let's Encrypt?
Nein, das ist so nicht ganz korrekt... Via Lets Encrypt hast Du 2 Möglichkeiten: a) HTTP-Challenge (benötigt - temporär - offene Ports bei Dir, aber in gewisser Regelmässigkeit), b) DNS01-Challenge (benötigt einen Domainverwalter mit API, wo Du Dir für z.B. Certbot einen API-Token generieren kannst). Der Token würde dann bei Certbot hinterlegt werden. Steht eine Ausstellung/Aktualisierung an, rennt Certbot zu LE, bekommt einen Token, dieser Token muss "öffentlich erreichbar" als TXT-Record bei Deiner Domain hinterlegt werden. Hat Certbot keinen Zugriff auf Deine Domain klappt es natürlich nicht, deswegen die Geschichte mit dem API-Token, womit Certbox direkt den Token bei Deinem Domainverwalter im DNS hinterlegen kann und Lets Encrypt diesen Eintrag dort überprüfen kann.

Heisst also, dass hier 2x ausgehende Verbindungen stattfinden (Token abholen und Token via API im DNS hinterlegen), während bei der HTTP-Challenge zwar der Token geholt wird, dann aber lokal auf einem (öffentlich erreichbaren) Webserver hinterlegt sein muss, damit LE das auch überprüfen kann (das wäre dann die Sache mit der Portweiterleitung, also eine eingehende Verindung). Die eingehende Verbindung zur Überprüfung verschiebt sich also bei der DNS-Challenge auf den öffentlichen DNS-Bereich. Da dieser nicht "bei Dir" liegt, musst Du auch entsprechend nichts dafür freigeben :)

Ich hatte doch die Liste der Anbieter mit API weiter oben gepostet - schau doch einfach mal dort rein, ob da nicht auch zufällig schon Dein Anbieter drin steht. Oder hast Du evtl. gar keine eigene öffentliche Domain und hast Dir nur für intern etwas ausgedacht? 😁
 
Nein, das ist so nicht ganz korrekt... Via Lets Encrypt hast Du 2 Möglichkeiten: a) HTTP-Challenge (benötigt - temporär - offene Ports bei Dir, aber in gewisser Regelmässigkeit), b) DNS01-Challenge (benötigt einen Domainverwalter mit API, wo Du Dir für z.B. Certbot einen API-Token generieren kannst). Der Token würde dann bei Certbot hinterlegt werden. Steht eine Ausstellung/Aktualisierung an, rennt Certbot zu LE, bekommt einen Token, dieser Token muss "öffentlich erreichbar" als TXT-Record bei Deiner Domain hinterlegt werden. Hat Certbot keinen Zugriff auf Deine Domain klappt es natürlich nicht, deswegen die Geschichte mit dem API-Token, womit Certbox direkt den Token bei Deinem Domainverwalter im DNS hinterlegen kann und Lets Encrypt diesen Eintrag dort überprüfen kann.

Heisst also, dass hier 2x ausgehende Verbindungen stattfinden (Token abholen und Token via API im DNS hinterlegen), während bei der HTTP-Challenge zwar der Token geholt wird, dann aber lokal auf einem (öffentlich erreichbaren) Webserver hinterlegt sein muss, damit LE das auch überprüfen kann (das wäre dann die Sache mit der Portweiterleitung, also eine eingehende Verindung). Die eingehende Verbindung zur Überprüfung verschiebt sich also bei der DNS-Challenge auf den öffentlichen DNS-Bereich. Da dieser nicht "bei Dir" liegt, musst Du auch entsprechend nichts dafür freigeben :)

Ich hatte doch die Liste der Anbieter mit API weiter oben gepostet - schau doch einfach mal dort rein, ob da nicht auch zufällig schon Dein Anbieter drin steht. Oder hast Du evtl. gar keine eigene öffentliche Domain und hast Dir nur für intern etwas ausgedacht? 😁
Danke dir für dein Feedback. Das werde ich mir heute Abend anschauen.

Aktuell habe ich meine Domain über GoDaddy am Start, um für mein MS365 Paket meine E-Mail Adressen für Outlook über meine Domain laufen zu lassen.

Es kann gut sein, dass ich mich hier nochmal melden werde, habe aber dank euch hier gute Punkte zum Recherchieren genannt bekommen. Top! :)
 
Im Prinzip musst Du ja nur dafür sorgen, dass traefik ein entsprechendes Wildcard-Zertifikat bekommt, wenn Du intern auch alles über den Reverse-Proxy ansprichst. Wird schon schief gehen... ☺️
 
Moinsen,
auch wenn ihr schon direkt mit den "echten" Zertifikaten hantiert...
auf die Eingangsfrage (selbst erstellt oder zB LetsEncrypt) antwortend: hier nutze ich nur die selbstsignierten Zertiikate. Ich habe kein Gerät direkt von draußen verfügbar, das läuft via VPN. Für internes https lege ich Zertifikate über die CA auf der pfsense an.
Musste dafür dann natürlich die Ausnahmen auf den Clients hinzufügen, das ist bei mir aber überschaubar. Und für die nächsten 10 Jahre gelten die dann auch...
:)
 
Musste dafür dann natürlich die Ausnahmen auf den Clients hinzufügen
Root-CA-Zertifikat importieren und jut ist? Der Gedanke mit einer eigenen CA kam mir auch direkt, aber ich wollte das jetzt auch nicht gleich überstrapazieren... 😁 Wenn das mit der DNS-Challenge via LE funktioniert, ist ja auch jut, dann ist mitunter direkt ein Wildcard-Zertifikat durch und dann hat man das ganze Zeugs direkt weg. Ist ja so verkehrt eigentlich auch nicht 🙃

Ich persönlich lebe aber ganz einfach mit den selbst-signierten (die i.d.R. direkt auf dem Gerät ausgestellt werden) und mach mir da eigentlich mal so gar keinen Stress... (auch keine Ausnahmen). So oft muss ich hier eigentlich nicht an etwas (naja, eigentlich sogut wie nie...), von daher stört mich das eigentlich auch nicht groß... wenn ich mal "wirklich" irgendwo dran muss, ist es sowieso meist via SSH, von daher ist mir das eh wurscht... Ansonsten geht's halt (aber nicht privat) für div. Test-Geschichten über einen Reverse-Proxy mit hinterlegtem Wildcard-Zertifikat, damit ist der Drops dann auch gelutscht 😇
 
Moinsen,
genau: früher selber ne CA auf dem Rechner angelegt gehabt. Damit dann die internen ssl-Zertifikate ausgestellt.
Heute dann mit dem CertManager der pfsense, was easy zu machen ist.
Eine CA für die ssl-Certs, eine für den VPN-Server und die benötigten VPN Zertifikate.
:)

Und da, wo ich zusätzlich SSH nutze, lege ich die Keypairs eben selber an...ist ja mit etwas Übung auch relativ schnell gemacht.
;)
 
Wenn auch etwas am Thema vorbei:
Da mein Public-DNS Anbieter zwar DynDNS anbietet, aber keine API für DNS-01 Challenges, habe ich mir beholfen, Port 80/443 auf den Traefik zu verweisen. An diesem klebt auch die Middleware Authelia, welche den externen Zugriff auf eigentlich nur intern gehostete Dienste per OTP oder FIDO2-Keys absichert.
Vielleicht wäre das eine Alternative?
 
Ich habe es die Woche mit dem Docker Image "CertBot inkl GoDaddy Plugin" erfolgreich gelöst.
Es funktioniert wunderbar und mittels eines eingerichteten Cron Jobs automatisch, wenn das Cert abgelaufen ist. Vielen Dank für die nützlichen Hinweise. Die haben mein Problem gelöst.
 

Zurzeit aktive Besucher

Neueste Beiträge

Letzte Anleitungen

Statistik des Forums

Themen
5.366
Beiträge
53.162
Mitglieder
5.150
Neuestes Mitglied
derBremser
Zurück
Oben