Solution communautaire

Corriger les avertissements HTTPS sur ZimaOS et les applications auto-hébergées

A ZimaOS user wanted to remove browser security warnings from the dashboard and every hosted app. The thread clarified the local ZimaOS certificate, Windows trust-store import, and why separate apps need their own HTTPS or a reverse proxy.

Si votre navigateur avertit que le tableau de bord ZimaOS ou les applications sont « Non sécurisés », commencez par distinguer le tableau de bord principal de ZimaOS des applications exécutées derrière leurs propres ports. La discussion source a finalement établi qu’il s’agissait de deux problèmes HTTPS différents.

ZimaOS peut générer un certificat local pour https://zimaos.local. Faire confiance à ce certificat peut supprimer l’avertissement du navigateur pour le tableau de bord ZimaOS. Cela ne fournit pas automatiquement HTTPS à Plex, Jellyfin, Emby, AdGuard ou aux autres applications Docker, car il s’agit de services HTTP distincts. Pour placer plusieurs applications derrière des noms HTTPS approuvés, utilisez un proxy inverse tel que Nginx Proxy Manager ou Caddy avec les certificats appropriés.

L’avertissement d’origine du navigateur

Avertissement de certificat du navigateur affiché lors de l’ouverture du tableau de bord local ZimaOS via HTTPS
L’auteur de la source voulait arrêter de devoir contourner l’avertissement de certificat du navigateur à l’ouverture de ZimaOS.

Option 1 : Désactiver HTTPS pour le tableau de bord ZimaOS local

Zima-Giorgio a répondu qu’il était possible de désactiver HTTPS dans le panneau Paramètres de ZimaOS. Sur un réseau local privé de confiance, le simple HTTP peut éviter les avertissements liés au certificat, mais il supprime également le chiffrement des données entre le navigateur et le tableau de bord.

Écran des paramètres de ZimaOS affichant le certificat HTTPS local et les contrôles de sécurité
La réponse source de 2025 indiquait où gérer le comportement HTTPS local dans ZimaOS.

Pour les ordinateurs portables ou les appareils qui changent de réseau, il est généralement préférable de faire confiance au certificat ZimaOS plutôt que d’affaiblir globalement la sécurité du navigateur.

Option 2 : Télécharger et approuver le certificat local ZimaOS

La réponse officielle recommandait de télécharger le fichier CRT généré et de lui faire confiance sur le client. Une fois la confiance configurée, utilisez :

https://zimaos.local
Interface ZimaOS permettant de télécharger le certificat CRT HTTPS local généré
Le CRT généré est destiné à établir la confiance pour le nom d’hôte du tableau de bord ZimaOS local.

Faire confiance au CRT de ZimaOS sous Windows

La réponse source indiquait cette procédure Windows :

  1. Appuyez sur Win + R.
  2. Exécutez certmgr.msc.
  3. Ouvrez Autorités de certification racines de confiance → Certificats.
  4. Choisissez Toutes les tâches → Importer.
  5. Sélectionnez le fichier CRT téléchargé depuis votre propre système ZimaOS.
  6. Placez-le dans Autorités de certification racines de confiance.
  7. Redémarrez le navigateur.

Ne faites confiance qu’à un certificat obtenu depuis votre propre instance ZimaOS connue. Installer un certificat racine signifie lui faire confiance pour valider les connexions sur ce client.

Pourquoi le certificat ZimaOS ne sécurise pas Jellyfin, Plex ou Emby

L’auteur original a ensuite importé le certificat avec succès sur Pop!_OS et a confirmé que zimaos.local cela fonctionnait, mais Plex, Emby et Jellyfin apparaissaient toujours comme non sécurisés.

Une réponse de 2026 a expliqué pourquoi : ces applications écoutent sur des services et des ports distincts. Voici quelques exemples :

Jellyfin : http://ZIMAOS_IP:8096
Plex :     http://ZIMAOS_IP:32400

Elles n’héritent pas automatiquement du certificat du tableau de bord ZimaOS. Ce comportement est normal et ne signifie pas que l’importation du certificat CRT a échoué.

Utiliser un proxy inverse pour le HTTPS de plusieurs applications

Pour donner aux applications des noms tels que :

https://jellyfin.example.com
https://emby.example.com
https://adguard.example.com

placer un proxy inverse devant elles. Le proxy gère les certificats TLS, puis redirige chaque requête vers le port HTTP interne de l’application.

Nginx Proxy Manager est actuellement disponible dans l’App Store de ZimaOS :

Nginx Proxy Manager pour ZimaOS

Pourquoi Nginx Proxy Manager indique que les ports 80 ou 443 sont déjà utilisés

L’auteur de la source a essayé d’installer un proxy et a immédiatement rencontré un conflit de ports. La documentation actuelle de Nginx Proxy Manager prévoit ces ports standard :

80 → HTTP public
443 → HTTPS public
81 → interface d’administration de NPM

Si ZimaOS utilise déjà les ports hôtes 80 ou 443, NPM ne peut pas utiliser simultanément le même port hôte.

Configuration officielle de Nginx Proxy Manager

Le port 81 n’est pas la destination HTTPS publique

Un autre utilisateur du même fil a redirigé les ports 80 et 443 du routeur vers le port interne 81. La communauté l’a corrigé :

Routeur 80 → port 80 de NPM
Routeur 443 → port 443 de NPM

Port 81 Il s’agit de l’interface d’administration de NPM. Elle ne doit pas recevoir le trafic ordinaire d’un site web public.

Défi HTTP ou défi DNS

Le fil a également distingué deux méthodes de validation de Let's Encrypt :

  • Défi HTTP : exige généralement que l’autorité de certification puisse joindre le proxy via le port 80.
  • Défi DNS : vérifie le contrôle du domaine via les enregistrements ou l’API du fournisseur DNS et peut éviter la validation entrante sur le port 80.

Choisissez volontairement une méthode. Ne combinez pas les paramètres des deux approches sans comprendre quelle méthode de validation NPM utilise.

Avez-vous besoin de MySQL pour faire fonctionner Nginx Proxy Manager ?

Non. La configuration actuelle de Nginx Proxy Manager prend en charge SQLite pour une installation simple dans un conteneur unique. Une base de données MySQL/MariaDB/PostgreSQL externe est facultative.

Cela répond à une autre préoccupation soulevée dans le fil source : un débutant n’a pas besoin de déployer MySQL simplement pour commencer à utiliser un proxy inverse pour quelques services domestiques.

Modifier le port Web de ZimaOS implique un compromis

Plus loin dans le fil, un utilisateur a déplacé ZimaOS du port 80 et a alors pu installer Nginx Proxy Manager. Cependant, des rapports distincts de la communauté en 2026 indiquent que la modification du port du tableau de bord ZimaOS peut perturber le fonctionnement du client de bureau et de l’application mobile Zima.

Ainsi, « déplacer ZimaOS du port 80 » n’est pas une solution universelle sans risque. Avant de le modifier, déterminez ce qui est le plus important dans votre environnement :

  • la gestion standard des ports 80/443 par un proxy inverse ;
  • ou préserver le comportement par défaut du client et de la découverte de ZimaOS.

HTTPS local uniquement ou HTTPS public

Si vous utilisez uniquement les applications chez vous :

  • vous pouvez conserver le HTTP direct sur un réseau local de confiance ;
  • utilisez des certificats approuvés localement ;
  • ou exécutez un proxy inverse interne et un DNS interne.

Si vous souhaitez utiliser le HTTPS depuis Internet, utilisez un domaine, une authentification forte, des certificats correctement délivrés et une conception réfléchie de l’accès à distance et de la sécurité. N’exposez pas les ports d’administration des applications ni l’interface d’administration de NPM simplement pour faire apparaître le cadenas dans le navigateur.

Liste de contrôle du HTTPS de ZimaOS

  1. Déterminez si l’avertissement concerne zimaos.local ou une application distincte.
  2. Pour le tableau de bord ZimaOS, téléchargez et approuvez le CRT généré si vous souhaitez utiliser le HTTPS local sans avertissements.
  3. Utilisez https://zimaos.local une fois le certificat approuvé.
  4. Ne vous attendez pas à ce que le CRT de ZimaOS sécurise des ports d’application distincts.
  5. Utilisez un proxy inverse pour les noms d’hôte HTTPS de plusieurs applications.
  6. Vérifiez quel service utilise les ports 80 et 443 avant d’installer NPM.
  7. Conservez le port 81 de NPM pour l’administration, et non pour la redirection d’un site public.
  8. Choisissez la validation par HTTP ou par DNS selon votre réseau.
  9. N’exposez pas de services d’administration inutiles sur Internet.

FAQ sur le HTTPS de ZimaOS

Pourquoi zimaos.local est-il sécurisé alors que Jellyfin utilise toujours HTTP ?

Parce que le certificat ZimaOS s’applique au nom d’hôte du tableau de bord. Jellyfin est un service distinct qui écoute sur son propre port.

Un seul proxy inverse peut-il sécuriser toutes mes applications ZimaOS ?

Il peut terminer les connexions HTTPS pour plusieurs services HTTP, à condition que chaque hôte proxy soit correctement configuré et que le proxy puisse atteindre l’application cible.

Pourquoi Nginx Proxy Manager ne peut-il pas démarrer sur le port 443 ?

Un autre service utilise déjà ce port sur l’hôte. Le fil de discussion d’origine a rencontré ce problème lorsque ZimaOS et NPM se disputaient les ports Web standard.

Le port 81 est-il celui vers lequel je dois rediriger le trafic HTTPS public ?

Non. Le port 81 correspond à l’interface d’administration de NPM. Le trafic public normal doit arriver sur les ports 80 et 443.