HA Core en https

Bonjour a tous

J’utilise Home Assistant « Core » (donc sans les add-ons) dans un docker dans un NUC Intel sous Ubuntu.

Je souhaite passer en https mais (comme de nombreuses personnes) je ne m’en sors pas.

la contrainte est que j’ai aussi un NAS synology qui tourne sur le même réseau, ce qui m’empêche de rediriger le port 80 vers le NUC.

Donc je ne peux pas utiliser letsencrypt.

J’ai une adresse de type xxx.duckdns.org qui fonctionne et qui redirige bien vers le NUC avec le port 8123.

Le protocole DNS-01 parait intéressant et depuis zerossl, j’ai récupéré des fichiers ca_bundle, certificate et private.key mais ce ne sont pas les fichiers pem necessaires a HA

Quelles solutions utilisez vous avec une configuration similaire ?

Merci d’avance

Cdlt

Philippe

tu ne peux pas désactiver le port 80 juste le temps d’effectuer le lets encrypt sur l’adresse duckdns ?
le certificat est au niveau du nom de domaine, donc une fois que c’est fait tu réactive le 80 sur ton NAS
et tu redirige le port 8123 sur ton HA
à tester… mais par contre si ca marche, il faudra refaire cette manipulation à chaque renouvellement

Tu peux investir dans un domaine, voir chez gandi les offres possibles. En ce moment, le .me est à 5 euros pour 1 an.
Ensuite, tu mets ton DNS chez cloudflare et tu peux avoir ton certificat pour tonsuperdomaine.eu valable 15 ans. C’est gratuit et pas de renouvellement à la mode Let’s encrypt.
Il y a un addon cloudflare qui permet de gérer les changements d’@IP chez toi.
Après, tu créés un tonha.tonsuperdomaine.eu dans le DNS et hop. C’est fait.

1 « J'aime »

Pourquoi t’empêche-t’ il ? Tu as déjà un NAT en 80 sur ton Synology ?

J’ai un Syno, j’utilise le proxy inversé qui est livré avec et Let’s encrypt aussi. Ensuite c’est le proxy inversé qui fait le chemin vers HA ou autre, donc rien de let’s encrypt sur HA !

Mon NAS a besoin du port 80 pour renouveler ses certificats .
Quand j’avais HA sur le NAS, le problème ne se posait pas car HA bénéficiait du ssl du NAS.

Depuis que j’ai migré HA sur un NUC, je dois choisir de rediriger les ports 90 et 443 soit vers le NAS , soit vers le NUC.
Dans l’absolu, une fois tous les 3 mois, ce n’est pas gênant mais ça n’est pas propre je trouve.

Je viens de regarder et mon NAS Synology n’a pas le port 80 de redirigé dessus. Juste un port exotique pour l’administration et le certificat Let’s Encrypt se renouvelle sans problème…

D’où l’intérêt du reverse proxy sur ton NAS, 1 seul point d’entrée, 1 ou plusieurs certificats, plusieurs destinations locales !

Oui mais justement je ne veux plus laisser HA sur le NAS pour plusieurs raisons:

  • fondamentalement le NAS ne sert pas à ça
  • les acces SSH sont risqués sur le NAS
  • la version DSM. 7 ne supporte plus l’USB donc HA sera à terme inutilisable
    Etc …
    Beaucoup de raisons pour mettre HA dans une machine dédiée indépendante du NAS

Surprenant car toutes les docs de letsencrypt demandent la redirection des ports 80 et 443 pour le renouvellement.

Encore une fois le principe du reverse proxy est de rediriger les requêtes vers une autre IP (donc soit un autre service de ton Syno soit … une autre machine avec HA par exemple).

Oui pour la 1ère fois que tu configures Let’s encrypt, lors du challenge (validation de ton domaine avec un jeton local). Ensuite, ce ne sera que du renouvellement et seul le 443 sera nécessaire.

Encore une fois le principe du reverse proxy est de rediriger les requêtes vers une autre IP (donc soit un autre service de ton Syno soit … une autre machine avec HA par exemple).

Oui mais cela a un sens quand tout est sur la meme machine. faire du reverse proxy entre 2 machines n’est pas cohérent à mon sens .

Oui pour la 1ère fois que tu configures Let’s encrypt, lors du challenge (validation de ton domaine avec un jeton local). Ensuite, ce ne sera que du renouvellement et seul le 443 sera nécessaire.

intéressant mais ne règle pas le problème des hooks qui demandent l’accès au port 443 vers HA

J’ai l’impression de tourner en rond !
en tous cas merci pour vos messages
Philippe

Moi, ça fait 2 ans que HA est accessible en https sur un port exotique. et aucun problème

Grace a ce super tuto:

https://www.splitbrain.org/blog/2017-08/10-homeassistant_duckdns_letsencrypt

j’ai pu configurer l’accès en https sans rediriger ni le port 80 ni le port 443 vers le NUC. seul le port 8123 est redirigé

quelques modifications a faire sachant que mon HA core est installé dans un docker

  • mettre le git dans /docker/homeassistant
  • remplacer
    sudo systemctl restart home-assistant@homeassistant.service
    par sudo docker restart « numero du docker »
    -changer les chemins des fichiers pem

Ca fonctionne en https tant en distant (https://xxx.duckdns.org:8123) qu’en local (https://192.168.x.y:8123)

Par contre ca ne fonctionne plus avec http://192.168.x.y:8123 ! pourtant j’ai bien
http://192.168.x.y:8123 dans URL interne dans le menu Configuration General de HA

J’ai fait un énorme pas !
Philippe

Ce qui est normal, un port est pour 1 protocols, donc soit HTTP soit HTTPS, mais pas les 2 !

le reverse proxy offre un service de point d’entrée unique, et est fortement adapté (et heureusement) devant un ensemble de machine/service.

L’accès au 443 est demandé par Let’s Encrypt, le certificat est UNIQUEMENT sur le reverse proxy, donc Let’s Encrypt doit aussi être sur le reverse proxy (la majorité propose ce service, Synologie aussi). De ce fait, la configuration coté HA est plus légère (et pour tous les services qui sont derrières ce reverse proxy d’ailleurs) !

2 « J'aime »

Hello
Oui c’est logique
il faudrait que je redirige le port 443 vers 8123 pour les accès en https (sans port donc défaut 443) depuis le Wan
pour l’instant je vais laisser le truc se roder tel quel car je n’ai toujours pas compris pourquoi la procédure décrite utilisant dehydrated fonctionne sans avoir redirigé aucun port vers le NUC sauf le 8123 !

Dernière question :
faut il continuer à saisir une ligne de type base_url: xxx.duckdns.org:8123 dans le fichier configuration.yaml en plus des informations saisies dans Configuration / Général ?
cela parait faire double emploi. pour l’instant je l’ai retirée et cela fonctionne

Car le script utilisé dans le tuto utilise la technique DNS-01, c’est à dire que le script va ajouter directement le token de challenge dans votre enregistrement DNS de DuckDNS (pour cela vous avez dû renseigner dans ce script vos identifiants DuckDNS j’imagine).
De cette façon, Let’s encrypt ne va pas chercher le token sur votre machine via le port 80, mais il va demander le token à DuckDNS. Pas d’ouverture de port !
=> Cette technique fonctionne uniquement si vous avez un script (comme celui du tuto) qui prend en charge la modification de vos données DNS chez votre Registrar (ici DuckDNS).

Pour la dernière question, le paramètre base_url dans le fichier de config est totalement inutile dans votre cas.

Merci pour l’explication.
Je suis étonné qu’il y ait autant de tutos hyper compliqués avec autant de voies de garage pour mettre en œuvre ssl quand celui datant quand même de plus de 3 ans fonctionne aussi bien du premier coup !
Bon il y a quand même quelques modifications à faire dans le cadre d’une utilisation en docker mais ça reste simple

Concernant le paramètre base_url, dans quels cas est il utile ?

En tous cas merci à tous pour les explications et la patience. Ce forum est extraordinaire et très sympathique.

Prochaine étape non spécifique HA: faire fonctionner Samba !

Philippe

En gros quand tu dois dire à quelqu’un en face comment tu t’appelles!
Typiquement pour un callback ou équivalent.
C’est expliqué là: 0.110: Speed! OpenZWave beta, HomeKit Cameras, ONVIF, Calendars - Home Assistant
Et en plus base_url est deprecated

Hello
donc ca ne sert plus. " After upgrading to 0.110, you can delete base_url from your configuration as Home Assistant will automatically migrate that setting for you on upgrade."
Merci !
Philippe