Es gibt keinen bestätigten globalen HTTPS-Schalter für jede App
Im Community-Thread wurde keine ZimaOS-Schaltfläche genannt, die jeder installierten Anwendung automatisch einen gültigen HTTPS-Endpunkt bereitstellt. Jede App kann an einem anderen Port lauschen, unterschiedliche Webfunktionen verwenden und ein eigenes Routing-Verhalten erfordern.
Der Benutzer griff über eine Domain und eine statische öffentliche IP auf den Speicher zu, erhielt aber weiterhin eine Warnung vor einer unsicheren Verbindung. Ein Domainname allein erstellt kein TLS. Der Browser muss einen Endpunkt erreichen, der ein für diesen Hostnamen gültiges Zertifikat präsentiert.
Beginne damit, jede App, ihren internen Port, den gewünschten Hostnamen und die Art des Zugriffs aufzulisten: nur lokal, privater Fernzugriff oder öffentlicher Internetzugriff. Dieser Umfang bestimmt das geeignete Ingress-Design.
Wähle ein Ingress-Modell für das tatsächliche Zugriffsziel
Ein Reverse-Proxy kann TLS an Port 443 beenden und verschiedene Hostnamen an separate interne App-Ports weiterleiten. Das passt zu einem domainbasierten Design, bei dem ein zentral kontrolliertes Frontend mehrere Anwendungen bereitstellt.
Ein verwalteter Tunnel kann einen HTTPS-Einstiegspunkt bereitstellen, ohne jeden Anwendungsport direkt vom Router weiterzuleiten. Ein privates Overlay wie Tailscale löst ein anderes Problem: Authentifizierte Geräte treten einem privaten Netzwerk bei und können auf Dienste zugreifen, ohne diese allgemein öffentlich zugänglich zu machen.
Wähle ein Modell, bevor du Zertifikate konfigurierst. Das gleichzeitige Einrichten von direkter Portweiterleitung, einem Tunnel und einem Overlay ohne klaren Grund erhöht die Zahl der Pfade, die abgesichert und überprüft werden müssen.
Zertifikate gehören an den TLS-Terminierungspunkt
Ein Let's-Encrypt-Zertifikat kann von einem Reverse-Proxy oder einem anderen Dienst verwendet werden, der die HTTPS-Verbindung kontrolliert. Es wird nicht „auf der Domain“ installiert, und seine Ausstellung bringt nicht automatisch jeder Backend-App bei, wie sie es verwendet.
Leite einen Hostnamen an den ausgewählten Proxy oder Tunnel weiter, stelle das Zertifikat dort aus oder binde es dort ein und leite diesen Hostnamen an eine interne App weiter. Halte den Backend-Port privat, sofern die Architektur nicht ausdrücklich direkten Zugriff erfordert.
Wenn der Browser eine Warnung anzeigt, überprüfe den Hostnamen im Zertifikat, das DNS-Ziel, die Zertifikatskette und die Komponente, die tatsächlich auf Port 443 antwortet. Umgehe die Warnung nicht als dauerhafte Lösung.
Validiere eine Anwendung, bevor du das Muster wiederholst
Teste die Anmeldung, Uploads, Downloads, Live-Aktualisierungen und alle Funktionen, die von WebSockets abhängen, über den HTTPS-Hostnamen. Eine Seite, die geladen wird, aber keine Uploads ermöglicht oder keine Sitzung aufrechterhalten kann, ist nicht vollständig konfiguriert.
Starte den Proxy oder Tunnel sowie die Ziel-App neu und wiederhole anschließend denselben Ablauf. Bestätige, dass HTTP nur dort weitergeleitet wird, wo dies beabsichtigt ist, und dass rohe Backend-Ports nicht unbeabsichtigt dem Internet ausgesetzt sind.
Sobald eine App funktioniert, wiederhole die Zuordnung von Hostname zu Backend für die nächste App. Setze bei einem Dienst mit besonderen Proxy-Anforderungen nur die fehlerhafte Route zurück, statt funktionierende HTTPS-Endpunkte abzubauen.
Remote-HTTPS ersetzt keine Zugriffskontrolle
TLS verschlüsselt den Datenverkehr und authentifiziert den Hostnamen, entscheidet aber nicht, wer die Anwendung verwenden darf. Behalte eine starke App-Authentifizierung, eine begrenzte Veröffentlichung, Updates und Audit-Logs bei.
Im Thread wird empfohlen, Cloudflare Tunnels, Tailscale oder einen Reverse-Proxy wie Caddy zu untersuchen, eine abgeschlossene Bereitstellung wird jedoch nicht dokumentiert. Dies sind Architekturvorschläge und keine durch die Quelle bestätigte Schritt-für-Schritt-Anleitung für ZimaOS.
Beende den Vorgang vor einer öffentlichen Veröffentlichung, wenn die gewählte Methode, der Besitz des Zertifikats oder die Authentifizierungsgrenze unklar ist. Validiere zunächst einen unkritischen Dienst oder nutze beim Entwurf des öffentlichen Zugriffs einen privaten Fernzugriff.
FAQ
Kann ein einziges Zertifikat automatisch jede ZimaOS-App absichern?
Nicht von selbst. Ein Proxy oder anderer TLS-Endpunkt benötigt weiterhin einen Hostnamen und eine Routing-Regel für jeden Backend-Dienst.
Muss ich für Remote-HTTPS den Port jeder App öffentlich zugänglich machen?
Nicht unbedingt. Reverse-Proxies und verwaltete Tunnel zentralisieren den Ingress, während private Overlays eine allgemeine öffentliche Veröffentlichung vermeiden.
Ist Tailscale dasselbe wie ein Reverse-Proxy?
Nein. Tailscale stellt eine private Netzwerkverbindung zwischen autorisierten Geräten her; ein Reverse-Proxy nimmt Webanfragen entgegen und leitet Hostnamen an Backend-Dienste weiter.
