HTTPS im Heimnetz: So sichern Sie lokale Dienste ab¶
Veröffentlicht am 25. September 2026 · Geschätzte Lesezeit: 12 Minuten
Home Assistant, AdGuard Home, Paperless-ngx, Nginx Proxy Manager – viele Dienste laufen nur im Heimnetz, ohne von außen erreichbar zu sein. Trotzdem zeigt der Browser eine Warnung, Apps verweigern die Verbindung und moderne Protokolle wie OAuth oder WebHooks setzen eine gültige HTTPS-Verbindung voraus. Dieser Artikel zeigt vier Wege, lokale Dienste mit HTTPS zu versehen, sodass der Browser ein grünes Schloss anzeigt. Welcher Weg zu dir passt, hängt davon ab, ob du eine eigene Domain besitzt und wie viel Aufwand du investieren möchtest. Lies die Einordnung am Ende und entscheide selbst.
Voraussetzungen für alle Varianten
- Ein Linux-Server mit Docker und Docker Compose
- Grundlegende Kenntnisse im Umgang mit der Kommandozeile
- (optional) Eine eigene Domain mit Zugriff auf die DNS-Einstellungen
Warning
Dieser Artikel beschreibt ausschließlich die Absicherung lokaler Dienste im Heimnetz. Wenn deine Dienste von außen erreichbar sein sollen, findest du passende Anleitungen unter Docker-Dienst mit Caddy und HTTPS absichern, Traefik als Reverse Proxy mit Let's-Encrypt-Zertifikaten oder Nginx Proxy Manager per Docker installieren.
1. Das Problem: Warum bekomme ich kein gültiges HTTPS für lokale Adressen?¶
Klassische Zertifikatsstellen wie Let's Encrypt prüfen die Kontrolle über eine Domain, bevor sie ein
Zertifikat ausstellen. Bei der HTTP-01-Challenge schickt Let's Encrypt eine Anfrage an
http://<deine-domain>/.well-known/acme-challenge/… und erwartet eine bestimmte Antwort. Solange
deine Domain nur auf eine lokale IP wie 192.168.1.100 zeigt und von außen nicht erreichbar ist,
kann Let's Encrypt diese Prüfung nicht durchführen.
Die gute Nachricht: Es gibt mehrere Wege, dieses Problem zu umgehen – für jede Situation ist eine passende Lösung dabei.
| Problem | Lösung |
|---|---|
| Keine Domain vorhanden | Self-signed oder eigene CA |
| Domain vorhanden, aber kein Port 80/443 von außen | Let's Encrypt DNS-01-Challenge |
| Domain vorhanden, Port 80/443 erreichbar, aber NAT-Loopback fehlt | Split-DNS |
2. Variante A: Selbstsignierte Zertifikate (einfach, kein Domain-Zwang)¶
Ein selbstsigniertes Zertifikat erstellst du in einer Minute – es ist kryptografisch genauso sicher wie ein geprüftes Zertifikat, aber keiner Stelle außer dir vertraut ihm. Jeder Client zeigt beim ersten Aufruf eine Sicherheitswarnung an.
2.1 Zertifikat erstellen¶
Führe diesen Befehl auf dem Docker-Server aus:
mkdir -p ~/certs && cd ~/certs
openssl req -x509 -newkey rsa:4096 -keyout privkey.pem -out cert.pem -days 365 -nodes \
-subj "/CN=heimdienst.local" \
-addext "subjectAltName=DNS:heimdienst.local,DNS:heimdienst,DNS:homeassistant.local,IP:192.168.1.100"
Passe die Namen und IP-Adressen an deine Umgebung an. Mit -days 365 ist das Zertifikat ein Jahr
gültig, danach muss ein neues erstellt werden.
2.2 In Nginx Proxy Manager einbinden¶
Nginx Proxy Manager (NPM) erwartet Zertifikate im Verzeichnis ~/npm/data/nginx/. Lege sie dort ab
und trage sie als Custom SSL Certificate in der NPM-Oberfläche ein:
Öffne NPM unter http://<server-ip>:81, wähle den Proxy-Host aus, schalte auf der SSL-Karte
das Tab Custom Certificate und wähle die hochgeladene Datei aus.
2.3 Vor- und Nachteile¶
| Vorteil | Nachteil |
|---|---|
| Ein Befehl, kein Setup | Browser-Warnung bei jedem Client |
| Keine Domain nötig | Manuelle Erneuerung nach einem Jahr |
| Funktioniert offline | Jeder Dienst braucht ein eigenes Zertifikat oder wildcard |
Tip
Wenn du bereit bist, auf jedem Gerät einmal ein Zertifikat zu installieren, lies bei Variante B weiter – dort bekommst du das grüne Schloss ohne Aufpreis.
3. Variante B: Eigene CA im Heimnetz (empfohlen ohne Domain)¶
Eine eigene Certificate Authority (CA) im Heimnetz ist die sauberste Lösung, wenn du keine Domain besitzt oder deine Dienste nur lokal laufen. Du wirst deine eigene Zertifizierungsstelle – einmal aufgesetzt und auf allen Geräten als vertrauenswürdig eingetragen, zeigt der Browser ein grünes Schloss für alle deine lokalen Dienste. Dasselbe Verfahren nutzen Unternehmen intern seit Jahrzehnten.
3.1 Root-CA erstellen¶
mkdir -p ~/myca && cd ~/myca
# Root-CA-Schlüssel (UNBEDINGT sichern!)
openssl genrsa -out root-ca-key.pem 4096
# Root-CA-Zertifikat (10 Jahre gültig)
openssl req -x509 -new -key root-ca-key.pem -out root-ca.pem -days 3652 \
-subj "/CN=Meine Heimnetz-CA"
CA-Key sichern
Die Datei root-ca-key.pem ist der Schlüssel zu deinem gesamten Zertifikats-Wald.
Mit diesem Key kann jeder gültige Zertifikate für dein Heimnetz ausstellen.
Lege sie an einen sicheren Ort (Backup, verschlüsselt). Ohne diesen Key kannst du später
keine neuen Zertifikate ausstellen.
3.2 Konfigurationsvorlage für Dienst-Zertifikate¶
Damit nicht jeder Aufruf dieselben Parameter braucht, legst du eine Konfigurationsdatei an:
cat > dienst.cnf << 'EOF'
[req]
distinguished_name = req_distinguished_name
x509_extensions = v3_req
prompt = no
[req_distinguished_name]
CN = dienstname.lan
[v3_req]
subjectAltName = @alt_names
[alt_names]
DNS.1 = dienstname.lan
DNS.2 = dienstname
DNS.3 = homeassistant.lan
IP.1 = 192.168.1.100
EOF
3.3 Zertifikat für einen Dienst ausstellen¶
Für jeden Dienst wiederholst du diesen Vorgang. Ersetze dienstname.lan durch den gewünschten
Namen deines Dienstes.
cd ~/myca
# Dienst-Schlüssel
openssl genrsa -out dienstname-key.pem 2048
# Zertifikatsanforderung (CSR)
openssl req -new -key dienstname-key.pem -out dienstname.csr -config dienst.cnf
# Dienst-Zertifikat mit CA signieren (10 Jahre)
openssl x509 -req -in dienstname.csr -CA root-ca.pem -CAkey root-ca-key.pem \
-CAcreateserial -out dienstname.pem -days 3652 -extensions v3_req -extfile dienst.cnf
Am Ende erhältst du dienstname.pem (Zertifikat) und dienstname-key.pem (privater Schlüssel).
Die CSR-Datei (dienstname.csr) kannst du löschen.
3.4 Im Nginx Proxy Manager einbinden¶
cp ~/myca/dienstname.pem ~/myca/dienstname-key.pem ~/npm/data/nginx/
chmod 600 ~/npm/data/nginx/dienstname-key.pem
Wähle in NPM unter SSL → Custom Certificate das Zertifikat dienstname.pem aus.
3.5 Root-CA auf den Geräten installieren¶
Damit alle Clients dem selbst ausgestellten Zertifikat vertrauen, muss die Root-CA
(root-ca.pem) auf jedem Gerät als vertrauenswürdig hinterlegt werden. Diesen Schritt
führst du einmal pro Gerät aus – danach sind alle von dir signierten Zertifikate gültig.
- Lade
root-ca.pemauf das Gerät (E-Mail, Nextcloud, USB) - Öffne die Einstellungen → Profil (oben) → Zertifikate herunterladen
- (Neuere iOS-Versionen: Einstellungen → Allgemein → VPN & Geräteverwaltung → Zertifikate installieren)
- Root-Zertifikat auswählen und installieren
- Passwort oder PIN bestätigen
Falls der Menüpunkt fehlt: Datei über Safari öffnen, iOS fragt automatisch nach der Installation.
- Lade
root-ca.pemauf das Gerät - Gehe zu Einstellungen → Sicherheit & Datenschutz → Weitere Einstellungen → Zertifikate verschlüsseln und authentifizieren
- Tippe auf CA-Zertifikat installieren
- Wähle die
root-ca.pemund bestätige - Android vertraut nun allen von dir signierten Zertifikaten
Tip
Auf älteren Android-Versionen heißt der Pfad Einstellungen → Sicherheit → Vertrauenswürdige Anmeldeinformationen → Installieren.
Für Chrome und Edge (nutzen den Windows-Zertifikatsspeicher):
- Kopiere
root-ca.pemauf den Windows-Rechner - Doppelklick auf die Datei → Zertifikat installieren klicken
- Vertrauenswürdige Stammzertifizierungsstellen auswählen → OK
Für Firefox (nutzt einen eigenen Zertifikatsspeicher):
- Firefox öffnen → Einstellungen → Datenschutz & Sicherheit → Zertifikate
- Zertifikate anzeigen → Reiter Zertifizierungsstellen → Importieren
root-ca.pemauswählen und Dieses Zertifikat zum Identifizieren von Websites verwenden aktivieren
- Kopiere
root-ca.pemauf den Mac - Doppelklick auf die Datei → Schlüsselbundverwaltung öffnet sich
- → System → Anmelden wählen
- Vertrauenswürdig auswählen → Zertifikat speichern
- Passwort bestätigen
3.6 Vor- und Nachteile¶
| Vorteil | Nachteil |
|---|---|
| Grünes Schloss ohne Domain | Einmalige Einrichtung pro Gerät nötig |
| Keine Port-Weiterleitung nötig | CA-Key muss sorgfältig gesichert werden |
| Für beliebig viele Dienste wiederholbar | Keine öffentliche Gültigkeit (nur im Heimnetz) |
| Volle Kontrolle, keine externen Abhängigkeiten |
4. Variante C: Let's Encrypt mit DNS-01-Challenge (mit Domain, ohne Port-80-Weiterleitung)¶
Wenn du eine eigene Domain besitzt (z. B. meine-domain.de), aber keine Ports 80 oder 443 nach
außen öffnen möchtest oder kannst, ist die DNS-01-Challenge der richtige Weg. Statt einer
HTTP-Anfrage prüft Let's Encrypt hier die Kontrolle über die Domain, indem es einen
DNS-TXT-Eintrag abfragt. Das Tool acme.sh steuert diesen Vorgang komplett
automatisch: Es setzt den TXT-Eintrag über die API deines DNS-Anbieters, wartet auf die
Verbreitung und fordert das Zertifikat an.
4.1 acme.sh installieren¶
cd ~
git clone https://github.com/acmesh-official/acme.sh.git
cd acme.sh
./acme.sh --install --home ~/.acme.sh
4.2 DNS-API einrichten¶
acme.sh unterstützt über 150 DNS-Anbieter. Welcher das ist, hängt davon ab, wo deine Domain verwaltet wird. Nach dem Einrichten der API-Zugangsdaten (in der Regel ein API-Token aus dem DNS-Provider-Dashboard) fügst du sie in die Umgebungsvariablen ein:
# Beispiel: Cloudflare
export CF_Token="<dein-cloudflare-api-token>"
export CF_Email="<deine-email@example.com>"
# Beispiel: deSEC (kostenlos, deutsch)
export DEDYN_TOKEN="<dein-desec-token>"
# Beispiel: Route53 (Amazon AWS)
export AWS_ACCESS_KEY_ID="<key>"
export AWS_SECRET_ACCESS_KEY="<secret>"
# Beispiel: INWX
export INWX_User="<benutzername>"
export INWX_Password="<passwort>"
Tip
Die Liste aller unterstützten Anbieter findest du in der acme.sh-Dokumentation unter dnsapi. Der Umgebungsvariable-Name steht jeweils in der rechten Spalte.
4.3 Zertifikat anfordern (nur DNS, kein Port 80 nötig)¶
~/.acme.sh/acme.sh --issue --dns dns_cf -d "*.meine-domain.de" -d "meine-domain.de" \
--keylength ec-384
Ersetze dns_cf durch deinen Anbieter (z. B. dns_desec für deSEC, dns_aws für Route53).
Das Argument ec-384 erzeugt ein modernes ECDSA-Zertifikat mit einer elliptischen Kurve –
sicherer und schlanker als RSA.
Wildcard-Zertifikat
Der Eintrag "*.meine-domain.de" ist ein Wildcard-Zertifikat. Es gilt für
alle Subdomains (dienst1.meine-domain.de, dienst2.meine-domain.de …) und
du benötigst nur ein Zertifikat für alle deine lokalen Dienste.
4.4 Zertifikate exportieren¶
acme.sh speichert die Zertifikate in ~/.acme.sh/. Für die Verwendung in Nginx Proxy Manager
oder anderen Diensten exportierst du sie:
~/.acme.sh/acme.sh --install-cert -d "*.meine-domain.de" \
--cert-file ~/certs/cert.pem \
--key-file ~/certs/privkey.pem \
--fullchain-file ~/certs/fullchain.pem
Kopiere die Zertifikate in das NPM-Verzeichnis:
cp ~/certs/fullchain.pem ~/certs/privkey.pem ~/npm/data/nginx/
chmod 600 ~/npm/data/nginx/privkey.pem
Wähle in der NPM-Oberfläche unter SSL → Custom Certificate das Zertifikat fullchain.pem
aus.
4.5 Automatische Erneuerung¶
acme.sh installiert automatisch einen Cron-Job, der die Zertifikate alle 60 Tage prüft und bei Bedarf erneuert. Nach der Erneuerung müssen die Dateien in das NPM-Verzeichnis kopiert werden. Dafür gibt es eine Erneuerungs-Hook-Datei:
mkdir -p ~/.acme.sh/deploy
cat > ~/.acme.sh/deploy/npm-deploy.sh << 'EOF'
#!/bin/bash
cp "$CERT_PATH/fullchain.pem" "$HOME/npm/data/nginx/"
cp "$CERT_PATH/privkey.pem" "$HOME/npm/data/nginx/"
chmod 600 "$HOME/npm/data/nginx/privkey.pem"
EOF
chmod +x ~/.acme.sh/deploy/npm-deploy.sh
Verknüpfe den Hook mit deinem Zertifikat:
~/.acme.sh/acme.sh --install-cert -d "*.meine-domain.de" --reloadcmd "bash ~/.acme.sh/deploy/npm-deploy.sh"
Tip
Wenn du Caddy oder Traefik nutzt, bindest du die Zertifikate stattdessen als Docker-Volume
ein. Bei Caddy über ./conf/Caddyfile, bei Traefik über acme.json direkt – siehe die
entsprechenden Anleitungen auf dieser Seite.
4.6 Vor- und Nachteile¶
| Vorteil | Nachteil |
|---|---|
| Öffentlich gültiges Zertifikat (keine manuelle Installation auf Clients) | Du brauchst eine eigene Domain |
| Automatische Erneuerung | DNS-API-Zugangsdaten nötig |
| Wildcard möglich (ein Zertifikat für alle Dienste) | Einrichtung einmalig komplexer |
| Kein offener Port 80 nötig |
5. Variante D: Split-DNS (öffentliche Domain, interne Auflösung)¶
Wenn du eine Domain besitzt und Port 80/443 grundsätzlich von außen erreichbar ist, dein Router
aber kein NAT-Loopback kann (Geräte im Heimnetz können die öffentliche IP nicht von innen
erreichen), hilft Split-DNS. Das Prinzip: Deine öffentliche Domain dienst.meine-domain.de zeigt
im Internet auf deine öffentliche IP. Im Heimnetz löst ein lokaler DNS-Server (AdGuard Home,
Pi-hole oder der Router selbst) dieselbe Domain direkt auf die interne IP deines Servers auf.
So funktioniert Let's Encrypt von außen (HTTP-01-Prüfung) und deine Clients erreichen den Dienst auch von innen, ohne über das Internet zu gehen.
5.1 Lokalen DNS-Eintrag setzen (AdGuard Home / Pi-hole)¶
Öffne die Oberfläche deines lokalen DNS-Servers:
AdGuard Home: Gehe zu Einstellungen → DNS-Einträge → Benutzerdefinierte Regeln:
Pi-hole: Gehe zu Local DNS → DNS Records → trage Domain und IP ein.
5.2 Zertifikat per HTTP-01-Challenge¶
Leite die Ports 80 und 443 vom Router auf deinen Server. Da Let's Encrypt die Domain von außen prüft, funktioniert die normale HTTP-01-Challenge. Nginx Proxy Manager, Caddy oder Traefik können das Zertifikat automatisch beziehen – ohne DNS-API, ohne manuelle Skripte.
In der NPM-Oberfläche wählst du einfach SSL → Request a new SSL Certificate → Domain eintragen → Let's Encrypt aus. NPM erledigt den Rest.
5.3 Vor- und Nachteile¶
| Vorteil | Nachteil |
|---|---|
| Einfachste Einrichtung mit NPM | Port 80/443 muss von außen erreichbar sein |
| Automatische Zertifikatsverwaltung | Nicht bei DS-Lite/CGNAT möglich |
| Kein manuelles Kopieren von Zertifikaten | Doppelter Konfigurationsaufwand (DNS+Proxy) |
6. Welcher Weg ist der richtige für dich?¶
| Deine Situation | Empfohlene Variante |
|---|---|
| Ich habe keine Domain, möchte aber ein grünes Schloss | B – Eigene CA |
| Ich habe keine Domain, will es schnell und einfach | A – Self-signed (Browser-Warnung in Kauf nehmen) |
| Ich habe eine Domain, aber keine offenen Ports | C – Let's Encrypt DNS-01 |
| Ich habe eine Domain, Ports sind offen, NAT-Loopback fehlt | D – Split-DNS |
| Ich habe eine Domain, Ports sind offen, NAT-Loopback funktioniert | Kein Spezialfall nötig – NPM/Caddy/Traefik kann direkt Let's Encrypt per HTTP-01 nutzen |
| Ich bin unsicher und will das flexibelste Setup | B (eigene CA) + optional später C (DNS-01) – beides parallel möglich |
7. Begriffserklärungen¶
| Begriff | Bedeutung |
|---|---|
| CA / Certificate Authority | Zertifizierungsstelle – eine Instanz, die Zertifikate ausstellt und signiert |
| Self-signed | Selbst signiert – das Zertifikat ist von niemandem beglaubigt |
| Root-CA | Wurzelzertifikat – die höchste Ebene einer eigenen Zertifikatskette |
| CSR | Certificate Signing Request – Anfrage an eine CA, ein Zertifikat auszustellen |
| ACME | Automatic Certificate Management Environment – Protokoll, mit dem Let's Encrypt arbeitet |
| HTTP-01-Challenge | Let's Encrypt prüft die Domain-Kontrolle über eine HTTP-Anfrage auf Port 80 |
| DNS-01-Challenge | Let's Encrypt prüft die Domain-Kontrolle über einen TXT-DNS-Eintrag |
| Wildcard-Zertifikat | Ein Zertifikat, das für *.domain.de und damit für alle Subdomains gilt |
| Split-DNS | Unterschiedliche DNS-Auflösung derselben Domain je nach Netzwerk (intern vs. extern) |
| NAT-Loopback | Die Fähigkeit eines Routers, von innen über die öffentliche IP auf interne Dienste zuzugreifen |
| DS-Lite / CGNAT | Der Internetanbieter gibt keine eigene öffentliche IPv4-Adresse, sondern teilt sich eine |
| Nginx Proxy Manager (NPM) | Webbasierte Verwaltung für Nginx-Reverse-Proxy mit integrierter HTTPS-Verwaltung |
Fertig¶
Deine lokalen Dienste sind jetzt mit HTTPS gesichert – ohne Browser-Warnung, ohne Kompromisse. Welche Variante du auch gewählt hast, ab sofort zeigen Home Assistant, Paperless und alle anderen Dienste im Heimnetz ein grünes Schloss.