TuringFan

Merci @Kramlech. J'ai bien un DNS local fonctionnel puisque j'acc_de depuis mon LAN à mes services via https://service.ndd.tld depuis le navigateur de mon PC. Les problèmes de connexion parfois observés sont eux uniquement sur des applications iPhone depuis le même LAN en pointant vers via https://service.ndd.tld:443. Étrange donc ... Je pousse le bouchon mais aurais tu également une idée pour ça (observé sur le WAN et le LAN) ?

Merci @Kramlech, Ok, je dois donc toujours écrire https://service.ndd.tld:443. En revanche pourquoi cela semble t il parfois fonctionner en WAN mais pas en LAN ? Est(ce car en LAN l'application n'est plus contrainte par mon pare-feu et peut donc appeler le port spécifique du service en évitant donc le port 443 de mon reverse proxy ? Comment corriger ce comportement ?

Bonjour à tous, J'ai visité la page Synology dédiée à la description des ports à utiliser pour les différents services mais tout n'est pas encore clair pour moi. Application iOS Tous mes services sont accessibles via reverse proxy en https (entrées https qui pointent ensuite vers les ports internes des applications en http) avec des adresses du type service.ndd.tld. Modulo quelques garde-fous sur les droits des utilisateurs (dossiers, applications) et les IPs utilisées (LAN/VPN vs. WAN) cette configuration est parfaitement fonctionnelle depuis un PC quelconque (vérifié sur différentes machines et différents réseaux). En revanche j'ai remarqué (sur plusieurs appareils en LAN/VPN/WAN) à plusieurs reprises des comportements très erratiques de connexion depuis les applications iOS (l'accès depuis le même appareil via l'interface web étant parfaitement fonctionnel) qui m'obligent à systématiquement tâtonner pour trouver quoi indiquer dans l'interface de connexion de l'application iOS : https://service.ndd.tld:443 https://service.ndd.tld service.ndd.tld:443 service.ndd.tld service.ndd.tld:X (avec X un port spécifique à ce service) cocher ou non l'option https Plus étonnant encore je remarque parfois qu'après une connexion réussie en WAN celle-ci n'est pas fonctionnelle en LAN ! A priori il ne peut pas s'agir de problèmes de droits et/ou mots de passe car (i) l'accès via l'interface web est toujours fonctionnelle et (ii) j'utilise un gestionnaire de mot de passe synchronisé sur mes appareils iOS et mes PC. PS : j'utilise notamment les applications DS Router, DS Finder, VPN Plus, DS Cam, DS File, Drive, Moments, DS Video, DS Chat, Mail. Interface web J'ai aussi remarqué que mon accès via l'interface Drive était parfaitement fonctionnelle sauf en ce qui concerne le chargement d'un fichier (depuis mon PC vers le NAS) : j'obtiens systématiquement le message d'erreur "Erreur de l'opération". La même opération est par contre parfaitement réalisable (au même moment, avec le même fichier, vers le même emplacement, sur le même réseau, avec le même PC et le même utilisateur) mais depuis File Station ! Ma question Tous ces éléments me font penser à des problèmes de ports mais je ne comprends pas suffisamment finement ce sujet pour savoir ce qui cloche. Quelles sont normalement les formats des adresses à indiquer dans les interfaces de connexion des applications iOS ? Ma configuration Livebox fibre Routeur Synology avec DNS local NAS (en DMZ) du Routeur avec pare-feu, reverse proxy et paquets des services Transfert de port sur mon routeur Pare-feu sur mon routeur Très étonnamment j'ai parfois remarqué qu'il fallait, en plus de transférer un port, l'ouvrir également sur le routeur ! Pare-feu sur mon NAS Merci d'avance pour votre aide !

Merci @PiwiLAbruti, @Jeff777 et @maxou56 pour vos réponses. Si un jour une solution de contournement existe je suis preneur ! Mais plus important encore, pour ma culture, je suis curieux de savoir comment la Livebox bloque le DNS local et/ou le Reverse Proxy ? Si la Livebox a aujourd'hui ce comportement, pourquoi pas d'autres appareils demain ? Merci d'avance,

Bonjour à tous, J'ai mon routeur en DMZ de ma Livebox, celle-ci est accessible via https://192.168.1.1. J'ai créé sur le DNS local de mon routeur une entrée box.ndd.tld => A 86400 192.168.1.1 et j'ai fait un flush dns mais impossible d'atteindre ma box via cette adresse. Je dois taper l'IP. Cela vient il du fait que le DNS n'est valable que sur le sous réseau créé par mon Routeur et ne peut pas pointer en dehors ? Comment faire pour rendre l'adresse https://box.ndd.tld fonctionnel ? PS j'ai également essayé avec un reverse proxy mais même problème ... Merci d'avance pour votre aide,

Merci @oracle7 mon certificat est bien à jour ! Voici ce que j'ai fait (en espérant que ça aidera) : J'ai complété mon fichier account.conf pour en avoir un de la forme : LOG_FILE='/volume1/Certs/Acme_renew/acmelog' #LOG_LEVEL=1 AUTO_UPGRADE='1' #NO_TIMESTAMP=1 CERT_HOME='/volume1/Certs' ACCOUNT_EMAIL='email@orange.fr' UPGRADE_HASH='XXX' DEFAULT_ACME_SERVER='https://acme-v02.api.letsencrypt.org/directory' SAVED_OVH_AK='XXX' SAVED_OVH_AS='XXX' SAVED_OVH_CK='XXX' SAVED_DID='XXX' USER_PATH=':/sbin:/bin:/usr/sbin:/usr/bin:/usr/syno/sbin:/usr/syno/bin:/usr/local/sbin:/usr/local/bin' A noter c'est bien une variable "SAVED_OVH_CK" qui y apparait et non "OVH_CK" : j'avais lancé dans cette config en attendant ta réponse et ça a fonctionné ... bizarre ... J'ai exécuté la commande deploy : ./acme.sh --deploy -d "$CERT_DOMAIN" --deploy-hook synology_dsm pour obtenir [Sun Mar 20 12:41:24 CET 2022] Logging into localhost:5000 [Sun Mar 20 12:41:25 CET 2022] Getting certificates in Synology DSM [Sun Mar 20 12:41:26 CET 2022] Generate form POST request [Sun Mar 20 12:41:26 CET 2022] Upload certificate to the Synology DSM [Sun Mar 20 12:42:29 CET 2022] http services were restarted [Sun Mar 20 12:42:30 CET 2022] Success Pas certain de bien comprendre pourquoi j'obtiens un "success" ici car (i) si je comprends bien mon certificat n'était alors pas encore à jour et (ii) comme tu l'avais deviné j'utilise une connexion avec 2FA (ce qui semble aujourd'hui poser problème pour le déploiement). J'ai ensuite lancé une MAJ d'ACME cd /usr/local/share/acme.sh ./acme.sh --force --upgrade --nocron --home /usr/local/share/acme.sh Pour obtenir : [Sun Mar 20 12:50:37 CET 2022] Installing from online archive. [Sun Mar 20 12:50:37 CET 2022] Downloading https://github.com/acmesh-official/acme.sh/archive/master.tar.gz [Sun Mar 20 12:50:38 CET 2022] Extracting master.tar.gz [Sun Mar 20 12:50:38 CET 2022] It is recommended to install socat first. [Sun Mar 20 12:50:38 CET 2022] We use socat for standalone server if you use standalone mode. [Sun Mar 20 12:50:38 CET 2022] If you don't use standalone mode, just ignore this warning. [Sun Mar 20 12:50:38 CET 2022] Installing to /usr/local/share/acme.sh [Sun Mar 20 12:50:38 CET 2022] Installed to /usr/local/share/acme.sh/acme.sh [Sun Mar 20 12:50:38 CET 2022] Good, bash is found, so change the shebang to use bash as preferred. [Sun Mar 20 12:50:41 CET 2022] OK [Sun Mar 20 12:50:41 CET 2022] Install success! [Sun Mar 20 12:50:41 CET 2022] Upgrade success! J'ai exporté mes variables : cd /volume1 cd Certs/Acme_install cd acme.sh-master ACME_HOME="/usr/local/share/acme.sh" CERT_HOME="/volume1/Certs" cd $ACME_HOME export OVH_END_POINT=ovh-eu export OVH_AK="votre application key" export OVH_AS="votre application secret" export OVH_CK="votre consumer key" cd $ACME_HOME export CERT_DOMAIN="votre-domaine.tld" export CERT_WDOMAIN="*.votre-domaine.tld" export CERT_DNS="dns_ovh" export SYNO_DID=xxx pwd export SYNO_Scheme="http" export SYNO_Hostname="localhost" export SYNO_Port="5000" export SYNO_Username='DSM_Admin_Username' export SYNO_Password='DSM_Admin_Password!123' export SYNO_Certificate="ACME_Wilcard_LE_*.ndd.tld" export SYNO_Create=1 J'ai paramétré ACME pour utiliser LE et non ZeroSSL comme indiqué dans ton edit de juin 2021 : cd $ACME_HOME ./acme.sh --issue --keylength 4096 -d "$CERT_DOMAIN" -d "$CERT_WDOMAIN" --dns "$CERT_DNS" --set-default-ca --server letsencrypt [Sun Mar 20 15:32:52 CET 2022] Changed default CA to: https://acme-v02.api.letsencrypt.org/directory J'ai lancé un renouvellement : ./acme.sh --issue --keylength 4096 -d "$CERT_DOMAIN" -d "$CERT_WDOMAIN" --dns "$CERT_DNS" [Sun Mar 20 15:34:15 CET 2022] Using CA: https://acme-v02.api.letsencrypt.org/directory [Sun Mar 20 15:34:15 CET 2022] Domain key exists, do you want to overwrite the key? [Sun Mar 20 15:34:15 CET 2022] Add '--force', and try again. [Sun Mar 20 15:34:15 CET 2022] Create domain key error. [Sun Mar 20 15:34:15 CET 2022] Please check log file for more details: /volume1/Certs/Acme_renew/acmelog [Sun Mar 20 15:34:15 CET 2022] Creating domain key ./acme.sh --issue --keylength 4096 -d "$CERT_DOMAIN" -d "$CERT_WDOMAIN" --dns "$CERT_DNS" --force Et miracle cela a fonctionné ! J'ai ensuite utilisé WinSCP pour télécharger les fichier du certificat et les importer à la main dans mon NAS et mon Routeur. Maintenant mon navigateur m'affiche bien un accès en https à SRM et DSM comme sécurisé ! Merci encore ! ------------------------------------------------------------------------------------------------------------------------------ @oracle7 Au regard du nouveau paradigme et des évolutions de Synology et DSM je comprends que je devrais maintenant systématiquement importer le Certificat (ce que je faisais déjà pour mon Routeur) sur mon NAS. Du coup est-ce que cela ne vaut il pas le coup de faire sauter la tache, ACME, le script ACME_renew.py fait avec @bruno78 et de faire tous les 3 mois un renouvellement LE wilcard à la main ? Sauf erreur de ma part l'interface de Synology ne permet de le faire que pour un "sous" domaine Synology. Comment faire un renouvellement à la main sur un domaine quelconque "*.ndd.tld" ? Je vois par ailleurs beaucoup de tuto, forum etc. qui parlent de certificat wildcard avec Synology : n'existe-t-il pas une solution stable adaptée pour le commun des mortelles (simple à implémenter) ? Même payante ? Avec des évolutions apportées par DSM 7 (ça pourrait être un déclencheur pour faire la migration chez moi) ? Merci d'avance

Merci. Est-ce "OVH_CK" ou "SAVED_OVH_CK" ? Je vais essayer le reste et je te dis. @oracle7 Je viens de modifier mon fichier acount.conf en ajoutant SAVEC_DID et SAVED_OHV_CK et j'ai toujours le même problème. Dois-je aller modifier cette fameuse variable SYNO_TOTP_SECRET ?Si oui où la trouver ? Dans acme.sh ? Merci d'avance,

Bonjour @oracle7, J'ai une erreur inédite sur l’exécution su script : -- Le nom de domaine (ndd.tld) est errone ou mal configure avec acme.sh. -- Arret du script de renouvellement du certificat Process menant à cette erreur Voici ce que j'ai fait pour essayer de corriger (sous PuTTY en root) : cd /volume1 cd Certs/Acme_install cd acme.sh-master ACME_HOME="/usr/local/share/acme.sh" CERT_HOME="/volume1/Certs" cd $ACME_HOME export OVH_END_POINT=ovh-eu export OVH_AK="votre application key" export OVH_AS="votre application secret" export OVH_CK="votre consumer key" cd $ACME_HOME export CERT_DOMAIN="votre-domaine.tld" export CERT_WDOMAIN="*.votre-domaine.tld" export CERT_DNS="dns_ovh" export SYNO_DID=xxx pwd export SYNO_Scheme="http" export SYNO_Hostname="localhost" export SYNO_Port="5000" export SYNO_Username='DSM_Admin_Username' export SYNO_Password='DSM_Admin_Password!123' export SYNO_Certificate="ACME_Wilcard_LE_*.ndd.tld" export SYNO_Create=1 ./acme.sh --deploy -d "$CERT_DOMAIN" --deploy-hook synology_dsm J'obtiens alors : [Sun Mar 20 12:41:24 CET 2022] Logging into localhost:5000 [Sun Mar 20 12:41:25 CET 2022] Getting certificates in Synology DSM [Sun Mar 20 12:41:26 CET 2022] Generate form POST request [Sun Mar 20 12:41:26 CET 2022] Upload certificate to the Synology DSM [Sun Mar 20 12:42:29 CET 2022] http services were restarted [Sun Mar 20 12:42:30 CET 2022] Success C'est encourageant et je poursuis donc avec : cd /usr/local/share/acme.sh ./acme.sh --force --upgrade --nocron --home /usr/local/share/acme.sh J'obtiens alors : [Sun Mar 20 12:50:37 CET 2022] Installing from online archive. [Sun Mar 20 12:50:37 CET 2022] Downloading https://github.com/acmesh-official/acme.sh/archive/master.tar.gz [Sun Mar 20 12:50:38 CET 2022] Extracting master.tar.gz [Sun Mar 20 12:50:38 CET 2022] It is recommended to install socat first. [Sun Mar 20 12:50:38 CET 2022] We use socat for standalone server if you use standalone mode. [Sun Mar 20 12:50:38 CET 2022] If you don't use standalone mode, just ignore this warning. [Sun Mar 20 12:50:38 CET 2022] Installing to /usr/local/share/acme.sh [Sun Mar 20 12:50:38 CET 2022] Installed to /usr/local/share/acme.sh/acme.sh [Sun Mar 20 12:50:38 CET 2022] Good, bash is found, so change the shebang to use bash as preferred. [Sun Mar 20 12:50:41 CET 2022] OK [Sun Mar 20 12:50:41 CET 2022] Install success! [Sun Mar 20 12:50:41 CET 2022] Upgrade success! C'est de nouveau encourageant. Je suis dans volume1/Scripts et j’exécute la commande suivante : python acme_renew.py -t ndd.tld J'obtiens alors : -- Le nom de domaine (ndd.tld) est errone ou mal configure avec acme.sh. -- Arret du script de renouvellement du certificat État de m configuration Je suis encore sous DMS 6. Mon fichier account.conf dans usr/local/share/acme.sh est le suivant : LOG_FILE='/volume1/Certs/Acme_renew/acmelog' #LOG_LEVEL=1 AUTO_UPGRADE='1' #NO_TIMESTAMP=1 CERT_HOME='/volume1/Certs' ACCOUNT_EMAIL='email@orange.fr' UPGRADE_HASH='XXX' DEFAULT_ACME_SERVER='https://acme-v02.api.letsencrypt.org/directory' SAVED_OVH_AK='XXX' SAVED_OVH_AS='XXX' USER_PATH=':/sbin:/bin:/usr/sbin:/usr/bin:/usr/syno/sbin:/usr/syno/bin:/usr/local/sbin:/usr/local/bin' As tu une idée de ce qui cloche ? Merci d'avance,

Ok mais je ne comprends pas pourquoi paramétrer ces éléments puisque de toute façon l'accès se faite déjà via https://homeassistant.ndd.tld depuis le WAN et le LAN ? Ok mais dans le cas où je préciserais https://@IPexterne:443 comment le flux serait amené jusqu'au Home Assistant une fois arrivé à ma passerelle WAN<->LAN (mon routeur chez moi) ? Oui ça c'est bien clair pour moi mais tu semblais indiqué que le passage par le Reverse proxy permettait de faire la certification puisque celui-ci est hebergé sur mon NAS qui possède un certificat valide. Je me disais donc qu'un passage par le Reverse Proxy pour aller sur le Routeur pourrait permettre de s'affranchir du certificat sur celui-ci. Ta réponse est claire : ce n'est pas possible (même si je n'ai pas le niveau pour comprendre pourquoi). Merci encore,

Non pas encore. Mais tu m'as convaincu la dernière fois. Je vais donc le faire (i) sur le DNS de mon Registrar et (ii) sur mon DNS local. Pas d'accès externe configuré et pas de DynDNS sur cette machine donc a priori pas joignable directement depuis l’extérieur sans passer par mon routeur puis mon Reverse Proxy ? En revanche je ne lui ai pas encore formellement banni l'accès à internet depuis mon Routeur (ce que je vais surement faire d'ailleurs). J'avais sur mon Routeur une règle de transfert de port que j'ai désactivé suite à l'activation de mon Reverse Proxy. => La non existence d'une règle d'accès sur le firewall de mon routeur + la non existence d'un paramétrage URL externe est elle suffisante pour indiquer "qu'il n'est pas exposé à internet" ou faut il aussi ajouter un bannissement depuis le routeur pour formellement pouvoir le dire ? Juste pour ma culture, d'un point de vue technique que ce passe t il quand on configure une URL externe ? C'est une sorte de dynDNS ? Ok, dans ce cas cela pourrais-je créer une entrée dans mon Reverse Proxy pour pointer vers mon routeur qui me permettrait d'éviter de copier à la main tous les 3 mois mon certificat depuis mon NAS (cf. ton super tuto) vers mon Routeur ? De mon côté aucune règle d'accès configuré (cf plus haut). Pour moi cela est redondant avec : En LAN : (i) l'utilisation du DNS local qui pointe vers le NAS sur lequel (ii) le Reverse proxy fait pointer sur le bon port de Home Assistant En WAN : (i) l'utilisation de l'entrée CNAME du DNS de mon registrar qui fait pointer vers mon ndd.tld qui (ii) pointe ensuite via le Dyn DNS du registrar vers mon Routeur sur lequel (iii) mon firewall route le vers mon NAS sur lequel (iv) le Reverse proxy fait pointer sur le bon port de Home Assistant. Est-ce bien cela ? SI oui, pourquoi as tu conservé ce paramétrage ? Merci d'avance,

Bonjour @oracle7 et @GrOoT64, Juste pour informer que c'est bon, je parviens à atteindre home.ndd.tld depuis le WAN et le LAN. Voici ce que j'ai fait : J'ai effacé les entrées créée sur le DNS local J'ai effacé l'entrée sur le Reverse Proxy de mon NAS Sur le DNS local (héberge sur mon routeur), j'ai crée une entrée home.ndd.tld A 86400 @IP NAS Sur le Reverse Proxy (hébergé sur mon NAS), j'ai créé une entrée https://home.ndd.tld -> http://IP_Home_Assistant:8123 J'ai fait un ipconfig/flushdns sur l'invite de commande de mon client Et là miracle ça marche ! J'ai une dernière question : mon certifcat wildcard joue son rôle, mon accès apparait donc comme sécurisé. je pensais justement qu'un certificat était lié à un nom de domaine et une machine et que je devrais l'installer sur mon Home Assistant (ou mon Raspberry Pi 4B) pour avoir un accès sécurisé ! Comment expliquer ce comportement ?

Pas certain de comprendre. A date mon entrée du DNS local est : home.ndd.tld A 86400 192.168.X.X J'ai essayé d'utiliser : home.ndd.tld CNAME 86400 ns.ndd.tld et home.ndd.tld A 86400 IP Routeur mais ça n'aide pas et ça casse même l'accès local en http. Je viens de créer une entrée home.ndd.tld CNAME 86400 ndd.tld et même ainsi le port reste obligatoire ... Idem

Tu as raison, je devrais le faire. J'ai gardé ma configuration historique pour me forcer à repasser dessus de temps en temps et virer ce qui est inutile mais en ligne avec toi : je vais le faire. En revanche une idée pour mon problème qui m'oblige à utiliser une adresse locale en http et à préciser le port ? Le fait de devoir préciser le port fait penser à un défaut sur le Reverse Proxy mais le fait de ne pas avoir de redirection de port 8123 sur le Routeur et un accès valide depuis le WAn montre pourtant que le Reverse Proxy tourne ... je ne comprends vraiment pas. Deux pistes auxquelles je pense : Pour une raisin que je ne maitrise pas je dois utiliser les web socket sur l'entrée du Reverse Proxy qui correspond à Home Assistant. Le comportement exotique qui semble attribuer une IP au Raspberry Pi monté "vide" (sans home assistant, uniquement Raspbian) et une IP différente quand le Raspberry Pi est monté avec Home Assistant. Si quelqu'un à une idée ...

Merci @oracle7 non je n'ai pas cette entrée d'où mon ajout manuel non je n'ai pas cette entrée d'où mon ajout manuel en ligne : je l'ai supprimée décidément j'écris n'importe quoi, pardon, mon entrée reverse proxy est bien https://home.ndd.tld:443 -> http://192.168.X.X:8123 (je passe de nouveau un edit). Du coup ma config est bonne non ?

Merci à vous deux @GrOoT64 et @oracle7 Ok, du coup a priori je suis bon sur ma configuration : J'ai ma redirection CNAM registrar : home.ndd.tld -> IP WAN de mon routeur J'ai mon entrée de type A sur le DNS local (hébergé sur mon routeur) : home.ndd.tld -> IP LAN de Home Assistant J'ai une redirection de ports sur mon routeur : 8123 IP WAN -> 8123 192.168.X.X (IP LAN de Home Assistant) J'ai mon entrée sur mon Reverse Proxy (hébergé sur mon NAS) : https://home.ndd.tld 443 -> http://192.168.X.X:8123 (http://home.ndd.tld:8123) Ma configuration 4 est donc superflue et je peux la supprimer (grâce au travail du reverse proxy) : je viens de supprimer cette redirection et mon accès WAN en https est préservé ce qui semble démontrer que le Reverse Proxy fonctionne bien. En revanche je ne comprends toujours pas pourquoi en LAN je dois passer par du http et préciser le port ! Une idée ? Ok peut être un truc exotique chez moi mais in fine comme toi je pense utiliser que très rarement le SSH vers le Raspberry Pi. Cela vient peut être du fait que mon raspberry est en RJ45 mais que je l'ai également configuré pour pouvoir se connecter au wifi ? Mes capteurs EnOcean sont un héritage d'une solution grand public dont je ne suis pas satisfait (d'où ma démarche) mais je pense que les capteurs en eux même doivent faire le job. Concernant la portée et le maillage j'ai cru comprendre que justement Z-wave était le plus robuste. Je vais lire ton article. Tu peux aussi regarder cette vidéo.

Merci pour vos réponses rapides @GrOoT64 et @oracle7, J'étais visiblement fatigué quand j'ai rédigé mon poste car j'ai écris des bêtises /imprécisions : tu as raison c'est bien ce que j'ai sur mon reverse proxy (je passe un edit sur mon post original pour corriger) raison encore c'est bien ce que j'ai (je passe un edit sur mon post original pour corriger) pas certain de comprendre cette entrée : Localhost c'est pour la même machine non (donc mon NAS dans mon cas) ? Pourquoi un reverse proxy HTTPS vers HTTP sur la même machine ? Dans tous les cas j'imagine que chez moi le localhost doit être remplacé par l'IP d'Home Assistant ? j'ai également ces deux redirections sur mon routeur ok donc : X.ndd.tld. -> IP WAN : via une entrée CNAME du registrar IP WAN -> IP LAN Routeur (qui héberge le DNS local) : via le Routeur en lui-même ? IP LAN Routeur -> IP LAN NAS : via DNS local (hébergé sur le Routeur) IP LAN NAs -> IP LAN + port service : via Reverse Proxy (hebergé sur le NAS) C'est bien cela ? Du coup je ne comprends toujours pas pourquoi pour ce service spécifique je dois sur mon LAN (i) utiliser du http et (ii) préciser le port alors que je reste toujours (LAN/VPN/WAN) en https sans précision de port pour tous mes autres services ! @GrOoT64 et @oracle7 Avez-vous une explication là dessus ? Super remarque : justement je n'ai trouvé aucun argument fort en faveur ou en défaveur d'une des deux solutions (Jeedom vs. Home Assistant) en dehors du fait que (i) Home Assistant semblait intégrer plus rapidement de nouveaux équipements et (ii) l'UX me semblait assez sympa. La communautés semble également bien présente en français ou en anglais. Mais honnêtement je suis encore en phase de test et pas impossible que j'essaie ensuite Jeedom. Je suis preneur d'arguments factuels pour l'arbitrage entre les deux solutions si tu en as ? Pour info je boot bien mon Home Assistant directement depuis une clé USB SSD branchée sur mon Raspberry Pi 4B 4Go qui est branché au LAN en RJ45. A noter d'ailleurs que j'observe sur mon routeur une IP LAN différente pour mon Raspberry Pi et Home Assistant ! Quand Home Assistant est booté le raspberry semble alors non connecté au réseau ... Comme si sur un PC je dissociais le PC vs. Windows qui prendrait le dessus sur le hardware ... D'ailleurs quand je fais du SSH je ne peux atteindre le Raspebrry Pi uniquement quand Home Assistant n'est pas booté. As tu le même comportement ? Est-ce un sujet de machine virtuelle ou similaire ? PS pour les protocoles je pense a priori partir sur du Z-Wave et EnOcean. Merci encore,

Bonjour à tous, Je vous prie par avance de m'excuser si je poste au mauvais endroit, dans ce cas n’hésitez pas à me dire où poster. Ma configuration J'ai un NAS Synology derrière un Routeur Synology en DMZ d'une Livebox. J'avais historiquement suivi ce tuto et celui sur le DNS et grâce à eux et à un DynDNS j'accède aujourd'hui sans problème à mes différents services via des "sous domaines" (ex : files.ndd.tld) depuis une IP LAN/VPN/WAN. Je souhaite maintenant me lancer dans la domotique et je viens donc d'installer sur mon LAN un Raspberry Pi 4B 4Go sur lequel tourne Home Assistant dont l'adresse IP est 192.168.XX.XX et le port 8123 - pour information je me suis posé la question de l'arbitrage entre Raspberry et NAS et j'ai opté pour le premier pour (i) avoir un laboratoire sur lequel je peux "faire des bêtises" et (ii) car j'ai souvent lu que l'intégration Home Assistant sur un NAS Synology était parfois compliquée à cause de problèmes de compatibilité. Mon paramétrage Home Assistant Au même titre que mes différents services sur mon NAS j'ai donc : Fixé l'adresse IP locale de mon Raspberry via le DHCP de mon routeur Créé sur la résolution locale de mon DNS (hébergé sur mon routeur) une entrée du type : home.ndd.tld A 86400 192.168.XX.XX. Sauf erreur de ma part cela permet, uniquement à mes équipement locaux (LAN/VPN), de pointer sur mon Raspberry sans se souvenir de l'adresse IP : est-ce bien cela ? Créé un redirection depuis mon registar : home.ndd.tld CNAME 0 ndd.tld. Sauf erreur de ma part cela permet, aux équipement exterieurs (WAN), de pointer sur mon Raspberry sans se souvenir de l'adresse IP extérieur de mon routeur : est-ce bien cela ? Créé une entrée dans le reverse proxy : home.ndd.tld HTTPS 443 vers HTTP 8123 192.168.XX.XX. Créé sur mon routeur une règle de redirection de ports 8123 WAN vers 8123 IP 192.168.XX.XX. A noter que je n'ai pas de problème de certificat car j'ai suivi le tuto de @oracle7 sur les certificats wildcard. Mes questions : J'ai peur de m'enméler un peu les pinceaux entre (i) redirection Registar, (ii) DNS local et (iii) reverse proxy : le (i) permet de pointer vers mon LAN avec un nom de domaine (et non une IP externe qui change régulièrement), le (ii) permet de pointer via un domaine vers un appareil de mon LAN (et non une IP locale) et le (iii) permet de pointer via un domaine vers une application avec un port dédié et non une IP et un port : c'est bien cela ? Avec cette configuration j'arrive à bien accéder à mon service Home Assistant depuis le WAN en https via https://home.ndd.tld en revanche impossible depuis le LAN Je suis obligé de passer par du http (ce qui n'est pas un problème en LAN) mais aussi de devoir préciser le port via http://home.ndd.tld:8123. Je ne comprends pas pourquoi cette différence ? Pouvez-vous svp m'aider là dessus ? A noter que comme indiqué ici j'ai activé les Web Sockets (sans comprendre pourquoi) sur le reverse proxy de ce service et validé l'IP de mon NAS en tant que proxy de confiance dans la configuration de Home Assistant. Merci d'avance pour votre aide,

ok si mais je pensais que le process overwrittait cela ok ok Je l'ai fait justement Je l'ai bien Est ce un problème d'avoir un certificat ZéroSSL ? ok Merci encore @oracle7

Merci beaucoup @oracle7 pour ta pédagogie. J'ai suivi tes instructions de désinstallation de acme puis j'ai redescendu le tuto pas à pas. Voici en gros ce que j'ai fait ce que j'ai fait cd /volume1 cd Certs/Acme_install cd acme.sh-master ACME_HOME="/usr/local/share/acme.sh" CERT_HOME="/volume1/Certs" cd $ACME_HOME export OVH_END_POINT=ovh-eu export OVH_AK="votre application key" export OVH_AS="votre application secret" export OVH_CK="votre consumer key" cd $ACME_HOME export CERT_DOMAIN="votre-domaine.tld" export CERT_WDOMAIN="*.votre-domaine.tld" export CERT_DNS="dns_ovh" export SYNO_DID=xxx pwd export SYNO_Scheme="http" export SYNO_Hostname="localhost" export SYNO_Port="5000" export SYNO_Username='DSM_Admin_Username' export SYNO_Password='DSM_Admin_Password!123' export SYNO_Certificate="ACME_Wilcard_LE_*.ndd.tld" export SYNO_Create=1 ./acme.sh --deploy -d "$CERT_DOMAIN" --deploy-hook synology_dsm PS j'ai essayé avec export SYNO_Scheme="https" export SYNO_Hostname="localhost" export SYNO_Port="5001" Mais j'avais un problème que j'aavis également eu la première fois de mémoire, je suis donc parti sur http /5000 Premiers éléments à noter J'ai obtenu un log SSH avec à la fin : [Fri Dec 17 20:06:14 CET 2021] Logging into localhost:5000 [Fri Dec 17 20:06:15 CET 2021] Getting certificates in Synology DSM [Fri Dec 17 20:06:15 CET 2021] Generate form POST request [Fri Dec 17 20:06:15 CET 2021] Upload certificate to the Synology DSM [Fri Dec 17 20:06:16 CET 2021] http services were NOT restarted [Fri Dec 17 20:06:16 CET 2021] Success Bon signe donc. Dans l'interface DSM je voyais bien un certificat ACME mais la date de préremption était inférieure au certificat créé à la main il y quelques jours le certificat n'apparait par comme certificat par défaut mon navigateur indiquait toujours mon ancien certificat après (i) configuration du certificat ACME par défaut, (ii) suppression de mon ancien certificat dans le DSM et (iii) déconnexion/reconnexion au DSM Pour pousser l'exercice jusqu'au bout j'ai forcé un renouvellement cd /volume1 cd /volume1/Scripts /volume1/Scripts$ python acme_renew.py -f ndd.tld J'ai alors obtenu un log bien plus long que d'habitude dans l'exécution avec de nombreuses itérations de code du type GET / Retrying GET (cf. exemple ci-dessous). GET [Fri Dec 17 20:29:55 CET 2021] url='https://eu.api.ovh.com/1.0/auth/time' [Fri Dec 17 20:29:55 CET 2021] timeout=30 [Fri Dec 17 20:29:55 CET 2021] displayError='1' [Fri Dec 17 20:29:55 CET 2021] _CURL='curl --silent --dump-header /usr/local/share/acme.sh//http.header -L -g --connect-timeout 30' [Fri Dec 17 20:29:55 CET 2021] ret='0' [Fri Dec 17 20:29:55 CET 2021] _hcode='0' [Fri Dec 17 20:29:55 CET 2021] _ovh_p='[hidden](please add '--output-insecure' to see this value)' Retrying GET In fine j'ai eu en fin de log [Fri Dec 17 20:30:23 CET 2021] Your cert is in: /volume1/Certs/ndd.tld/ndd.tld.cer [Fri Dec 17 20:30:23 CET 2021] Your cert key is in: /volume1/Certs/ndd.tld/ndd.tld.key [Fri Dec 17 20:30:23 CET 2021] The intermediate CA cert is in: /volume1/Certs/ndd.tld/ca.cer [Fri Dec 17 20:30:23 CET 2021] And the full chain certs is there: /volume1/Certs/ndd.tld/fullchain.cer ... -- Renouvellement certificat via acme.sh -- commande acme.sh : bash /usr/local/share/acme.sh/acme.sh --cron --force --debug --home /usr/local/share/acme.sh/ -- Nouveau certificat par DEFAULT : TIucVw --- Le certificat n'a pas ete renouvele. --- => Consulter le log : /volume1/Certs/Acme_renew/acmelog Situation actuelle J'ai ensuite récupéré le certificat pour l'importer sur mon routeur. J'ai maintenant le même certificat sur mon NAS et mon routeur et mon navigateur indique qu'ils sont valides du 1712/2021 jusqu'au 18/03/2022 et qu'ils sont délivrés par ZeroSSL. Enfin mes certificats sont bien maintennat dans Volume1/certs/ndd.tld et tous les fichiers sont en date du 17/12/2021 sauf le clé de RSA mais je comprends que c'est normal ? A noter également que mon certificat intermédiaire n'a plus la première ligne vide à faire sauter et qu'il semble concaténer deux certificats avec un format du type : -----BEGIN CERTIFICATE----- *** -----END CERTIFICATE----- -----BEGIN CERTIFICATE----- *** -----END CERTIFICATE----- Bref ça semble fonctionner mais sans vraiment comprendre ce qui s'est passé ... Dernière question Enfin @oracle7 je comprends que suite aux récentes évolutions du Shel script ACME je peux complètement supprimer la tache planifiée ? Je n'aurai juste donc qu'a importer tous les 3 mois le certificat (automatiquement renouvelé) de mon NAS vers mon routeur. Quid du DID dans tous ça ? Merci d'avance

Merci @oracle7 et @Jeff777, Pour faire les choses correctement cette fois-ci comment dois-je m'y prendre ? Désinstaller acme.sh : si oui comment faire ? Supprimer les fichiers : si oui lesquels ?§ Reprende le tuto sur les parties 2, 4 et 5 ? Ai-je oublié quelque chose ?

@oracle7 merci pour ton aide. Je n'avais jamais eu à redéclarer / exporter ces variables, j'ai donc appliqué tes conseils. J'ai tappé /volume1$ cd /volume1 /volume1$ cd Certs/Acme_install /volume1/Certs/Acme_install$ ACME_HOME="/usr/local/share/acme.sh" /volume1/Certs/Acme_install$ CERT_HOME="/volume1/Certs" /volume1/Certs/Acme_install$ cd $CERT_HOME /volume1/Certs$ export OVH_END_POINT=ovh-eu /volume1/Certs$ export OVH_AK="***" /volume1/Certs$ export OVH_AS="***" /volume1/Certs$ export OVH_CK="***" /volume1/Certs$ cd $ACME_HOME /usr/local/share/acme.sh$ export CERT_DOMAIN="ndd.tld" /usr/local/share/acme.sh$ export CERT_WDOMAIN="*.ndd.tld" /usr/local/share/acme.sh$ export CERT_DNS="dns_ovh" /usr/local/share/acme.sh$ ./acme.sh --issue --keylength 4096 -d "$CERT_DOMAIN" -d "$CERT_WDOMAIN" --dns "$CERT_DNS" [Tue Dec 14 22:33:21 CET 2021] Domains not changed. [Tue Dec 14 22:33:21 CET 2021] Skip, Next renewal time is: Sat Feb 12 21:15:08 UTC 2022 [Tue Dec 14 22:33:21 CET 2021] Add '--force' to force to renew. /usr/local/share/acme.sh$ ./acme.sh --issue --keylength 4096 -d "$CERT_DOMAIN" -d "$CERT_WDOMAIN" --dns "$CERT_DNS" --force Et j'obtiens [Tue Dec 14 22:34:15 CET 2021] Using CA: https://acme-v02.api.letsencrypt.org/directory [Tue Dec 14 22:34:16 CET 2021] Multi domain='DNS:ndd.tld,DNS:*.ndd.tld' [Tue Dec 14 22:34:16 CET 2021] Getting domain auth token for each domain [Tue Dec 14 22:34:19 CET 2021] Getting webroot for domain='ndd.tld' [Tue Dec 14 22:34:19 CET 2021] Getting webroot for domain='*.ndd.tld' [Tue Dec 14 22:34:19 CET 2021] ndd.tld is already verified, skip dns-01. [Tue Dec 14 22:34:19 CET 2021] *.ndd.tld is already verified, skip dns-01. [Tue Dec 14 22:34:19 CET 2021] Verify finished, start to sign. [Tue Dec 14 22:34:19 CET 2021] Lets finalize the order. [Tue Dec 14 22:34:19 CET 2021] Le_OrderFinalize='https://acme-v02.api.letsencrypt.org/acme/finalize/320043130/47314989630' [Tue Dec 14 22:34:20 CET 2021] Downloading cert. [Tue Dec 14 22:34:20 CET 2021] Le_LinkCert='https://acme-v02.api.letsencrypt.org/acme/cert/04dd41cf3ea49530f032b26a254546ac720f' [Tue Dec 14 22:34:21 CET 2021] Cert success. -----BEGIN CERTIFICATE----- *** -----END CERTIFICATE----- [Tue Dec 14 22:34:21 CET 2021] Your cert is in: /root/.acme.sh/ndd.tld/ndd.tld.cer [Tue Dec 14 22:34:21 CET 2021] Your cert key is in: /root/.acme.sh/ndd.tld/ndd.tld.key [Tue Dec 14 22:34:21 CET 2021] The intermediate CA cert is in: /root/.acme.sh/ndd.tld/ca.cer [Tue Dec 14 22:34:21 CET 2021] And the full chain certs is there: /root/.acme.sh/ndd.tld/fullchain.cer Bref ça à l'air de tourner en revanche je ne comprends pas pourquoi les certificats s'enregistrent dans /root/.acme.sh et non pas dans volume1/Certs ? Car du coup dans l'interface DSM mon certificat ne semble pas remonter et je vois toujours l'ancien. Comment faire ? Merci d'avance,

En passant par PuTTY même les logs semblent bizarres [Mon Dec 13 23:35:43 CET 2021] ===Starting cron=== [Mon Dec 13 23:35:43 CET 2021] Using config home:/usr/local/share/acme.sh/ [Mon Dec 13 23:35:43 CET 2021] ACME_DIRECTORY='https://acme-v02.api.letsencrypt. 'rg/directory [Mon Dec 13 23:35:43 CET 2021] _stopRenewOnError [Mon Dec 13 23:35:43 CET 2021] _set_level='2' /*.*/'ec 13 23:35:43 CET 2021] di='/volume1/Certs /*.*/Dec 13 23:35:43 CET 2021] Not a directory, skip: /volume1/Certs [Mon Dec 13 23:35:43 CET 2021] _error_level='3' [Mon Dec 13 23:35:43 CET 2021] _set_level='2' [Mon Dec 13 23:35:43 CET 2021] ===End cron===

@oracle7, Je viens d'essayer de recréer un certificat avec le code tappé sous WinSCP /root$ ACME_HOME="/usr/local/share/acme.sh" /root$ cd $ACME_HOME /usr/local/share/acme.sh$ export CERT_DOMAIN="ndd.tld" /usr/local/share/acme.sh$ export CERT_WDOMAIN="*.ndd.tld" /usr/local/share/acme.sh$ export CERT_DNS="dns_ovh" /usr/local/share/acme.sh$ ./acme.sh --issue --keylength 4096 -d "$CERT_DOMAIN" -d "$CERT_WDOMAIN" --dns "$CERT_DNS" J'obtiens ensuite le log [Mon Dec 13 23:08:52 CET 2021] Using CA: https://acme-v02.api.letsencrypt.org/directory [Mon Dec 13 23:08:53 CET 2021] Create account key ok. [Mon Dec 13 23:08:53 CET 2021] Registering account: https://acme-v02.api.letsencrypt.org/directory [Mon Dec 13 23:08:54 CET 2021] Registered [Mon Dec 13 23:08:54 CET 2021] ACCOUNT_THUMBPRINT='***' [Mon Dec 13 23:08:54 CET 2021] Creating domain key [Mon Dec 13 23:08:57 CET 2021] The domain key is here: /root/.acme.sh/ndd.tld/ndd.tld [Mon Dec 13 23:08:57 CET 2021] Multi domain='DNS:ndd.tld,DNS:*.ndd.tld' [Mon Dec 13 23:08:57 CET 2021] Getting domain auth token for each domain [Mon Dec 13 23:08:59 CET 2021] Getting webroot for domain='ndd.tld' [Mon Dec 13 23:09:00 CET 2021] You don't specify OVH application key and application secret yet. [Mon Dec 13 23:09:00 CET 2021] Please create you key and try again. [Mon Dec 13 23:09:00 CET 2021] Getting webroot for domain='*.ndd.tld' [Mon Dec 13 23:09:00 CET 2021] Adding txt value: *** for domain: _acme-challenge.ndd.tld [Mon Dec 13 23:09:00 CET 2021] Error add txt for domain:_acme-challenge.ndd.tld [Mon Dec 13 23:09:00 CET 2021] Please add '--debug' or '--log' to check more details. [Mon Dec 13 23:09:00 CET 2021] See: https://github.com/acmesh-official/acme.sh/wiki/How-to-debug-acme.sh Vois tu le problème ?

En fait ma première manip me sert à faire un "reset" pour partir d'une base propre avec des certificats qui tournent. Ensuite je force le renouvellement (pour anticiper ce qui se passera dans 3 mois) et pour vérifier que le process tourne correctement. In fine indépendamment des logs le certificat reste inchangé sur l'interface DSM ... Non pas encore passé sur DSM 7.0 : preneur d'ailleurs d'un lien pour les bonnes pratiques / pièges à éviter. Je me mets dans WinSCP en l'utilisant comme explorateur pour directement ouvrir le fichier que je vois bien dans le répertoire : c'est lors de l'ouverture que j'ai le message d'erreur. Comme ci le fichier était une coquille vide ... Oui, aucune ambiguïté la dessus : je voulais voir si j'avais un message d'erreur "exotique" ou si cela se comportait "comme avant". Cordialement,

@oracle7, Je viens de taper ACME_HOME="/usr/local/share/acme.sh" cd $ACME_HOME export CERT_DOMAIN="ndd.tld" export CERT_WDOMAIN="*.ndd.tld" export CERT_DNS="dns_ovh" ./acme.sh --issue --keylength 4096 -d "$CERT_DOMAIN" -d "$CERT_WDOMAIN" --dns "$CERT_DNS" --set-default-ca --server letsencrypt J'obtiens alors [Sun Dec 12 23:14:16 CET 2021] Changed default CA to: https://acme-v02.api.letsencrypt.org/directory Je tape ensuite cd / volume1/Scripts python acme_renew.py -f ndd.tld J'obtiens un log qui termine par --- Le certificat n'a pas ete renouvele. --- => Consulter le log : /volume1/Certs/Acme_renew/acmelog Puis quand je vais ouvrir le fichier acmelog un message d'erreur m'indique que le fichier acmelog ne peut par être créé et il est précisé : Erreur système. Code : 123. La syntaxe du nom de fichier, de répertoire ou de volume est incorrecte Que puis je faire ? A noter que j'ai essayé de renouveler le certificat en passant par le DSM mais en demandant un certificat pour "*.ndd.tld" un message d'erreur m'indique que les certificats génériques ne fonctionnent que pour les DDNS Synology. Preneur de tes lumières, je sèche ... PS : évidemment j'ai bien remplacé les "ndd.tld" par mon propre domaine à chaque fois.