L’essentiel de cette discussion est que « HTTPS sur ZimaOS » désigne en réalité plusieurs problèmes de confiance. Un certificat utilisé par le tableau de bord ZimaOS ne devient pas automatiquement le certificat de chaque application Docker exécutée sur un autre nom d’hôte ou port.
Séparer le HTTPS du tableau de bord de celui des applications
Le guide actuel sur les certificats HTTPS de ZimaOS explique la même distinction : faire confiance au certificat local de ZimaOS peut couvrir le nom d’hôte du tableau de bord, mais des applications comme Obsidian, Jellyfin ou Plex sont des services distincts. Obsidian sur ZimaOS en est un exemple utile, car les applications accessibles depuis un navigateur peuvent avoir leurs propres exigences en matière de HTTPS et de sécurité.
Le matériel ZimaBoard 2 fournit le contexte matériel actuel de ZimaBoard 2, mais le problème de certificat lui-même concerne le nom d’hôte, la chaîne de confiance et le proxy inverse, et non une limitation de la carte.
Pourquoi l’importation d’un fichier CER peut ne pas résoudre le problème du navigateur
Un certificat approuvé doit correspondre au nom d’hôte ouvert par le navigateur et être rattaché à une autorité de confiance acceptée par ce client. L’importation d’un certificat ne permet pas aux ports d’applications sans lien d’en hériter. Si le navigateur ouvre une adresse IP alors que le certificat mentionne un autre hôte, la confiance peut tout de même échouer.
Quand un certificat public est nécessaire
Les défis de Let's Encrypt expliquent que l’émission d’un certificat public nécessite de prouver le contrôle du nom de domaine au moyen d’un défi ACME. Pour les services que vous souhaitez exposer via un véritable nom d’hôte, un proxy inverse peut terminer la connexion TLS et rediriger le trafic vers les ports internes de l’application.
La configuration de Cloudflare Tunnel associe elle aussi un nom d’hôte public à un service local via un tunnel. Cela peut résoudre un problème différent de celui de la confiance accordée à un certificat local : cette solution fournit un chemin géré entre un nom de domaine et l’application interne.
Ne publiez pas les ports d’administration uniquement pour afficher un cadenas
N’exposez pas directement les ports d’administration de ZimaOS ou des applications sur Internet simplement pour supprimer un avertissement du navigateur. Déterminez d’abord si le besoin concerne la confiance en local, l’accès à distance ou le HTTPS public, puis concevez le chemin du certificat et du proxy en fonction de cette limite précise.
En résumé
La discussion de la communauté ne prouvait pas que le fichier CER de ZimaOS était défectueux. Il est plus probable que le certificat du tableau de bord et les services d’application distincts aient été traités comme un seul point de terminaison HTTPS. N’accordez votre confiance au certificat du tableau de bord que pour le nom d’hôte qu’il couvre, et utilisez si nécessaire un proxy inverse correctement configuré ou un certificat de domaine pour les autres applications.
