Die Aktivierung von HTTPS für das ZimaOS-Dashboard verleiht Jellyfin, Vaultwarden, Nginx Proxy Manager oder jeder anderen Docker-Anwendung nicht automatisch eine HTTPS-Adresse. Dieses Missverständnis war der eigentliche Auslöser für diesen Thread vom Februar 2026. Der Nutzer hatte HTTPS in den ZimaOS-Einstellungen aktiviert, das für die ZimaOS-Oberfläche generierte Zertifikat gespeichert und versucht, es in Nginx Proxy Manager zu importieren. Jellyfin und NPM verhielten sich jedoch weiterhin nicht wie erwartet.
Im weiteren Verlauf führte der Thread schließlich zu einer funktionierenden Community-Konfiguration: Nginx Proxy Manager als TLS-Terminierungspunkt für einzelne Anwendungen verwenden, das ZimaOS-Gateway von den Ports 80 und 443 wegverlegen, wenn diese Ports vom Reverse-Proxy benötigt werden, über DuckDNS einen Hostnamen konfigurieren und ein Zertifikat für diesen Hostnamen ausstellen. Der ursprüngliche Nutzer veröffentlichte später einen Screenshot, der die Proxy Hosts als online zeigte, und fasste das Ergebnis als funktionierend zusammen.
Die drei getrennten HTTPS-Ebenen verstehen
Es gibt drei verschiedene Dinge, die leicht miteinander verwechselt werden:
- HTTPS für das ZimaOS-Dashboard schützt die ZimaOS-Verwaltungsoberfläche selbst.
- HTTP der Anwendung ist der normale interne Port, den eine Anwendung wie Jellyfin verwendet.
- HTTPS des Reverse-Proxys ist ein öffentlicher oder lokaler Hostname, der TLS beendet und den Datenverkehr an den internen HTTP-Port der Anwendung weiterleitet.
Das für die ZimaOS-Verwaltungsoberfläche generierte Zertifikat ist daher kein universelles Zertifikat für jede Anwendung. Ein Reverse-Proxy benötigt ein Zertifikat, dessen Hostname mit der Adresse übereinstimmt, die Nutzer tatsächlich im Browser öffnen.
Nginx Proxy Manager als HTTPS-Einstiegspunkt verwenden
Der am besten wiederverwendbare Teil der Community-Lösung ist die Architektur und nicht die exakte Portkonfiguration aus dem Jahr 2026. Nginx Proxy Manager empfängt HTTPS-Anfragen für Hostnamen wie jellyfin.example.net und leitet sie an den lokalen HTTP-Dienst von Jellyfin weiter. Jellyfin kann weiterhin auf seinem normalen internen Port lauschen; das öffentliche Zertifikat muss nicht von Jellyfin selbst verwaltet werden.
Das aktuelle Nginx Proxy Manager folgt weiterhin diesem Modell: Einen Proxy Host erstellen, Zielhost und Zielport angeben, anschließend ein SSL-Zertifikat zuweisen und optional SSL erzwingen. Bei einer neuen Einrichtung sollte man dem aktuellen Ablauf von Nginx Proxy Manager für Proxy Hosts und Zertifikate folgen, statt einen alten Screenshot als unveränderliche Vorgabe für die Benutzeroberfläche zu betrachten.
Konflikte mit den Ports 80 und 443 vor der Ausstellung von Zertifikaten lösen
Der ursprüngliche Nutzer stellte fest, dass das ZimaOS-Gateway die Ports 80 und 443 bereits verwendete. Das ist wichtig, weil ein Reverse-Proxy normalerweise auf diesen Standardports lauschen möchte. Als Lösung änderte der Nutzer die Gateway-Ports von ZimaOS in /etc/casaos/gateway.ini, verschob Port 80 auf 85 und Port 443 auf 444 und startete anschließend den Gateway-Dienst neu.
Diese exakten Änderungen stammten vom Nutzer und nicht aus einer Support-Antwort von IceWhale in diesem Thread. Sie sollten als historische Community-Lösung und nicht als universelle Befehlsfolge betrachtet werden. Vor der Änderung der Dashboard-Ports sollte man sich die aktuelle URL notieren, sicherstellen, dass man weiß, wie ZimaOS anschließend erreicht werden kann, und die aktuelle ZimaOS-Oberfläche bevorzugen, sofern sie eine unterstützte Möglichkeit zum Ändern des Verwaltungsports bietet.
Warum DuckDNS dem ursprünglichen Nutzer geholfen hat
Eine Zertifizierungsstelle benötigt einen Hostnamen, den sie validieren kann. Der Nutzer richtete DuckDNS ein und verwendete anschließend diesen Hostnamen, um über Nginx Proxy Manager ein Zertifikat anzufordern. Damit wurde ein anderes Problem gelöst als die Frage „Wie erreiche ich die Anwendung?“: DNS stellte den Namen bereit, während NPM die HTTPS-Terminierung und Weiterleitung übernahm.
Auch rein lokales HTTPS benötigt lokal auflösbares DNS
Die ursprüngliche Frage bezog sich ausdrücklich auf HTTPS innerhalb des lokalen Netzwerks und nicht auf den Fernzugriff. Ein Domainname zwingt den Datenverkehr nicht dazu, das Haus zu verlassen. Man kann einen Hostnamen innerhalb des eigenen Netzwerks über lokales DNS oder Split-DNS in die LAN-Adresse von ZimaOS auflösen lassen und anschließend Nginx Proxy Manager ein vertrauenswürdiges Zertifikat für diesen Hostnamen bereitstellen lassen.
Das ist in der Regel sauberer, als eine private Roh-IP-Adresse aufzurufen und zu versuchen, ein öffentliches Zertifikat dafür passend zu machen. Das Zertifikat wird für den Hostnamen validiert; das lokale DNS bestimmt, dass dieser Hostname in eine private Adresse aufgelöst werden soll.
Ein selbst signiertes Zertifikat ist eine weitere Möglichkeit, erfordert aber eine verwaltete Vertrauensstellung
Eine Community-Antwort schlug vor, mit OpenSSL ein Zertifikat zu erstellen und es in Nginx Proxy Manager zu importieren. Das kann für eine rein lokale Nutzung funktionieren, aber Browser und Geräte vertrauen einem selbst signierten Zertifikat nicht automatisch. Jeder Client, der eine fehlerfreie HTTPS-Verbindung anzeigen soll, muss dem ausstellenden Zertifikat oder der lokalen Zertifizierungsstelle vertrauen.
Für einen Haushalt mit vielen Smartphones, Fernsehern, Tablets und Anwendungen ist die Verwendung eines öffentlich vertrauenswürdigen Zertifikats für einen Hostnamen oft einfacher, als überall manuell eine lokale Zertifizierungsstelle zu installieren.
Cloudflare ist eine alternative Architektur, keine Voraussetzung
Ein anderer Teilnehmer erklärte, Cloudflare sowohl innerhalb als auch außerhalb des Heimnetzwerks zu verwenden. Cloudflare kann nützlich sein, wenn derselbe Hostname aus der Ferne funktionieren muss, aber die ursprüngliche Frage erforderte keinen öffentlichen Zugriff. Ein Tunnel sollte nicht allein deshalb eingerichtet werden, weil HTTPS im LAN gewünscht ist.
Jede Ebene einzeln überprüfen
- Bestätigen, dass die Anwendung über ihre direkte lokale HTTP-Adresse geöffnet werden kann.
- Bestätigen, dass der Hostname zum vorgesehenen Reverse-Proxy aufgelöst wird.
- Bestätigen, dass Nginx Proxy Manager den internen Host und Port der Anwendung erreichen kann.
- Das Zertifikat erst zuweisen, nachdem die Weiterleitung über den Proxy ohne HTTPS funktioniert.
- Anschließend HTTPS erzwingen und von mehr als einem lokalen Client aus testen.
Diese Reihenfolge verhindert, dass ein Zertifikatsproblem mit einem Docker-Routing-Problem oder einem Portkonflikt verwechselt wird.
FAQ zu lokalem HTTPS unter ZimaOS
Schützt der HTTPS-Schalter von ZimaOS Jellyfin automatisch?
Nein. Er schützt die ZimaOS-Verwaltungsoberfläche, nicht jede Docker-Anwendung.
Brauche ich für HTTPS ausschließlich im LAN eine öffentliche Domain?
Du benötigst einen Hostnamen, der zum Zertifikat passt. Dieser Hostname kann innerhalb deines Netzwerks in eine private LAN-Adresse aufgelöst werden.
Warum hat der ursprüngliche Nutzer ZimaOS von den Ports 80 und 443 wegverlegt?
Nginx Proxy Manager benötigte die Standardports für HTTP und HTTPS. Die Änderung war eine Community-Lösung für diese Installation.
Wurde bestätigt, dass die Einrichtung des ursprünglichen Nutzers funktioniert?
Ja. Der ursprüngliche Verfasser zeigte die NPM-Hosts mit Zertifikaten als online und erklärte, dass die Einrichtung funktionierte.
