HTTPS für Dienste im Heimnetz: Zertifikate ohne Fehlermeldung

Warum der Browser überhaupt meckert

Dein Browser zeigt eine Warnung, wenn er dem Zertifikat einer Seite nicht traut. Ein Zertifikat ist so etwas wie ein Ausweis für den Dienst: Es bestätigt, dass du wirklich mit „nas.example.com“ sprichst und niemand dazwischensitzt. Ausgestellt wird dieser Ausweis von einer Zertifizierungsstelle (englisch Certificate Authority, kurz CA) – einer Stelle, deren Unterschrift in Betriebssystemen und Browsern fest hinterlegt ist.

Ein selbstsigniertes Zertifikat stellst du dir selbst aus. Kein Browser kennt deine Unterschrift, also kommt die Warnung. Sie wegzuklicken ist keine Lösung: Sobald eine Seite den Schutzmechanismus HSTS (HTTP Strict Transport Security – der Browser merkt sich „diese Seite nur noch verschlüsselt“) aktiviert hat, lässt sich die Warnung gar nicht mehr wegklicken. Apps prüfen ohnehin strenger als Browser und brechen die Verbindung oft kommentarlos ab.

Noch eine Stolperfalle: Jeder Hostname und jede IP, unter der du den Dienst erreichst, muss im Feld „SAN“ (Subject Alternative Name, die Liste der gültigen Namen) des Zertifikats stehen. Das alte Feld „Common Name“ ignorieren Chrome und Co. seit 2017.

Zwei Wege zum Schloss ohne Warnung

Weg A: Öffentliches Zertifikat für eine eigene Domain

Der bequemste Weg, wenn du eine Domain besitzt oder für ein paar Euro im Jahr registrierst. Du legst eine Subdomain nur fürs Heimnetz an, zum Beispiel home.example.com, und ziehst darunter Zertifikate für nas.home.example.com, pihole.home.example.com und so weiter.

Damit das ohne offenen Port funktioniert, nutzt du die DNS-01-Prüfung. Statt dass die Zertifizierungsstelle deinen Server aus dem Internet aufruft (das wäre die HTTP-01-Prüfung und bräuchte Port 80 von außen), legst du einen bestimmten TXT-Eintrag – einen kurzen Textschnipsel – im DNS deiner Domain ab, unter _acme-challenge.home.example.com. Die CA liest ihn und weiß: Wer den setzen kann, kontrolliert die Domain. Dein NAS muss dafür aus dem Internet gar nicht erreichbar sein – nur die DNS-Zone deiner Domain ist öffentlich. Ein interner DNS-Server (etwa Pi-hole) darf den Namen dann auf die private IP zeigen lassen.

Sinnvoll ist das nur, wenn dein DNS-Anbieter eine Schnittstelle (API) zum automatischen Setzen solcher Einträge hat. Anbieter wie Cloudflare, deSEC oder das kostenlose DuckDNS bieten das; bei Cloudflare lässt sich der Zugriffs-Token auf eine einzige Zone begrenzen. Wer den Schlüssel noch enger fassen will, delegiert nur den _acme-challenge-Eintrag per CNAME an einen separaten acme-dns-Server. Nur über DNS-01 bekommst du außerdem ein Wildcard-Zertifikat (*.home.example.com), das für alle Unteradressen auf einen Schlag gilt.

Certificate Transparency: deine Hostnamen sind öffentlich

Jedes öffentlich ausgestellte Zertifikat wird in Transparenz-Logs eingetragen – öffentliche, dauerhafte Listen, durchsuchbar etwa über crt.sh. Ziehst du ein Einzelzertifikat für vaultwarden.home.example.com, steht dieser Name damit für immer im Netz und verrät, welche Dienste du betreibst. Ein Wildcard-Zertifikat mildert das, weil dort nur *.home.example.com auftaucht. Mit einem CAA-Eintrag im DNS legst du zusätzlich fest, welche CA überhaupt für deine Domain ausstellen darf.

DNS-Rebind-Schutz

Viele Router und DNS-Filter – die FritzBox, pfSense, Pi-hole – verwerfen öffentliche DNS-Antworten, die auf private Adressen wie 192.168.x.x zeigen. Das ist der „DNS-Rebind-Schutz“, eine Sicherheitsfunktion. Zeigt dein öffentlicher Eintrag für nas.home.example.com aber genau auf so eine interne IP, blockiert der Schutz die Auflösung. Lösung: die eigene Domain als Ausnahme eintragen. Bei der FritzBox unter „Heimnetz → Netzwerk → Netzwerkeinstellungen → DNS-Rebind-Schutz → Ausnahmen“ – der genaue Menüpfad kann je FritzOS-Version abweichen.

Weg B: Eigene Zertifizierungsstelle

Manche Namen wird dir keine öffentliche CA je ausstellen: die reservierten Endungen .local (für mDNS-Dienste wie Bonjour/Avahi), .home.arpa (der offizielle Standard für Heimnetze) und .internal (seit Juli 2024 von der ICANN für private Nutzung reserviert), dazu alle privaten IP-Adressen. Willst du solche Namen mit HTTPS betreiben, musst du selbst zur Zertifizierungsstelle werden.

Für den schnellen Anfang gibt es mkcert: Ein Aufruf von mkcert -install legt eine lokale Wurzel-CA an und trägt sie in den Vertrauensspeicher deines Betriebssystems sowie von Firefox und Chrome ein. Danach erzeugst du damit Zertifikate für beliebige lokale Namen. Für mehrere Geräte und Automatik ist smallstep step-ca die größere Lösung – eine selbst betriebene CA, die per ACME (dem Protokoll, das auch Let’s Encrypt nutzt) automatisch ausstellt und erneuert.

Der Haken bei jeder eigenen CA: Das Wurzelzertifikat muss auf jedes Gerät und in jeden Browser, der den Diensten vertrauen soll. Und das ist zäher, als es klingt:

• Firefox bringt einen eigenen Vertrauensspeicher mit; der Eintrag im Betriebssystem hilft ihm nur mit gesetztem security.enterprise_roots.enabled. Auch Java, Node.js, Python und teils curl haben je eigene Speicher.
• Apple begrenzt Zertifikate aus einer selbst hinzugefügten CA auf 825 Tage Laufzeit; ein „10-Jahres-Zertifikat“ lehnen iOS und macOS ab. Auf dem iPhone musst du ein manuell installiertes Wurzelzertifikat zusätzlich unter „Einstellungen → Allgemein → Info → Zertifikatsvertrauenseinstellungen“ scharfschalten.
• Android macht es besonders schwer: Seit Android 7 vertrauen Apps nutzerinstallierten CAs standardmäßig nicht. Android 11 verbietet das Einspielen per ADB, Android 14 hält den System-Speicher unveränderlich – selbst mit Root kommst du ohne Spezialwerkzeuge nicht mehr rein.

Wichtig zu mkcert: Der private Schlüssel der Wurzel-CA (rootCA-key.pem) liegt ungeschützt auf der Platte. Wer ihn in die Finger bekommt, kann sich gegenüber allen vertrauenden Geräten für jede beliebige Seite ausgeben. Erzeuge die CA einmal an einem sicheren Ort und verteile an andere Geräte nur die öffentliche rootCA.pem.

Kurze Laufzeiten – ohne Automatik geht nichts mehr

Let’s-Encrypt-Zertifikate gelten aktuell 90 Tage, erneuert wird nach 60. Und es wird kürzer: Das CA/Browser Forum hat beschlossen, die maximale Laufzeit von 398 auf 200 Tage (ab März 2026), dann 100 (2027) und schließlich 47 Tage (2029) zu senken. Let’s Encrypt hat angekündigt, noch davor auf 45 Tage zu gehen. Seit Juni 2025 verschickt Let’s Encrypt außerdem keine Ablauf-Erinnerungsmails mehr – du brauchst eine Überwachung, die dir Bescheid gibt, wenn eine Erneuerung hakt.

Praktisch heißt das: Ein Client muss das automatisch erledigen. Verbreitet sind certbot (die Referenz), das reine Shell-Skript acme.sh (läuft auf fast jedem NAS und Router), lego sowie die in Caddy und Traefik eingebauten Clients. Um OCSP – eine frühere Methode zur Sperrprüfung – musst du dich bei Let’s Encrypt nicht mehr kümmern: Der Dienst wurde 2025 komplett abgeschaltet, Sperrungen laufen nur noch über CRL-Listen.

Der einfachste Einstieg: ein Reverse Proxy

Statt jeden Dienst einzeln mit einem Zertifikat auszustatten, stellst du einen Reverse Proxy davor – einen Vermittler, der alle Anfragen annimmt, die Verschlüsselung an einer Stelle erledigt und intern per einfachem HTTP an die Dienste weiterreicht.

• Caddy macht HTTPS von sich aus: Für öffentliche Domains holt es automatisch Zertifikate (Let’s Encrypt mit ZeroSSL als Ausweichanbieter), für rein lokale Namen nutzt es eine eingebaute eigene CA. Der einfachste Start fürs Homelab.
• Traefik wird über Docker-Labels konfiguriert und kann DNS-01 – gut, wenn du deine Einrichtung als Code pflegst.
• Nginx Proxy Manager ist eine grafische Oberfläche über nginx mit Zertifikaten per Klick. Beachte: Version 2 ist nur noch im Wartungsmodus, Version 3 lange in Arbeit, und es gab Sicherheitslücken – halte die Installation aktuell.

Wer gar keine eigene Domain will, aber Tailscale (ein VPN-Netz) nutzt: tailscale cert stellt für Namen unter <tailnet>.ts.net echte Let’s-Encrypt-Zertifikate aus, ohne den Dienst nach außen zu öffnen. Auch hier landen die Maschinennamen in den Transparenz-Logs.

Besonderheit Synology und QNAP

Das in Synologys DSM 7 eingebaute Let’s Encrypt kann nur die HTTP-01-Prüfung (du musst also Port 80/443 weiterleiten) oder einen Synology-DDNS-Namen auf synology.me, für den Synology Wildcards über den eigenen DNS anbietet. Ein automatisches DNS-01 für Wildcards deiner Domain ist nach dem Stand von 2025 nicht eingebaut – dafür installierst du acme.sh oder lässt einen Container mit Caddy oder Traefik laufen. Bei QNAP (QTS) läuft das eingebaute Let’s Encrypt über den myQNAPcloud-DDNS-Namen, mit ähnlichen Einschränkungen; Details können sich mit neueren QTS-Versionen geändert haben.

Unsere Empfehlung

Synology DS225+ 2-Bay Diskstation NAS
Wer seine Heimnetz-Dienste auf einem Synology-NAS bündelt, trifft dort auf genau die DSM-Zertifikatsverwaltung, um die es in diesem Artikel geht. Preis Stand 04.09.2026: 349,00 €.

Preis prüfen *

Häufige Irrtümer auf einen Blick

• „Selbstsigniert reicht, man klickt die Warnung weg.“ Bei HSTS-Seiten geht das nicht mehr, Apps verweigern die Verbindung.
• „Ich bekomme ein Zertifikat für 192.168.1.10 oder server.local.“ Nein – öffentliche CAs stellen nur für registrierte Namen aus. Zertifikate für öffentliche IP-Adressen gibt es seit Januar 2026 zwar, aber nicht für private Heimnetz-Adressen.
• „Für Let’s Encrypt muss ich mein NAS ins Internet stellen.“ Nein, mit DNS-01 bleibt alles intern; öffentlich ist nur die DNS-Zone.
• „CA in Windows eingetragen – fertig.“ Firefox und viele Laufzeitumgebungen (Java, Node.js, Python, curl) haben eigene Speicher.
• „Ein Wildcard-Zertifikat ist ein Sicherheitsrisiko.“ Im Homelab verbessert es eher die Privatsphäre; das Hauptrisiko ist derselbe Schlüssel auf vielen Geräten.