Générer un certificat HTTPS gratuit : jeedom, home assistant, nas synology et reverse proxy

Obtenir un accès à distance en https, sans payer de certificat, en sécurisant proprement jeedom et home assistant derrière un nas synology grâce à un reverse proxy, c’est surtout une affaire de cohérence: même nom de domaine partout, bons ports au bon moment, et vérifications avant d’ouvrir vers l’extérieur. Ce guide harmonise certificat ssl gratuit let’s encrypt, proxy inversé sur dsm et méthode de contrôle pour éviter les erreurs récurrentes de nom de domaine, de redirection et de certificate mismatch, avec une check-list opérationnelle et des pistes de dépannage concrètes.

Ce que change un certificat https et le rôle du reverse proxy

Un certificat https ne « sécurise » pas magiquement un service domotique: il chiffre la connexion (https), évite les alertes navigateur, et garantit que le client parle au bon serveur pour un nom de domaine donné. Sans certificat ssl valide, les navigateurs signalent un risque, et certains clients bloquent carrément l’accès, notamment quand hsts a été activé sur un domaine: le navigateur refusera alors toute tentative en http.

Le reverse proxy joue un autre rôle, souvent confondu avec le certificat: il centralise l’entrée et distribue vers les bons services internes. Sur un nas synology, l’intérêt fonctionnel est net: un même certificat ssl peut être utilisé pour plusieurs services accessibles de l’extérieur via différents sous-domaines, avec aiguillage vers la bonne destination (par exemple jeedom.domaine.tld vers un port local, ha.domaine.tld vers une vm ou un conteneur docker, nas.domaine.tld vers dsm).

Concrètement, le reverse proxy s’appuie sur le sni (server name indication): lorsque le client se connecte en https, il annonce le nom visé (ex. ha.domaine.tld), ce qui permet au nas de présenter le bon certificat et d’appliquer la bonne règle. Sans cette brique, on se retrouve vite à ouvrir des ports différents par service, à multiplier les règles de pare-feu et à bricoler des certificats séparés.

La conséquence pratique: vous pouvez n’exposer que les ports 80 et 443 côté internet, garder vos services internes sur leurs ports habituels, et gérer la sécurité au même endroit (pare-feu synology, règles de proxy inversé, certificats). Nom de domaine, ddns et sous-domaines: la base pour éviter les erreurs

Nom de domaine, ddns et sous-domaines: la base pour éviter les erreurs

Au 11/06/2026, le prérequis reste simple sur le papier: il faut un nom de domaine pointant vers l’adresse ip publique pour utiliser un reverse proxy, typiquement sous la forme sous-domaine.domaine.tld. Dans la pratique, l’erreur la plus fréquente n’est pas le proxy, mais la discordance entre l’url tapée et les noms réellement couverts par le certificat (san, wildcard).

Deux cas reviennent sans cesse quand « le certificat de home assistant ne correspond pas au nom de domaine »:

• vous tapez homeassistant.domaine.tld alors que le certificat a été émis pour ha.domaine.tld uniquement, ou l’inverse
• vous utilisez un ddns (ex. duckdns) pour l’url, mais le certificat a été généré pour un autre domaine, ou pour le domaine racine sans inclure le sous-domaine

Le dns doit être propre avant toute demande de certificat. La configuration de référence est la suivante:

• un enregistrement type a fait correspondre le nom de domaine avec l’adresse ip publique
• un enregistrement type cname avec un sous-domaine joker * permet de faire pointer tous les sous-domaines vers l’ip publique, pratique pour créer plusieurs accès (ex. jeedom.domaine.tld, web.domaine.tld, nas.domaine.tld)

Le ddns (dont duckdns) sert quand l’ip publique change. Le piège: le ddns met à jour l’ip, mais ne corrige pas un mauvais choix d’url. Si votre certificat couvre *.domaine.tld (wildcard), tout sous-domaine sera accepté; si votre certificat ne couvre qu’un nom précis, le moindre écart déclenche un certificate mismatch (souvent vu comme net::err_cert_common_name_invalid).

Autre cause réelle d’erreur: un navigateur « se souvient » via hsts. Après une tentative ratée, vous corrigez le certificat, mais le navigateur continue d’imposer https et de signaler un problème tant que la chaîne n’est pas parfaitement valide. D’où l’intérêt d’une méthode de vérification avant ouverture et avant activation d’hsts. Générer un certificat gratuit avec let’s encrypt sur synology

Générer un certificat gratuit avec let’s encrypt sur synology

Sur dsm, let’s encrypt fournit des certificats https gratuits, et dsm peut les renouveler automatiquement puis les lier au reverse proxy. Pour jeedom ou home assistant, l’idée est de générer un certificat pour le ou les noms réellement utilisés (un sous-domaine par service, ou un wildcard si vous voulez industrialiser).

Pré-requis réseau à respecter, sinon la demande échoue: les ports 80 et 443 doivent être correctement gérés sur le routeur et le pare-feu. La référence la plus robuste:

• ports à ouvrir/rediriger sur le routeur: 80 (http) et 443 (https)
• port 80: à ouvrir temporairement le temps de générer les certificats (challenge http-01)
• exemple de redirection: le trafic entrant internet sur le port 443 est redirigé vers le port 5001 du nas synology (port d’écoute https du synology)

Dans dsm, la procédure typique passe par la gestion des certificats (demande let’s encrypt), puis l’affectation du certificat au bon service. Si vous utilisez le challenge http-01, l’autorité vérifie votre contrôle du domaine via une requête http sur le port 80. Si ce port est fermé, filtré, ou redirigé vers un autre équipement, la validation échoue.

Quand privilégier un wildcard: dès que vous prévoyez plusieurs sous-domaines (jeedom, home assistant, dsm, web) et que vous voulez éviter de régénérer un certificat à chaque ajout. Le wildcard s’obtient classiquement via le challenge dns-01, qui valide via un enregistrement dns, sans dépendre du port 80. C’est souvent plus stable derrière certains routeurs ou connexions, et cela réduit la tentation d’exposer inutilement le port 80 en continu. Configurer le reverse proxy synology pour jeedom et home assistant

Configurer le reverse proxy synology pour jeedom et home assistant

La configuration du proxy inversé sur synology se fait à l’emplacement exact: panneau de configuration → portail de connexion → avancé → proxy inversé. En production, il n’est pas rare d’avoir de nombreuses règles, avec un exemple observé à 18 éléments, ce qui impose une nomenclature claire des sous-domaines.

Principe: une règle par service, basée sur le nom (sni) et le port externe. Exemple logique:

• source: https, hôte: jeedom.domaine.tld, port: 443 → destination: http(s) vers l’ip interne de jeedom et son port
• source: https, hôte: ha.domaine.tld, port: 443 → destination: http vers l’ip interne de home assistant (souvent 8123)

Ensuite, associer le bon certificat ssl à chaque sous-domaine dans dsm, sinon vous verrez un certificat « par défaut » qui ne correspond pas au nom demandé, typique d’un certificate mismatch même si le certificat existe bien.

Home assistant a des particularités: derrière reverse proxy synology, sans configuration complémentaire, l’accès externe peut renvoyer « 400: bad request ». La cause évoquée est un renforcement de la sécurité dans des mises à jour récentes; une version citée dans ce contexte est 2024.9.1. Deux points sont critiques: websocket et proxys de confiance.

• dans synology reverse proxy, vérifier/ajouter les en-têtes websocket upgrade et connection via l’onglet « en-tête personnalisé » (créer → websocket), sinon l’interface peut charger partiellement ou perdre des fonctions temps réel
• dans home assistant, éditer configuration.yaml (module complémentaire de type file editor ou visual studio code) et ajouter: use_x_forwarded_for: true et trusted_proxies avec l’ip du synology (ex. 192.168.1.250, à remplacer)

Pour la liste des proxys/ips de confiance, ajouter d’abord les adresses locales 127.0.0.1 et ::1, puis inclure toutes les adresses ip du nas (y compris celles non directement liées à home assistant, selon l’extrait). Et détail qui casse des déploiements: ne pas mettre de guillemets autour des valeurs external_url et internal_url quand vous les définissez dans la configuration actuelle.

En environnement docker, soyez strict sur les ports: le reverse proxy doit viser le port exposé sur le réseau interne (bridge ou macvlan selon votre design), pas un port « publié » uniquement vers l’hôte si l’architecture ne le permet pas. Si home assistant est en vm, une bonne pratique réseau mentionnée est d’attribuer une ip fixe via bail dhcp statique basé sur l’adresse mac, en dehors de la plage dhcp, pour éviter qu’une ip change et casse le proxy. Tests, dépannage et erreurs fréquentes: certificat, redirections, accès externe

Tests, dépannage et erreurs fréquentes: certificat, redirections, accès externe

La méthode la plus efficace est de diagnostiquer dans l’ordre: dns → certificat → sni → proxy → application. Elle évite de « corriger » home assistant alors que le problème est un mauvais sous-domaine, ou de régénérer un certificat alors que c’est une redirection de ports.

• dns: vérifier que le domaine/sous-domaine pointe vers l’ip publique (enregistrement a) et que le wildcard via cname * est cohérent si vous l’utilisez
• ports: confirmer la redirection de ports et l’ouverture sur le pare-feu; le port 80 peut être requis temporairement pour le challenge http-01, et le 443 doit être stable
• certificat: contrôler le nom commun et les san (subject alternative names) pour vérifier que ha.domaine.tld ou *.domaine.tld est bien couvert
• sni: tester que le bon certificat est présenté pour chaque sous-domaine; un mauvais mapping renvoie souvent le certificat du nas ou d’un autre service
• reverse proxy: consulter les logs et observer les codes 502/504 (destination injoignable) versus 400 (souvent applicatif, typique home assistant)

Symptômes typiques et causes réelles:

Quand « l’accès externe » apparaît comme désactivé dans paramètres → système, ne partez pas du principe que c’est un bug d’interface: c’est souvent le reflet d’une chaîne proxy non conforme. Dans les cas rapportés, la mise en conformité (trusted_proxies, websocket) est annoncée comme un temps nécessaire: 5 minutes, mais uniquement si le dns et le certificat sont déjà corrects, sinon vous pouvez tourner en rond longtemps.

Dernier piège: les redirections http vers https. Si vous forcez trop tôt une redirection globale, vous pouvez empêcher le challenge http-01 de passer, ou créer une boucle si le reverse proxy réécrit mal les en-têtes. D’où l’intérêt de valider d’abord l’obtention du certificat, puis la stabilité du proxy, avant de durcir. Bonnes pratiques de sécurité pour un accès à distance gratuit et durable

Bonnes pratiques de sécurité pour un accès à distance gratuit et durable

Un accès à distance gratuit ne doit pas devenir une exposition permanente inutile. Le socle: n’exposer que ce qui est nécessaire, chiffrer partout, et réduire la surface d’attaque au niveau du nas synology, du pare-feu et des services.

• rediriger http vers https, mais seulement après validation du certificat; garder le port 80 fermé hors phase de challenge http-01 si vous n’en avez pas besoin
• hsts: utile pour empêcher le downgrade en http, mais à activer prudemment, car une erreur de certificat devient alors bloquante côté navigateur
• pare-feu synology: limiter les sources (ip ou pays si pertinent), restreindre l’accès à dsm, et n’autoriser que 443 depuis l’extérieur quand c’est possible
• authentification: mots de passe robustes, 2fa sur dsm et sur les comptes exposés, et séparation des comptes d’administration
• segmentation: isoler jeedom, home assistant, docker et le nas sur des réseaux ou règles distinctes si votre matériel le permet

Si l’objectif est « home assistant à distance gratuitement sans s’exposer inutilement », les alternatives à l’exposition directe restent valables selon votre contexte: vpn ou tunnels, qui réduisent la dépendance aux redirections de ports et au maintien d’un point d’entrée public. Dans tous les cas, gardez la discipline de la vérification avant ouverture: dns cohérent, certificat lié au bon hôte, règles de proxy minimales, et tests sni.

FAQ

Pourquoi le certificat de home assistant ne correspond pas au nom de domaine ?

Parce que l’url utilisée (nom de domaine ou sous-domaine) ne correspond pas aux noms couverts par le certificat (cn/san), ou parce que le certificat n’est pas affecté au bon hôte dans dsm, ce qui présente un certificat par défaut via sni.

Pourquoi l’accès externe home assistant est désactivé ou ne fonctionne pas ?

Derrière reverse proxy, home assistant peut refuser la requête (400: bad request) si trusted_proxies et use_x_forwarded_for ne sont pas configurés, et si websocket n’est pas correctement géré dans le reverse proxy synology.

Comment faire un reverse proxy synology pour jeedom ?

Dans dsm: panneau de configuration → portail de connexion → avancé → proxy inversé, créer une règle https pour jeedom.sous-domaine vers l’ip interne de jeedom et son port, puis associer le certificat ssl correspondant au sous-domaine.

Comment activer l’accès externe home assistant proprement ?

Configurer une règle de proxy inversé vers le port 8123, ajouter les en-têtes websocket (upgrade, connection) dans synology, puis dans configuration.yaml définir use_x_forwarded_for: true et trusted_proxies avec 127.0.0.1, ::1 et l’ip du nas, sans guillemets pour external_url/internal_url si vous les utilisez.

Un accès externe fiable tient moins à la quantité de réglages qu’à leur alignement: dns exact, certificat couvrant le bon sous-domaine, sni cohérent, reverse proxy propre, puis ajustements home assistant (websocket, trusted_proxies) avant tout durcissement hsts et pare-feu.