De kern van deze thread is dat “HTTPS op ZimaOS” eigenlijk meer dan één vertrouwensprobleem beschrijft. Een certificaat dat door het ZimaOS-dashboard wordt gebruikt, wordt niet automatisch het certificaat voor elke Docker-applicatie die op een andere hostnaam of poort draait.
Scheid HTTPS voor het dashboard van HTTPS voor apps
De huidige handleiding voor HTTPS-certificaten in ZimaOS legt dezelfde grens uit: het vertrouwen van het lokale ZimaOS-certificaat kan van toepassing zijn op de hostnaam van het dashboard, maar applicaties zoals Obsidian, Jellyfin of Plex zijn afzonderlijke services. Obsidian op ZimaOS is een nuttig voorbeeld, omdat browsergebaseerde apps hun eigen HTTPS- en beveiligingsvereisten kunnen hebben.
De hardware van ZimaBoard 2 biedt de actuele hardwarecontext voor ZimaBoard 2, maar het certificaatprobleem zelf is een kwestie van hostnaam, vertrouwensketen en reverse proxy, en geen beperking van het board.
Waarom het importeren van een CER-bestand het browserprobleem mogelijk niet oplost
Een vertrouwd certificaat moet overeenkomen met de hostnaam die de browser opent en moet teruggaan naar een vertrouwensanker dat door die client wordt geaccepteerd. Het importeren van één certificaat zorgt er niet voor dat niet-gerelateerde applicatiepoorten dit automatisch overnemen. Als de browser een IP-adres opent terwijl het certificaat een andere hostnaam bevat, kan het vertrouwen nog steeds mislukken.
Wanneer een openbaar certificaat nodig is
De Let's Encrypt-uitdagingen leggen uit dat voor het uitgeven van een openbaar certificaat moet worden bewezen dat je controle hebt over de domeinnaam via een ACME-uitdaging. Voor services die je via een echte hostnaam beschikbaar wilt maken, kan een reverse proxy TLS beëindigen en verkeer doorsturen naar interne app-poorten.
De Cloudflare Tunnel-configuratie koppelt op vergelijkbare wijze een openbare hostnaam via een Tunnel aan een lokale service. Daarmee wordt een ander probleem opgelost dan lokaal certificaatvertrouwen: het biedt een beheerd pad van een domeinnaam naar de interne applicatie.
Publiceer geen adminpoorten alleen voor een hangslot
Stel ZimaOS- of applicatiebeheerpoorten niet rechtstreeks bloot aan het openbare internet, alleen om een browserwaarschuwing te verwijderen. Bepaal eerst of de vereiste lokaal vertrouwen, externe toegang of openbaar HTTPS is en ontwerp vervolgens het certificaat- en proxypad voor precies die grens.
Kort samengevat
De communitythread bewees niet dat het ZimaOS-CER defect was. Waarschijnlijker was dat het dashboardcertificaat en afzonderlijke applicatieservices als één HTTPS-eindpunt werden behandeld. Vertrouw het dashboardcertificaat alleen voor de hostnaam die het dekt en gebruik indien nodig een correct geconfigureerde reverse proxy of een domeincertificaat voor andere apps.
