Activer le HTTPS pour le tableau de bord ZimaOS ne fournit pas automatiquement une adresse HTTPS à Jellyfin, Vaultwarden, Nginx Proxy Manager ou toute autre application Docker. C’est précisément ce malentendu qui a donné naissance à cette discussion de février 2026. L’utilisateur avait activé le HTTPS dans les paramètres de ZimaOS, enregistré le certificat généré pour l’interface ZimaOS et tenté de l’importer dans Nginx Proxy Manager, mais Jellyfin et NPM ne fonctionnaient toujours pas comme prévu.
La discussion a finalement abouti à une configuration communautaire fonctionnelle : utiliser Nginx Proxy Manager comme point de terminaison TLS pour chaque application, déplacer la passerelle ZimaOS des ports 80 et 443 si ces ports sont nécessaires au proxy inverse, configurer un nom d’hôte via DuckDNS et émettre un certificat pour ce nom d’hôte. L’utilisateur source a ensuite publié une capture d’écran montrant les hôtes proxy en ligne et a résumé le résultat comme fonctionnel.
Comprendre les trois couches HTTPS distinctes
Il existe trois éléments différents qu’il est facile de confondre :
- Le HTTPS du tableau de bord ZimaOS protège l’interface de gestion de ZimaOS elle-même.
- Le HTTP de l’application est le port interne normalement utilisé par une application comme Jellyfin.
- Le HTTPS du proxy inverse correspond à un nom d’hôte public ou local qui termine le TLS et redirige le trafic vers le port HTTP interne de l’application.
Le certificat généré pour l’interface de gestion ZimaOS n’est donc pas un certificat universel pour toutes les applications. Un proxy inverse a besoin d’un certificat dont le nom d’hôte correspond à l’adresse réellement ouverte par les utilisateurs dans leur navigateur.
Utiliser Nginx Proxy Manager comme point d’entrée HTTPS
L’aspect le plus réutilisable de la solution communautaire est l’architecture, plutôt que les numéros de port exacts de 2026. Nginx Proxy Manager reçoit les requêtes HTTPS pour des noms d’hôte tels que jellyfin.example.net et les redirige vers le service HTTP local de Jellyfin. Jellyfin peut continuer à écouter sur son port interne habituel ; il n’a pas besoin de gérer lui-même le certificat public.
La version actuelle de Nginx Proxy Manager conserve ce modèle : créer un hôte proxy, indiquer l’hôte et le port de destination, puis lui associer un certificat SSL et, éventuellement, forcer le SSL. Pour une nouvelle configuration, suivez le processus actuel de Nginx Proxy Manager pour les hôtes proxy et les certificats, plutôt que de considérer une ancienne capture d’écran comme une description immuable de l’interface.
Résoudre les conflits sur les ports 80 et 443 avant d’émettre les certificats
L’utilisateur source a découvert que la passerelle ZimaOS utilisait déjà les ports 80 et 443. C’est important, car un proxy inverse souhaite généralement écouter sur ces ports standard. La solution de contournement a consisté à modifier les ports de la passerelle ZimaOS dans /etc/casaos/gateway.ini, en remplaçant le port 80 par 85 et le port 443 par 444, puis à redémarrer le service de la passerelle.
Ces modifications précises provenaient de l’utilisateur et non d’une réponse officielle du support IceWhale dans cette discussion. Elles doivent être considérées comme une solution communautaire historique, et non comme une suite de commandes universelle. Avant de modifier les ports du tableau de bord, notez l’URL actuelle, assurez-vous de savoir comment accéder à nouveau à ZimaOS et privilégiez l’interface actuelle de ZimaOS lorsqu’elle propose une méthode prise en charge pour modifier le port de gestion.
Pourquoi DuckDNS a aidé l’utilisateur source
Une autorité de certification a besoin d’un nom d’hôte qu’elle peut valider. L’utilisateur a configuré DuckDNS, puis utilisé ce nom d’hôte pour demander un certificat via Nginx Proxy Manager. Cela a résolu un problème différent de « comment accéder à l’application ? » : le DNS a fourni le nom, tandis que NPM a assuré la terminaison HTTPS et la redirection.
Le HTTPS local nécessite également un DNS qui se résout localement
La question d’origine portait spécifiquement sur le HTTPS à l’intérieur du réseau local, et non sur l’accès à distance. Un nom de domaine n’oblige pas le trafic à quitter le domicile. Vous pouvez faire en sorte qu’un nom d’hôte se résolve vers l’adresse LAN de ZimaOS au sein de votre réseau grâce à un DNS local ou à un DNS fractionné, puis laisser Nginx Proxy Manager fournir un certificat approuvé pour ce nom d’hôte.
C’est généralement plus propre que de naviguer vers une adresse IP privée brute et d’essayer de faire correspondre un certificat public à celle-ci. Le certificat est validé pour le nom d’hôte ; votre DNS local détermine que ce nom d’hôte doit se résoudre vers une adresse privée.
Un certificat autosigné est une autre possibilité, mais sa confiance doit être gérée
Une réponse de la communauté suggérait de générer un certificat avec OpenSSL et de l’importer dans Nginx Proxy Manager. Cela peut fonctionner pour un usage exclusivement local, mais les navigateurs et les appareils ne font pas automatiquement confiance à un certificat autosigné. Chaque client devant afficher une connexion HTTPS valide doit faire confiance au certificat émetteur ou à l’autorité de certification locale.
Pour un foyer comptant de nombreux téléphones, téléviseurs, tablettes et applications, l’utilisation d’un certificat publiquement approuvé pour un nom d’hôte est souvent plus simple que l’installation manuelle d’une autorité de certification locale partout.
Cloudflare est une architecture alternative, pas une obligation
Un autre participant a indiqué utiliser Cloudflare à la fois à l’intérieur et à l’extérieur de son réseau domestique. Cloudflare peut être utile si le même nom d’hôte doit fonctionner à distance, mais la question source ne nécessitait pas d’accès public. N’ajoutez pas un tunnel simplement parce que vous souhaitez utiliser le HTTPS sur le réseau local.
Vérifier chaque couche séparément
- Vérifiez que l’application s’ouvre via son adresse HTTP locale directe.
- Vérifiez que le nom d’hôte se résout vers le proxy inverse prévu.
- Vérifiez que Nginx Proxy Manager peut atteindre l’hôte et le port internes de l’application.
- Associez le certificat uniquement après avoir vérifié que le routage proxy simple fonctionne.
- Forcez ensuite le HTTPS et testez depuis plusieurs clients locaux.
Cette méthode évite de confondre un problème de certificat avec un problème de routage Docker ou de conflit de ports.
FAQ sur le HTTPS local dans ZimaOS
Le bouton HTTPS de ZimaOS sécurise-t-il automatiquement Jellyfin ?
Non. Il sécurise l’interface de gestion de ZimaOS, et non toutes les applications Docker.
Ai-je besoin d’un domaine public pour utiliser le HTTPS uniquement sur le réseau local ?
Vous avez besoin d’un nom d’hôte correspondant à votre certificat. Ce nom d’hôte peut se résoudre vers une adresse LAN privée au sein de votre réseau.
Pourquoi l’utilisateur source a-t-il déplacé ZimaOS des ports 80 et 443 ?
Nginx Proxy Manager avait besoin des ports HTTP et HTTPS standard. Cette modification constituait une solution communautaire adaptée à cette installation.
La configuration source a-t-elle été confirmée comme fonctionnelle ?
Oui. L’auteur de la publication d’origine a montré les hôtes NPM en ligne avec leurs certificats et a indiqué que la configuration fonctionnait.
