Zum Inhalt

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:

cp cert.pem privkey.pem ~/npm/data/nginx/
chmod 600 ~/npm/data/nginx/privkey.pem

Ö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.

  1. Lade root-ca.pem auf das Gerät (E-Mail, Nextcloud, USB)
  2. Öffne die Einstellungen → Profil (oben) → Zertifikate herunterladen
  3. (Neuere iOS-Versionen: Einstellungen → Allgemein → VPN & Geräteverwaltung → Zertifikate installieren)
  4. Root-Zertifikat auswählen und installieren
  5. Passwort oder PIN bestätigen

Falls der Menüpunkt fehlt: Datei über Safari öffnen, iOS fragt automatisch nach der Installation.

  1. Lade root-ca.pem auf das Gerät
  2. Gehe zu Einstellungen → Sicherheit & Datenschutz → Weitere Einstellungen → Zertifikate verschlüsseln und authentifizieren
  3. Tippe auf CA-Zertifikat installieren
  4. Wähle die root-ca.pem und bestätige
  5. 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):

  1. Kopiere root-ca.pem auf den Windows-Rechner
  2. Doppelklick auf die Datei → Zertifikat installieren klicken
  3. Vertrauenswürdige Stammzertifizierungsstellen auswählen → OK

Für Firefox (nutzt einen eigenen Zertifikatsspeicher):

  1. Firefox öffnen → Einstellungen → Datenschutz & Sicherheit → Zertifikate
  2. Zertifikate anzeigen → Reiter Zertifizierungsstellen → Importieren
  3. root-ca.pem auswählen und Dieses Zertifikat zum Identifizieren von Websites verwenden aktivieren
  1. Kopiere root-ca.pem auf den Mac
  2. Doppelklick auf die Datei → Schlüsselbundverwaltung öffnet sich
  3. → System → Anmelden wählen
  4. Vertrauenswürdig auswählen → Zertifikat speichern
  5. Passwort bestätigen
sudo cp root-ca.pem /usr/local/share/ca-certificates/meine-ca.crt
sudo update-ca-certificates

Für Firefox auch hier der separate Firefox-Zertifikatsspeicher (Schritte wie unter Windows).

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:

# Dienstname          Typ   Wert
dienst.meine-domain.de  A    192.168.1.100

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.