oracle7

@Stigmate101 Là je crains que tu ne pousses un peu trop les choses. Rajouter un 3eme NAS sur ce pauvre Eaton, en cas de panne de courant, tu risques fortement de ne pas avoir assez de capacité pour maintenir l'alimentation, le temps que les deux premiers s'arrêtent en toute sécurité car je suppose que tu n'as sûrement pas que ces deux NAS branchés sur l'onduleur. Mettre en service un second onduleur serait plus sage. Certes, il est vrai que c'est un budget mais ne dit -on pas que la sécurité à un prix ? Mais c'est toi qui vois ... Cordialement oracle7😉

@maxou56 Bon bah, rien à faire d'autre que de patienter pour le retour à la normale ... 😟 Cordialement oracle7😉

Bonjour, En me baladant sur les paramètres de mon routeur RT2600ac j'ai trouvé cela : Jusqu'à présent c'était toujours "vert", maintenant cela bascule au rouge après 1 seconde dès que j'accède à l'onglet. Quelqu'un a-t-il constaté le même comportement ? Cordialement oracle7😉

@Jeff777 Je suis d'accord mais comment fais-tu cela ? Car je n'ai rien trouvé au niveau de la LIveBox ni au niveau du RT2600ac. En plus, comment faire pour qu'ils s'éteignent les derniers (juste avant le NAS principal)? On en revient à ma question sur l'ordre des @IP. Cordialement oracle7😉

@alan.dub En fait, j'ai une box, un routeur, 2 NAS et une batterie de 4 RPI et sans compter 2 switchs derrière un seul onduleur et je souhaite que tout ce petit monde s'arrête en toute sécurité sur une panne de courant. D'où mes questions précédentes. Cordialement oracle7😉

@Jeff777 Questions "bêtes" : Y-a-t-il un ordre particulier à respecter ou bien on peut renseigner en "vrac" les @IP des "Périphériques Diskstation autorisés" ? Comment fait-on, si d'aventure on plus de 5 périphériques dont il faut gérer l'arrêt en toute sécurité, vu que la liste est limitée à 5 ? Cordialement oracle7😉

@Jeff777 Effectivement, à moins de développer ta propre API à l'image de celle d'OVH (mais là il y a du boulot !) je ne vois pas de solution dans ton cas. Désolé de t'avoir donné de faux espoirs avec ma méthode. Cordialement oracle7😉

@bruno78 Bonjour, Oui, cela me paraît logique comme comportement. C'est étonnant, chez moi il a bien pris en compte 3 mois : créé le 25/5/20020 --> validité 22/08/2020. Effectivement, j'ai constaté cela lors de la programmation de la tâche : j'ai donc choisi par défaut de sélectionner "tous les 3 mois" puisqu'il est impossible d'affiner.. Cela dit, je me demande si tu n'aurais pas tout compte fait raison, en proposant une tâche planifiée mensuelle. Malheureusement, pour vérifier cela il nous faut attendre chaque échéance pour constater le comportement effectif. Je n'ai pas d'autre solution en magasin pour l'instant ... A moins que tu ais une idée ? @Jeff777 Peut-être que dans ton cas la solution serait d'effectuer la création du certificat en mode "DNS manuel". Dans ce cas cela t'impose d'aller en plus créer à la main dans ta Zone DNS d'OVH les enregistrements "TXT" nécessaires, avec les valeurs reçues dans le message de retour lors de la création. Je t'invite à regarder ce post où j'avais décrit la méthode par DNS Manuel lors de mes premiers errements sur le sujet. Certes, il te faudra adapter, mais l'essentiel y est. Au final, c'est peut-être bien un mixte de tout cela qui te conviendra personnellement. Enfin je te le souhaite... J'attire ton attention sur le fait que la variable d'environnement "CERT_DNS" correspond au script ".sh" que ACME va employer selon le fournisseur de domaine. Ce script est situé dans "/usr/local/share/acme.sh/dnsapi". Donc ta modification ne me semble pas correcte. A voir ... Cordialement oracle7😉

@Mickael Frigout La LiveBox étant très capricieuse, peut-être qu'un p'tit reboot lui serait salvateur ? Cà coûte rien d'essayer. Cordialement oracle7😉

@Mickael Frigout Bonjour, Pour les nouveaux membres, il est de bon ton de passer par la case présentation dans le rubrique adéquat, certains ici y sont sensibles. Rassures-toi il n'est pas trop tard pour bien faire 😉 Je n'ai jamais personnellement rencontré ton problème de renvoi vers un certificat LiveBox. C'est assez étonnant. Toujours est-il, je te suggère de regarder ici pour créer un certificat Let's Encrypt sur un nom de domaine OVH. Si cela peut t'aider. Cordialement oracle7😉

@Jeff777 Je ne connais malheureusement pas ton type de configuration, du coup je crains de ne pouvoir t'aider efficacement. Cela dit, en y réfléchissant bien tu devrais pouvoir adapter mon Tuto et t'en sortir. Bon courage et n'hésites pas me questionner. Cordialement oracle7😉

@Outimeme Regardes, ici cela devrait t'intéresser. Et là plus de soucis d'ouverture des ports 80 et 443 pour un certificat. Cordialement oracle7😉

@bruno78 Merci de ton retour, c'est super ! Du coup, grâce à toi (si je puis dire), j'ai modifié le Tuto en ajoutant un avertissement à destination des utilisateurs Mac au §2. Cordialement oracle7😉

@Jeff777 Bonjour, En principe, l'ouverture de ton domaine "ndd.tld" chez OVH a dû créer automatiquement dans ta Zone DNS, 2 enregistrements "NS" vers les serveurs d'OVH : dns112.ovh.net et ns112.ovh.net. Donc ta Zone DNS chez OVH n'est normalement pas "vide" même si tu ne l'utilises pas. Du coup, je penses que cela devrait le faire si tu respectes les pré-requis du §1 d'une part et dans ton cas personnel, il me semble qu'il te faudra d'autre part ajouter à minima dans ta Zone DNS chez OVH, un enregistrement CNAME avec "*.ndd.tld." pointant vers "ndd.tld.". A essayer donc ... Cordialement oracle7😉

@bruno78 Bonjour, Désolé pour toi, je crois que tu es le premier à "essuyer les plâtres" 😩 Si tu as utilisé 'sudo -i' c'est que je devines que tu es sur Mac, effectivement c'est la méthode à utiliser pour passer sous 'root' dans cet environnement. En cela, tu as raison. Comme je ne travailles pas sous Mac, je n'ai pu tester la méthode que j'ai décrite dans cet environnement. J'ai fourni ce moyen croyant que ce serait identique puisque en principe les commandes Shell s'appliquent sur le noyau du NAS. Puisque que cela ne marche pas ('sudo -i'), je t'invite à suivre le Tuto de @unPixel sur les "Accès SSH et ROOT via DSM6" et ainsi te configurer un accès par le "vrai" root. Là cela devrait le faire ... Dis-moi le résultat en retour, si cela passe alors je modifierai en conséquence le tutoriel pour avertir les utilisateurs Mac du problème. Pour ce qui est de l'erreur liée à ta "consumer key" : vérifie que tu l'as bien copiée dans la variable OVK_CK lors de son export. Je veux dire pas là, vérifies que tu n'as pas introduit de caractères parasites lors du C/C. Souvent c'est un blanc ou un fin de ligne invisible qui perturbe, du coup la chaine est différente et d'où l'erreur ... Cordialement oracle7😉

Bonjour, EDIT 20/06/2021 §4 : Complément à la commande de création du certificat suite aux récentes évolutions du Shell script ACME. §6 : Ajout lié au renouvellement. Pour faciliter la compréhension, le texte lié à cette édition est repéré en bleu. EDIT 10/01/2021 § 5.1 : Ajout d’une astuce évitant un problème de renouvellement lié au cookie DID de la double authentification. EDIT 21/08/2020 § 6 : Évolution du script Python pour être aussi compatible de la dernière et actuelle version du langage Python : version 3.x.x § 10 : Mise à jour du texte d’aide associé à l’option « -h ». Suppression des fichiers de trace « cleanlog » et « cleanlogerr » qui n’apportaient rien de plus à la trace existante. Remaniement du fichier de trace pour que soit généré un nouveau fichier à chaque exécution du script. On dispose ainsi d’un historique « tournant » basé sur 9 fichiers : « acme_renew_python.log.1 » à « acme_renew_python.log.9 ». Le fichier à l’indice « 1 » étant toujours le dernier donc le plus récent. Nouvelle version v1.44 du script Python (à remplacer simplement dans le répertoire « /volume1/Scripts »). Pour faciliter la compréhension, le texte lié à cette édition est repéré en bleu. EDIT 11/08/2020 § 10 : Ajout d’une trace complète et systématique du processus de renouvellement. § 10 : Ajout de l’option « -f » au script Python de renouvellement. La partie configuration du renouvellement automatique du certificat au §6 a été revue grâce à l’aide de @bruno78 que je remercie vivement ici, pour prendre en compte une anomalie liée au Shell script « acme.sh » et à l’environnement particulier du NAS Synology. Cette anomalie ainsi que sa résolution, est décrite au § 10 ci-dessous. EDIT 01/06/2020 § 2 : Utilisation du "vrai" root pour la connexion SSH au lieu du "sudo -i" § 3.1 : Utilisation de l'Id principal de connexion OVH § 5.2.1 : Réaffectations de services à faire suite à la création du certificat en mode Ajout. Objectif de ce tutoriel : Créer un certificat « Wilcard » Let’s Encrypt (LE) afin : d’une part, de prendre en compte tous les domaines de second niveau de votre domaine personnel, et d’autre part, de s’affranchir de la limite fatidique de 256 caractères imposée par Synology pour les SAN (Subject Alternative Name – Autre nom de l’objet) lors de la création des certificats dans DSM. Pour mémoire, la méthode de création du certificat « wilcard » LE décrite dans le Tutoriel « Certificat TLS/SSL - Let's Encrypt "Wildcard" » de @unPixel utilisait le service ‘SSL For Free’. Malheureusement, ce service n’étant plus gratuit depuis le 18 mai 2020, il convenait alors pour moi de m’orienter sur un autre moyen pour obtenir un certificat « wilcard » LE et gratuit de surcroît. Nota : ‘SSL For Free’ fournit toujours gratuitement son service mais uniquement pour un seul nom de domaine du type « ndd.tld » (NomDeDomaine.Top-LevelDomain). En fouillant un peu la toile, j’ai fini par trouver cet autre moyen. Il est basé sur l’utilisation du client ACME via le Shell script « acme.sh » disponible sur GitHub. Je vous livre donc ci-après la méthode que j'ai suivie. J’ai essayé de la rendre aussi détaillée que possible. En fait elle est conçue pour « les nuls » 😊, mais pas que ... Sachez que c'est un mixte de différents tutoriels trouvés sur la toile, car aucun pris individuellement ne donnait complètement satisfaction vis-à-vis du but à atteindre et il fallait souvent s’adapter et/ou corriger en fonction de leurs contextes parfois légèrement différents. Je ne m’en cache pas, je n’ai pas réinventé la roue, vous retrouverez ici certaines explications directement extraites et traduites de ces tutoriels. Selon le cas, le lien vers l’original sera donné. Mais avant toutes choses, il convient pour mémoire, de faire un petit rappel contextuel. Depuis que Synology a introduit LE dans la gestion des certificats associés à ses NAS et Routeurs, beaucoup d'entre nous bénéficient du SSL gratuit et c’est très bien. D'un autre côté, beaucoup d'entre nous ne veulent pas exposer les ports 80 et 443 à Internet, y compris l'ouverture de ces ports sur le routeur. Malheureusement, l'actuelle implémentation Synology de LE ne prend en charge que la méthode de validation dite WEB, basée sur le protocole « HTTP-01 » qui nécessite d'exposer notamment le port 80 à Internet. Une alternative à cette non exposition est de passer par l’utilisation de la méthode de validation dite par DNS basée sur le protocole « DNS-01 ». Ce protocole présente l’avantage de ne pas avoir besoin d’ouvrir de ports lors de la création du certificat LE mais surtout lors de son renouvellement et là c’est le « plus » indéniable du point de vue sécurité qu’apporte cette méthode. Mais pour utiliser cette méthode de validation par DNS, il est obligatoire d’avoir la main sur la zone DNS du domaine concerné. En effet, LE vérifie la présence d’un enregistrement de type « TXT » sous la forme de « _acme‑challenge.votre-domaine.tld » contenant la valeur d’autorisation. Cet enregistrement permet de prouver que la personne qui demande le certificat, contrôle également la zone DNS du domaine en question. Il convient aussi de noter que le protocole « DNS-01 » est utilisé pleinement par les fonctions d’API (Application Programming Interface) développées par nos fournisseurs de domaines tels que OVH et que l’on va utiliser ici. Pour l’exemple, la méthode présentée ici, utilise les API de mon fournisseur OVH. Mais vous pouvez très bien utiliser les API d’un autre fournisseur car ACME prend en charge de nombreux autres services DNS. Il faudra alors adapter la méthode en fonction de ces autres fournisseurs. Rien de bien compliqué en soit, les paramètres diffèrent quelque peu mais le principe de mise en œuvre reste le même. Par ailleurs, l’utilisation du Shell script ‘acme.sh’ est rendu possible par le fait que nous pouvons accéder au NAS via une connexion SSH pour le configurer pour renouveler les certificats au lieu d'utiliser le tableau de bord WEB. Maintenant, cerise sur le gâteau si je puis dire, depuis peu Synology a introduit dans DSM le code nécessaire pour qu’il ne soit plus nécessaire d'exécuter le Shell script ‘acme.sh’ sur votre NAS pour renouveler le certificat. Le Shell script ‘acme.sh’ devra simplement être exécuté sur quelque chose (votre PC/Mac ou autre) qui a accès à l'interface d'administration de DSM. Du coup, les méthodes de déploiement du certificat généré sont considérablement simplifiées et c’est qui va être exploité dans la présente méthode. Voilà pour le discours préliminaire, on passe aux choses sérieuses … 1 Pré-requis · Disposer d’un nom de domaine personnel chez OVH. · Attribuer l’@IP externe de votre Box/Routeur à votre nom de domaine personnel. Pour cela, se rendre sur l'espace client d'OVH. Une fois connecté : Si vous avez une @IP fixe : aller dans l'onglet : « Web / Domaines / votre-domaine.tld / Zone DNS » vous devez avoir un enregistrement de type « A » dans le quel votre « votre-domaine.tld » pointe vers cette @IP fixe. Si vous avez une @IP dynamique : aller dans l'onglet : « Web / Domaines / votre-domaine.tld / DynHost » vous devez avoir une ligne avec « votre-domaine.tld » qui a pour cible votre @IP du moment (i.e. l’@IP externe de votre Box/Routeur). Ce même DynHost doit être également défini sur le NAS (« Panneau de configuration / Accès externe / DDNS » où le nom d’hôte est : « votre-domaine.tld ». 2 Installation du Shell script ‘acme.sh’ L’installation du Shell script ‘acme.sh’ doit s’effectuer dans un répertoire qui n’est pas modifié/réinitialisé lors des mises à jour de DSM. Pour ce faire, on va donc créer un répertoire spécifique d’installation « Certs/Acme_install » sous « /volume1 » et surtout pas sous le répertoire « /root » qui lui est régulièrement « nettoyé » par le système. Ce répertoire « /root » est également utilisé par défaut par ACME. Ceci expliquant cela. · Sous Windows ouvrir une session SSH sur le NAS (en tant qu’utilisateur « root ») avec « PuTTY » ou « WinSCP » · Sous Mac ouvrir une session SSH en lançant le « Terminal » puis tapez : ssh utilisateur-admin@ipdunas (si le port n'est pas 22 alors il faut rajouter « -pXXXXX » où XXXXX = No du port personnalié sudo -i (pour passer en « root » - c'est la procédure normale). · EDIT : Il s'avère que passer sous « root » via un « sudo -i» sur PC comme sur Mac, génère une erreur dans l'exécution de la commande « ./acme.sh». Aussi, je vous invite à suivre le Tuto sur les "Accès SSH et ROOT via DSM6" de @unPixel et ainsi de configurer un accès par le "vrai" « root ». Cela marche tout de suite bien mieux ... Nota 1 : Pour ma part sous Windows, je préfère l’utilisation de « WinSCP » à « PuTTY », tout simplement à cause de son interface graphique qui est très agréable de mon point de vue et aussi parce que l’on peut accessoirement directement sélectionner le texte affiché dans la Console pour le Copier/Coller ailleurs dans une autre application. C’est tout bête mais bien pratique au demeurant. Certes « PuTTY » le permet aussi mais je le trouve beaucoup moins souple de ce point de vue, et ce n’est que mon avis ... Nota 2 : Pour mémoire et ceci est valable pour toute la suite : le symbole « $ » présent en début des lignes de commandes Shell présentées ici, est ce qu’on appelle l’invite de commande du Shell. Dans le cas présent, il est propre à l’outil « WinSCP » que j’ai utilisé pour exécuter les différentes commandes Shell de cette procédure. Bien évidemment, il ne faut pas le sélectionner si vous faites des Copier/Coller du texte de ces commandes. Je préfère prévenir même si c’est évident pour certains initiés … · Tapez successivement les commandes suivantes : On crée le répertoire d’installation d’ACME : « /volume1/Certs/Acme_install » et on s’y place : $ cd /volume1 $ mkdir -p Certs/Acme_install $ cd Certs/Acme_install On télécharge ACME chez GitHub $ wget https://github.com/acmesh-official/acme.sh/archive/master.tar.gz On décompresse le fichier téléchargé et on se place dans le répertoire qui a été automatiquement créé lors de la décompression : $ tar xvf master.tar.gz $ cd acme.sh-master On lance l’installation d’ACME (pensez avant à remplacer dans la commande : « email@gmail.com » par votre @Mail personnelle) $ ACME_HOME="/usr/local/share/acme.sh" $ CERT_HOME="/volume1/Certs" « CERT_HOME » est le répertoire où seront générés les fichiers du certificat. Vous pouvez l’adapter à besoins. $ ./acme.sh --install --nocron --home "$ACME_HOME" --cert-home "$CERT_HOME" --accountemail "email@gmail.com" --nocron : spécifie de ne pas installer par défaut le « cron job ». Vous comprendrez de vous-même pourquoi plus loin. --home : désigne le répertoire « customisé » d’installation du Shell script ‘acme.sh’. C’est un répertoire dit « invariant ». C’est-à-dire qu’il n’est pas modifié par les mises à jour de DSM. Sinon par défaut, le script aurait été installé dans « ~/.acme.sh » où « ~ » correspond au répertoire ‘home’ de l’utilisateur « root » en l’occurrence : « /root ». Pour mémoire le répertoire « /root » est lui, dit « variant », donc sujet à modifications par les mises à jour de DSM. --cert-home : désigne le répertoire où seront générés les fichiers du certificat « wilcard » LE. Cette disposition permet de les sécuriser d’une part et d’autre part permet de les rendre accessibles facilement sans avoir à replonger dans les acarnes de DSM pour les retrouver en cas de besoin autre. Nota :Pour votre information, ce répertoire n’est pas un répertoire partagé au sens Synology. De fait, il ne sera donc pas visible sous « File Station » par exemple ce qui quelque part le protège de vos utilisateurs. Il ne sera donc visible qu’au travers d’une connexion directe au NAS dans une session SSH sous l’utilisateur « root ». Durant la courte installation, vous aurez certainement un message du style : It is recommended to install socat first. We use socat for standalone server if you use standalone mode. If you don't use standalone mode, just ignore this warning. Il faut savoir que ‘Acme.sh’ recommande l'installation du paquet « socat » pour gérer les certificats en mode standalone, mais comme nous n'allons pas utiliser ce mode, vous pouvez largement ignorer ce message. Vous trouverez donc, le dossier d'installation d’ACME dans le répertoire : « /usr/local/share/acme.sh ». Maintenant, il faut régénérer le fichier « .profile » de l'utilisateur courant (« root ») pour pouvoir utiliser immédiatement les commandes Shell. Pour cela, tapez simplement : $ source ~/.profile · Vérifier si besoin les droits d'exécution du fichier « acme.sh » : $ cd $ACME_HOME $ ls -al Normalement c’est bon mais si besoin, tapez : $ chmod a+x acme.sh · On active la mise à jour automatique du client (c’est préférable mais ce n’est pas une obligation) : $ ./acme.sh --upgrade --auto-upgrade Nota 1 : si vous souhaitez désactiver la mise à jour automatique d’ACME, tapez : $ ./acme.sh --upgrade --auto-upgrade 0 Comme vous pouvez aussi commenter manuellement la ligne : AUTO_UPGRADE="1" dans le fichier « /usr/local/share/acme.sh/account.conf » par l’ajout du caractère « # » en tout début de ligne. Nota 2 : Si vous êtes curieux et que vous souhaitez voir toutes les commandes disponibles pour ACME, tapez : $ ./acme.sh --help NE PAS quitter la session SSH 3 Configuration DNS 3.1 Création des clés Pour générer un certificat « wilcard » et pouvoir le renouveler automatiquement, on va donc utiliser l’API d’OVH. Pour ce faire, on va créer une application dans l’API qui va nous permettre de générer trois clés nommées respectivement : « application key », « application secret » et « consumer key ». Il est aussi une bonne pratique de sécurité que de limiter ce qu'une clé API donnée peut faire, dans le cas où elle serait perdue, volée ou que quelque chose de mal se produirait et ce, pour en limiter les dommages potentiels. Cela tombe bien, les clés API OVH peuvent être limitées à une zone de domaine spécifique à l'aide d'un mécanisme de modèle simple. On va donc en profiter pour restreindre une clé API OVH à la gestion de « votre-domaine.tld », en utilisant les paramètres suivants : GET=/domain/zone/votre-domaine.tld/* &POST=/domain/zone/votre-domaine.tld/* &PUT=/domain/zone/votre-domaine.tld/* &GET=/domain/zone/votre-domaine.tld &DELETE=/domain/zone/votre-domaine.tld/record/* Il est clair que cela peut facilement être personnalisé pour prendre en charge un ou plusieurs domaines si le besoin en est. Je vous renvoie à la documentation en ligne d’OVH pour plus de détails. · On se rend donc sur l’API d’OVH en saisissant l’URL suivante dans un navigateur WEB : https://api.ovh.com/createToken/?GET=/domain/zone/votre-domaine.tld/*&POST=/domain/zone/votre-domaine.tld/*&PUT=/domain/zone/votre-domaine.tld/*&GET=/domain/zone/votre-domaine.tld&DELETE=/domain/zone/votre-domaine.tld/record/* Nota : Dans le cas où vous ne souhaiteriez pas restreindre la gestion de la clé API OVH à votre domaine, il suffit simplement d’utiliser les paramètres suivants : ?GET=/domain/zone/* &POST=/domain/zone/* &PUT=/domain/zone/* &DELETE=/domain/zone/*/record/* o L’URL à utiliser pour aller sur l’API d’OVH, est alors : https://api.ovh.com/createToken/?GET=/domain/zone/*&POST=/domain/zone/*&PUT=/domain/zone/*&DELETE=/domain/zone/*/record/* · Donc avec le premier cas, on arrive sur l’écran suivant : Nota : Dans le second cas l’écran est très similaire, je vous laisse vous adapter. · On saisit les informations : o Account ID : votre identifiant principal de connexion chez OVH Nota : Si vous utilisez votre @Mail vous aurez un message d’erreur lors de la création des clés. o Password : votre mot de passe de connexion chez OVH. o Script name : Ce que vous voulez (par ex : « Synology_acme_sh ») mais avec que des caractères, pas d’espaces ni de points et pas de caractères spéciaux sinon cela bloque. o Script description : Ce que vous voulez (par ex : « Certificat wilcard LE – ACME ». o Validity : Dans le popup sélectionnez l’item « Unlimited ». · On clique en fin sur le bouton « Create keys ». · On obtient l’écran suivant, où il convient immédiatement de copier les clés et de les sauvegarder dans un fichier « .txt » : 3.2 Retour dans la session SSH · Taper successivement les commandes suivantes : $ export OVH_END_POINT=ovh-eu $ export OVH_AK="votre application key" $ export OVH_AS="votre application secret" $ export OVH_CK="votre consumer key" 4 Création du certificat Avant de créer effectivement le certificat il convient de préciser un point sur la méthode de chiffrement associée à la génération du certificat LE. Sans aucun paramètre spécifique, ACME utilise une clé de chiffrement de type RSA fixée à 2048 bits par défaut. Dans notre cas, on va directement forcer cette clé RSA à 4096 bits pour renforcer le niveau de sécurité, ce qui se fait par l’emploi du paramètre « -- keylength 4096 » dans la commande de création du certificat. Maintenant pour ceux qui le souhaitent, on peut aussi passer en mode « paranoïaque » et poussez plus loin les choses en adoptant un chiffrement basé sur une clé ECDSA qui elle s’appuie sur des courbes elliptiques. Malgré une faible longueur, ces clés sont très robustes et peut-être bien plus sécures que les clés RSA et sachant aussi que ces dernières sont déjà bien suffisantes pour nos besoins courants. Pour comparaison, une clé ECDSA 256 bits est équivalente à une clé RSA 3072 bits, et une clé ECDSA 384 bits est équivalente à une clé RSA 7680 bits ! À noter que LE reconnait les courbes elliptiques P-256 et P-384 mais le P-521 n'est pas encore reconnu. Donc dans ce dernier cas de figure, le paramètre à employer serait par exemple : « -- keylength ec-394 ». A vous de voir … Bon, il est maintenant vraiment temps de créer le certificat « wilcard » LE pour « votre-domaine.tld » : · Tapez successivement les commandes suivantes : $ cd $ACME_HOME $ export CERT_DOMAIN="votre-domaine.tld" $ export CERT_WDOMAIN="*.votre-domaine.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 Edit du 20/06/2021 : Suite aux récentes évolutions du Shell script ACME la commande de création du certificat doit être complétée par deux options. En effet, dorénavant lors de la création d'un nouveau certificat, par défaut c'est un certificat ZeroSSL qui est créé par ACME. Donc dans notre cas, comme l'on veux générer un certificat LesEncrypt, on doit ajouter les options suivantes à la commande de création pour forcer la génération du certificat LE : --set-default-ca --server letsencryp ainsi le shell script ACME prendra en compte ce choix qu'il retiendra d'ailleurs par la suite lors du renouvellement du certificat. Le processus de création du certificat se déroule et affiche un message du type : /usr/local/share/acme.sh$ ./acme.sh --issue --keylength 4096 -d "$CERT_DOMAIN" -d "$CERT_WDOMAIN" --dns "$CERT_DNS" [Sun May 24 22:42:07 CEST 2020] Create account key ok. [Sun May 24 22:42:07 CEST 2020] Registering account [Sun May 24 22:42:08 CEST 2020] Registered [Sun May 24 22:42:08 CEST 2020] ACCOUNT_THUMBPRINT='l7IOxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxfro' [Sun May 24 22:42:08 CEST 2020] Creating domain key [Sun May 24 22:42:13 CEST 2020] The domain key is here: /volume1/Certs/votre-domaine.tld/ votre-domaine.tld.key [Sun May 24 22:42:13 CEST 2020] Multi domain='DNS:votre-domaine.tld,DNS:*.votre-domaine.tld' [Sun May 24 22:42:13 CEST 2020] Getting domain auth token for each domain [Sun May 24 22:42:15 CEST 2020] Getting webroot for domain='votre-domaine.tld' [Sun May 24 22:42:15 CEST 2020] Getting webroot for domain='*.votre-domaine.tld' [Sun May 24 22:42:15 CEST 2020] Adding txt value: TLMxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxQWk for domain: _acme-challenge.votre-domaine.tld [Sun May 24 22:42:15 CEST 2020] Using OVH endpoint: ovh-eu [Sun May 24 22:42:15 CEST 2020] Checking authentication [Sun May 24 22:42:16 CEST 2020] Consumer key is ok. [Sun May 24 22:42:16 CEST 2020] Adding record [Sun May 24 22:42:17 CEST 2020] Added, sleep 10 seconds. [Sun May 24 22:42:27 CEST 2020] The txt record is added: Success. [Sun May 24 22:42:27 CEST 2020] Adding txt value: QXMxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxkJQ for domain: _acme-challenge.votre-domaine.tld [Sun May 24 22:42:27 CEST 2020] Using OVH endpoint: ovh-eu [Sun May 24 22:42:27 CEST 2020] Checking authentication [Sun May 24 22:42:27 CEST 2020] Consumer key is ok. [Sun May 24 22:42:27 CEST 2020] Adding record [Sun May 24 22:42:28 CEST 2020] Added, sleep 10 seconds. [Sun May 24 22:42:38 CEST 2020] The txt record is added: Success. [Sun May 24 22:42:38 CEST 2020] Let's check each dns records now. Sleep 20 seconds first. [Sun May 24 22:42:58 CEST 2020] Checking votre-domaine.tld for _acme-challenge.votre-domaine.tld [Sun May 24 22:42:58 CEST 2020] Domain votre-domaine.tld '_acme-challenge.votre-domaine.tld' success. [Sun May 24 22:42:58 CEST 2020] Checking votre-domaine.tld for _acme-challenge.votre-domaine.tld [Sun May 24 22:42:59 CEST 2020] Domain votre-domaine.tld '_acme-challenge.votre-domaine.tld' success. [Sun May 24 22:42:59 CEST 2020] All success, let's return [Sun May 24 22:42:59 CEST 2020] Verifying: votre-domaine.tld [Sun May 24 22:43:02 CEST 2020] Success [Sun May 24 22:43:02 CEST 2020] Verifying: *.votre-domaine.tld [Sun May 24 22:43:06 CEST 2020] Success [Sun May 24 22:43:06 CEST 2020] Removing DNS records. [Sun May 24 22:43:06 CEST 2020] Removing txt: TLMxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxQWk for domain: _acme-challenge.votre-domaine.tld [Sun May 24 22:43:06 CEST 2020] Using OVH endpoint: ovh-eu [Sun May 24 22:43:06 CEST 2020] Checking authentication [Sun May 24 22:43:06 CEST 2020] Consumer key is ok. [Sun May 24 22:43:09 CEST 2020] Removed: Success [Sun May 24 22:43:09 CEST 2020] Removing txt: QXMxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxkJQ for domain: _acme-challenge.votre-domaine.tld [Sun May 24 22:43:09 CEST 2020] Using OVH endpoint: ovh-eu [Sun May 24 22:43:09 CEST 2020] Checking authentication [Sun May 24 22:43:09 CEST 2020] Consumer key is ok. [Sun May 24 22:43:13 CEST 2020] Removed: Success [Sun May 24 22:43:13 CEST 2020] Verify finished, start to sign. [Sun May 24 22:43:13 CEST 2020] Lets finalize the order, Le_OrderFinalize: https://acme-v02.api.letsencrypt.org/acme/finalize/xxxxxxxxx/xxxxxxxxxxxxxx [Sun May 24 22:43:14 CEST 2020] Download cert, Le_LinkCert: https://acme-v02.api.letsencrypt.org/acme/cert/0xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx5c1f [Sun May 24 22:43:15 CEST 2020] Cert success. -----BEGIN CERTIFICATE----- xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx -----END CERTIFICATE----- [Sun May 24 22:43:15 CEST 2020] Your cert is in /volume1/Certs/votre-domaine.tld/votre-domaine.tld.cer [Sun May 24 22:43:15 CEST 2020] Your cert key is in /volume1/Certs/ votre-domaine.tld/votre-domaine.tld.key [Sun May 24 22:43:15 CEST 2020] The intermediate CA cert is in /volume1/Certs/votre-domaine.tld/ca.cer [Sun May 24 22:43:15 CEST 2020] And the full chain certs is there: /volume1/Certs/votre-domaine.tld/fullchain.cer Voilà déjà une bonne chose de faite … NE PAS quitter la session SSH 5 Déploiement du certificat Comme expliqué en préambule, Synology nous a facilité la vie pour le déploiement des fichiers du(des) certificat(s) généré(s). Cela se passe par l’emploi du « Synology DSM deployhook ». 5.1 Cas de la double authentification Si vous n’utilisez pas la double authentification pour vous connecter à votre NAS, passez directement au §5.2 ci-dessous. Mais avant de réaliser le déploiement effectif du certificat, il y a encore un point préciser car il y a un paramètre supplémentaire à prendre en compte dans le cas où, comme moi vous utilisez la double authentification pour vous connecter à votre NAS. En effet, si on ne renseigne pas ce paramètre, le processus de double authentification viendrait bloquer le déploiement du certificat tel qu’il sera décrit ci-après. Ce serait dommage convenez-en. Donc, habituellement lorsqu’on se connecte au NAS après avoir saisi son id/pseudo et son mot de passe, la double authentification réclame la saisie d’un code à six chiffres que l’on obtient à partir d’une application tierce installée idéalement sur un smartphone/iPhone. Pour n’en citer que quelques-unes, il y a : « FreeOTP Authenticator », « Google Authenticator », « Microsoft Authenticator », etc … (le choix est grand ! - pour la mise en place de la double authentification sur le NAS, reportez-vous à l’excellent Tutoriel de @Fenrir sur la sécurisation des accès au NAS). Bref, on récupère et on saisit donc ce code à six chiffres et on coche la case « Faire confiance à ce périphérique ». Cette dernière action a pour effet caché de créer un « cookie » dans votre navigateur qui lui, évite par la suite que ce code à six chiffres, ne vous soit systématiquement demandé à chaque connexion. Ce « cookie » stocke en interne un code nommé « DID » dont il nous faut récupérer la valeur pour alimenter le paramètre suscité. Pour récupérer la valeur de ce code « DID », normalement un simple clic gauche sur le cadenas situé à gauche de la barre d’URL du navigateur, suivi de la sélection de l’item « cookies » permet d’afficher ce code « DID ». Sauf que cela ne marche pas avec le navigateur FireFox. Pour contourner le problème, j’ai installé l’excellent module complémentaire « Cookie Quick Manager » dans FireFox. Ensuite on procède ainsi : · Se placer sur la page de connexion ou si déjà connecté, sur la page du navigateur affichant le bureau DSM de votre NAS. · Dans le popup de « Cookie Quick Manager », clic gauche et sélectionner l’item « Rechercher les cookies pour : URL de la page suscitée ». Cela peut-être selon : « https://nom-du-nas.ndd.tld » ou http://@IP_du_NAS:5000 ou encore « https://@IP_du_NAS:5001 ». · Une nouvelle page s’ouvre dans le navigateur, vous montrant tous le détail du cookie associé à la page du NAS. · Dans la partie droite de cette page, on trouve la valeur du fameux code « DID ». · Sélectionnez et Copiez cette valeur et refermez la page du cookie. · Revenez sur la session SSH et tapez la commande suivante en y collant la valeur du « DID » : $ export SYNO_DID=xxxxxxxxxxxxxxxValeur_du_DIDxxxxxxxxxxxxxxxxx Edit du 10/01/2021 Suite au retour de plusieurs utilisateurs dont le renouvellement du certificat avait échoué avec un message du style : « Tue Dec 15 15:58:28 CET 2020] Unable to authenticate to localhost:5000 using http. [Tue Dec 15 15:58:28 CET 2020] Check your username and password. » voici la « parade ». En fait, ce message survient parce que le cookie DID est périmé. Il s’avère qu’il n’a en fait qu’une durée de vie d’un mois et qu’il change donc tous les mois. Aussi, toute l’astuce va être d’aller éditer le cookie et de modifier sa date de péremption pour la repousser aux « calandres grecques ». Donc pour cela, comme expliqué ci-avant, vous éditez le cookie DID et vous modifiez le champ « expire » en indiquant une date en 2050 par exemple. Cela devrait suffire 😀. Dans le cas, où le cookie DID aurait changé, il vous faut alors aller modifier, dans une session SSH sous l’utilisateur « root » avec PuTTY ou WinSCP sur Windows ou dans un Terminal sur Mac, le fichier « /volume1/Certs/votre-domaine.tld/votre-domaine.tld.conf » pour mettre en accord la valeur de votre nouveau cookie DID avec le contenu de la variable « SAVED_SYNO_DID » sauvegardée par le système dans ce fichier. Ajout du 2021-02-15 : Il faut aussi mettre en accord la variable « SAVED_DID » qui se trouve elle, dans le fichier « /usr/local/share/acme.sh/account.conf ». Toujours pareil, attention lors du copier/coller de la valeur à ne pas prendre de caractères parasites ! N’oubliez pas aussi d’enregistrer le fichier à l’issue de vos modifications. Ainsi, plus de soucis de renouvellement à ce niveau … 5.2 Réalisation du déploiement du certificat Nota préliminaire : Tout ce qui suit présume que vous n’avez pas quitté la présente session SSH. Sinon, il faut réexporter toutes les variables définies précédemment. Sans quoi rien ne fonctionnera correctement ! Ce serait dommage, non ? Maintenant, deux cas de figure se présentent selon que l’on procède à un déploiement du nouveau certificat : · avec un mode « Annule et remplace » du certificat existant marqué « par défaut », · ou que l’on se contente d’ajouter simplement le nouveau certificat à la liste existante de vos certificats. Vous avez le choix, c’est vous qui décidez … 5.2.1 Mode « annule et remplace » du certificat par défaut Rappel : Ici on va ECRASER le certificat marqué par défaut dans le tableau de bord de DSM. Il n’existera plus !!! Vous êtes prévenus … · Dans la session SSH tapez successivement les commandes suivantes : o Par prudence, on vérifie que l’on est bien toujours placé dans le répertoire : « /usr/local/share/acme.sh ». $ pwd o Selon votre usage, décommentez et exécutez l’une ou deux ou les trois commandes suivantes : # export SYNO_Scheme="http" Par défaut : « http » mais on peut fixer à « https » # export SYNO_Hostname="localhost" Par défaut : « localhost » mais à spécifier si vous n’utilisez pas sur la présence machine. Les « très initiés » comprendront. # export SYNO_Port="5000" Port utilisé pour DSM, par défaut : 5000 pour HTTP et mais on peut fixer à 5001 pour HTTPS. o On poursuit les définitions de variables d’environnement : Attention ici, les « simples cotes » « ' » sont utilisées pour « échapper » les éventuels caractères spéciaux présents dans vos identifiants et mots de masse. $ export SYNO_Username='DSM_Admin_Username' $ export SYNO_Password='DSM_Admin_Password!123' La commande suivante est quant à elle impérative. Elle correspond à la description du certificat visible dans le tableau de bord de DSM. Toutefois pour pouvoir remplacer le certificat par défaut, il est nécessaire de spécifier une chaîne vide pour ce paramètre. Ne me demandez pas pourquoi ! (si un « initié » sait, je corrigerai en conséquence avec l’explication du pourquoi). $ export SYNO_Certificate="" · Et on déploie enfin le certificat … $ ./acme.sh --deploy -d "$CERT_DOMAIN" --deploy-hook synology_dsm 5.2.2 Mode « ajout » du nouveau certificat Ici, on va simplement ajouter le nouveau certificat à la liste des certificats éventuellement déjà présents sur le NAS. Le processus est sensiblement le même que celui décrit au §5.2.1 ci-dessus. · Dans la session SSH tapez successivement les commandes suivantes : o Par prudence, on vérifie que l’on est bien toujours placé dans le répertoire : « /usr/local/share/acme.sh ». $ pwd o Selon votre usage, décommentez et exécutez l’une ou deux ou les trois commandes suivantes : Par défaut : « http » mais on peut fixer à « https » # export SYNO_Scheme="http" Par défaut : « localhost » mais à spécifier si vous n’utilisez pas sur la présence machine. Les « très initiés » comprendront. # export SYNO_Hostname="localhost" Port utilisé pour DSM, par défaut : 5000 pour HTTP et mais on peut fixer à 5001 pour HTTPS (dans ce dernier, il faut ajouter l'option "--insecure" à la commande de déploiement donnée plus loin). # export SYNO_Port="5000" o On poursuit les définitions de variables d’environnement : Attention ici, les « simples cotes » « ' » sont utilisées pour « échapper » les éventuels caractères spéciaux présents dans vos identifiants et mots de masse. $ export SYNO_Username='DSM_Admin_Username' $ export SYNO_Password='DSM_Admin_Password!123' La commande suivante est quant à elle impérative. Elle correspond à la description du certificat visible dans le tableau de bord de DSM. Toutefois pour pouvoir ajouter le nouveau certificat, il est nécessaire de spécifier une chaîne non vide pour ce paramètre. Là, cela paraît évident … (Quoi que …) Vous nommez votre certificat comme bon vous semble. Pour ma part je lui donne le nom qui précise mon domaine « ACME_Wilcard_LE_*.ndd.tld » pour plus de clarté. Encore une fois, c’est vous qui voyez … $ export SYNO_Certificate="Nom_du_certificat" o Une dernière variable d’environnement : Par défaut : ce paramètre est sur « off » et n’est pas enregistré mais on peut le fixer à « 1 » pour indiquer au système de créer le certificat s’il n’existe pas déjà. $ export SYNO_Create=1 · Et on déploie enfin le certificat … $ ./acme.sh --deploy -d "$CERT_DOMAIN" --deploy-hook synology_dsm Dans cette commande, pour le cas où vous le souhaiteriez, on peut préciser un domaine de second niveau. La commande est alors : $ ./acme.sh --deploy -d "secondNiv.$CERT_DOMAIN" --deploy-hook synology_dsm Nota : On peut remarquer dans le message ci-dessus la ligne : « http services were NOT restarded », ne sachant pas ce qu’il faut en faire, je l’ai provisoirement ignorée. Je n’ai d’ailleurs pas constaté par la suite de disfonctionnements qui lui soient liés. Cela dit, je compte sur les « initiés » pour me dire s’il y a une quelconque action à exécuter vis-à-vis de ce message. D’avance merci, je mettrai à jour la présente procédure en conséquence. Toujours est-il, le nouveau certificat est maintenant visible dans « Panneau de configuration / Sécurité /Certificat » de DSM : Ici par défaut on constate que : · d’une part le nouveau certificat a été automatiquement marqué pour une utilisation « par défaut », · • et d’autre part là, deux cas de figures peuvent se présenter : Soit vous êtes dans le cas d’une toute première création du certificat i.e. aucun autre certificat pour « votre-domaine.tld » n’existait auparavant, alors il est obligatoire de réaliser une affectation manuelle du certificat aux services qui vont l’utiliser pour une bonne prise en compte de celui-ci. Pour cela : Sélectionnez le certificat. Cliquez sur le bouton « Configurer » et affectez le certificat aux services de votre choix en le sélectionnant dans le popup en regard du service concerné. Soit vous êtes dans le cas d’une nouvelle création du certificat avec déjà un certificat pour « votre-domaine.tld » existant auparavant, alors avec cette création, le constat est qu’il n’a pas repris les assignations aux services qui existaient pour le certificat précédemment marqué par défaut. Il vous faut alors reprendre ces assignations manuellement. Toujours pareil, vous adaptez à votre besoin … Nota : Dans ce dernier cas, sachez que ce comportement est normal puisque l’on crée le certificat. Un dernier constat : on ne le voit pas sur la copie d’écran, mais bien évidemment, le certificat précédemment marqué pour une utilisation par défaut, n’a pas disparu. Il est bien toujours présent dans la liste des certificats. Il n’est tout simplement plus marqué pour une utilisation par défaut. Rien n’a été perdu, c’est ce qui importe ! NE PAS quitter la session SSH 6 Configurer le renouvellement du certificat Maintenant que le certificat « wilcard » LE a été créé et déployé sur le NAS, il faut assurer son renouvellement à l’échéance fatidique de 3 mois. En fait, cette échéance est variable dans le sens où selon la date de génération du certificat il peut se passer entre 89, 90, 91 et 92 jours. Mais en pratique lors de son exécution, le script « acme.sh » contrôle par défaut si la date courante est supérieure de plus de 60 jours par rapport à la date de création du certificat avant de lancer ou non le renouvellement effectif de celui-ci. Par sécurité, on ne va pas « s’embêter », on va programmer tout simplement cette opération de contrôle du besoin de renouvellement, avec une exécution hebdomadaire à un horaire de faible charge du NAS (par exemple tous les Lundi et donc a priori la nuit soit à 00h00). Libre à vous de modifier cette périodicité selon vos propres besoins. C’est vous qui voyez … Mais avant toute choses, on va installer un petit programme/script écrit en langage Python (Encore MERCI à @bruno78 qui l’a développé) destiné à compléter l’action normale du script « acme.sh » en réalisant un certain nombre d’autres opérations spécifiques et rendues nécessaires par l’environnement du NAS Synology (pour les plus curieux, ces actions sont explicitées en détail au § 10 ci-dessous). Rassurez-vous, vous n’avez pas besoin de connaître le langage Python. Celui-ci est nativement géré par le NAS Synology au travers du package « Python module ». Vérifiez juste que ce package est bien installé sur votre NAS et auquel cas installez le via le centre de paquets. EDIT 21/08/2020 Le script Python est maintenant compatible de la dernière et actuelle version 3.x.x du langage Python. Si vous envisagez d’utiliser Python3 il vous faut alors installer le package « Python3 » disponible dans la rubrique « Outils de développement » dans le centre de paquets de DSM. Donc, le package « Python module » ou le package « Python3 » étant installé : Créez un répertoire spécifique pour accueillir ce script Python : On crée le répertoire : « /volume1/Scripts » et on s’y place : Nota 1 : Ce chemin peut être tout autre selon vos besoins, mais veillez à rester cohérent dans son utilisation par la suite. Nota 2 : Ce répertoire, tout comme le répertoire « Volume1/Certs » créé précédemment, n’est pas un répertoire partagé au sens Synology. De fait, il ne sera donc pas visible sous « File Station » par exemple ce qui quelque part le protège de vos utilisateurs. Il ne sera donc visible qu’au travers d’une connexion directe au NAS dans une session SSH sous l’utilisateur « root ». $ cd /volume1 $ mkdir -p Scripts $ cd Scripts Téléchargez sur votre PC/Mac le fichier du script Python : acme_renew.py Copiez/Collez ce fichier sur le NAS dans le répertoire « /volume1/Scripts ». (via WinSCP c’est on ne peut plus simple !). Le script Python étant en place, on va programmer effectivement l’exécution périodique de ce script. Nota :En préalable et pour ceux qui seraient tentés de le faire, il faut également savoir qu’Il n'est pas conseillé de configurer directement un « cron job » personnalisé car le conseiller de sécurité DSM va rapidement vous rappeler à l’ordre et vous dira que vous avez un avertissement critique concernant un ou des cron job(s) inconnu(s). Donc pour ce faire, on va configurer une tâche dans le planificateur de tâches de DSM. · Dans « Panneau de configuration / Planificateur de tâches », cliquer sur le bouton « Créer » et sélectionner dans le popup : « Tâche planifiée / Script défini par l’utilisateur » · Dans la fenêtre « Créer une tâche » onglet « Général » nommez la tâche à exécuter périodiquement. Par exemple : « RenewCertif_W_LE ». L’utilisateur doit être « root » et la case « Activé » est cochée. · Dans l’onglet « Paramètres de la tâche » : o Pour la partie « Paramètres généraux » : si vous voulez recevoir par eMail les détails d’exécution de la tâche : cochez la case correspondante et saisissez votre @Mail. Vous pouvez aussi décider de ne recevoir ces eMails uniquement si l’exécution de la tâche se termine de façon anormale. Dans ce cas cochez la case correspondante. o Pour la partie « Exécuter la commande » : saisir la commande suivante : python /volume1/Scripts/acme_renew.py -l votre-domaine.tld Ou si vous souhaitez utiliser la version sous « Python3 » : python3 /volume1/Scripts/acme_renew.py -l votre-domaine.tld Dans cette commande : - Le chemin d’accès au script « acme_renew.py » (ici « /volume1/Scripts/ ») devra être modifié selon que vous en aurez défini un autre ci-avant. - Le paramètre « -l » est quant à lui optionnel. Libre à vous de l’indiquer ou pas. Néanmois je ne peux que vous conseiller de le mentionner pour le cas où … On n’est jamais trop prudent. Si vous l’indiquez explicitement, sachez qu’à chaque renouvellement, un fichier de « log » nommé « acmelog » sera automatiquement généré dans le répertoire « /volume1/Certs/Acme_renew/ » lui-même créé automatiquement par le script Python. Donc si un quelconque problème survenait, vous disposerez alors d’une trace complète de toutes les opérations réalisées lors du processus de renouvellement du certificat« wilcard » LE. Si tout est OK, vous aurez tout de même une trace mais forcément « light ». - Le paramètre « votre-domaine.tld » est quant à lui OBLIGATOIRE et est bien évidemment à remplacer par l’intitulé de votre propre domaine pour lequel le certificat doit être renouvelé. · Dans l’onglet « Programmer » : o Sélectionner « Exécuter les jours suivants » o Dans le popup, cochez la case « Lundi ». o Dans la zone « Temps » : laisser les valeurs par défaut. · Valider l’ensemble de votre paramétrage en cliquant sur le bouton « OK ». EDIT du 20/06/2021 : Suite aux récentes évolutions du Shel script ACME (voir plus haut pour la commande de création du certificat) il n'y a normalement rien à faire si vous disposer déjà d'un certificat LE. Le Shell script ACME de lui même s'adapte et assure le rouvellement de votre certificat comme avant. Toutefois, afin de s'assurer et forcer ce renouvellement avec LetEncrypt, il convient d'ajouter (sous SSH à la fin du fichier) la ligne suivante dans votre fichier "account.conf" (/usr/local/share/acme.sh/account.conf) : DEFAULT_ACME_SERVER='https://acme-v02.api.letsencrypt.org/directory' 7 En cas de problème suite à une mise à jour de DSM En cas de problème suite à une mise à jour de DSM, on peut réparer l’environnement ACME en exécutant les commandes suivantes dans une session SSH sous l’utilisateur « root » : $ cd /usr/local/share/acme.sh $ ./acme.sh --force --upgrade --nocron --home /usr/local/share/acme.sh Vous pouvez aussi ajouter la ligne suivante dans le fichier « /root/.profile » et régénérer le « .profile » en tapant : . "/usr/local/share/acme.sh/acme.sh.env" $ source /root/.profile 8 Arrêter le renouvellement du certificat Pour arrêter le renouvellement d’un certificat, vous pouvez exécuter dans une session SSH sous l’utilisateur « root » , les commandes suivantes pour supprimer le certificat de la liste de renouvellement : $ cd /usr/local/share/acme.sh $ ./acme.sh --remove -d votre-domaine.tld Les fichiers « .cert » et « .key » de votre certificat ne sont pas supprimés du disque. Vous pouvez supprimer le répertoire correspondant (par exemple : « /volume1/Certs/votre-domaine.tld ») par vous-même. 9 Un dernier truc utile Vous pouvez éventuellement avoir besoin de convertir votre certificat en un fichier « .p12 » ou « .pfx » exploitable sous Android. C’est utile par exemple, pour un client VPN installé sur le smartphone. Dans ce cas, vous pouvez exécuter dans une session SSH sous l’utilisateur « root » , les commandes suivantes : $ ACME_HOME="/usr/local/share/acme.sh" $ CERT_HOME="/volume1/Certs" $ cd $ACME_HOME $ ./acme.sh --toPkcs -d votre-domaine.tld Enter Export Password: Verifying - Enter Export Password: [Mon May 25 20:00:28 CEST 2020] Success, Pfx is exported to: /volume1/Certs/votre-domaine.tld/votre-domaine.tld.pfx « Password » est le mot de passe utilisé pour ouvrir la session SSH. 10 Évolution du processus de renouvellement du certificat EDIT du 11/08/2020 et du 21/08/2020 Afin d’améliorer la recherche de la (les) cause(s) d’un éventuel dysfonctionnement dans le processus de renouvellement du certificat, la trace complète de toutes les opérations effectuées lors du déroulement de ce processus a été remaniée de façon à fournir un historique « tournant ». Ces informations sont inscrites dans un fichier nommé « acme_renew_python.log.x » qui est automatiquement généré dans le répertoire « /volume1/Certs/Acme_renew ». Cette trace est systématiquement générée que vous utilisiez ou non l’option « -l » pour obtenir un « log » du processus. Au total, vous disposerez de neuf (9) fichiers de trace sachant que le fichier ayant l’indice « 1 » sera toujours celui correspondant à la dernière exécution du script, donc le plus récent. Si pour une quelconque raison vous aviez besoin de renouveler votre certificat LE avant sa date normale de renouvellement, une option dédiée à cet effet à été ajoutée au script Python (v1.40). Cette option « -f » ou « --force » doit toutefois être utilisée avec parcimonie. En effet, LetsEncript limite le nombre de modifications d’un certificat d’un même domaine à cinq (5) par semaines calendaires. Au-delà de ces cinq (5) modifications dans une même semaine, vous serez bloqués et ne pourrez pas renouveler votre certificat durant une semaine à compter de la dernière modification tentée. Vous êtes donc prévenus ... EDIT du 25/07/2020 Suite aux retours de plusieurs utilisateurs « initiés », il a été fait le constat que le processus de renouvellement du certificat tel qu’il existait, n’était pas pleinement satisfaisant. En effet, même si en apparence le certificat semblait renouvelé dans le « Panneau de configuration / Sécurité / Certificat » avec une nouvelle date d’expiration affichée en vert et qu’il était bien marqué « par défaut », en fait il ne l’était pas complétement. À l’usage il générait encore des messages liés à une connexion non sécurisée avec une erreur du type « SLL_ERROR_BAD_CERT_DOMAIN ». La raison en était que les fichiers « .pem » du nouveau certificat n’avaient en fait, pas été recopiés partout où ils auraient dû l’être et du coup les navigateurs Web utilisaient toujours les anciens fichiers. Pour les plus sceptiques vis-à-vis de cette apparence trompeuse et pour bien se rendre compte que c’était toujours l’ancien certificat qui était pris en compte par les navigateurs Web, il suffit effectuer les manipulations suivantes : Effacer le cache du navigateur Web. Recharger le site web consulté où l’erreur SSL était apparue. Examiner le certificat utilisé par le navigateur dans ce cas. On constate que c’est toujours l’ancien certificat à la vue de sa date d’expiration. On obtient aussi la preuve que le processus de renouvellement pour le cas particulier de l’environnement du NAS Synology n’était pas complet, en examinant via une connexion SSH sous « root », les fichiers « .pem » contenus dans le répertoire « /usr/local/etc/certificate/WebStation/vhost_xxxxxx ». Ces fichiers correspondaient exactement à l’ancien certificat. Par ailleurs, après sa création et/ou son renouvellement, il avait été constaté que le nouveau certificat n’était pas non plus, appliqué et/ou réappliqué aux services à l'image de ce qui existait pour le certificat précédemment actif et marqué par défaut. Il fallait alors reprendre manuellement via le menu « Configurer », toutes les affectations de ce nouveau certificat aux différents services qui l’utilisaient. Opération laborieuse s’il en était … Nota : Je vous rappelle si besoin en est, qu’après toute création du certificat (qu’il en existe déjà un ou non pour « votre-domaine.tld »), cette opération d’affectation du certificat aux services est obligatoire pour la bonne prise en compte de celui-ci. Vous en conviendrez donc, du point de vue automatisation ce n’était pas top ! 🤔 Ces différents problèmes nous ont donc conduits @bruno78 et moi-même à plancher sur une automatisation COMPLETE de la procédure de renouvellement du certificat et il faut bien le dire ici, sans les talents de développeur de @bruno78, nous n’aurions pas aujourd’hui une procédure pleinement fonctionnelle et efficiente. Donc, @bruno78 a développé un script en langage Python nommé « acme_renew.py » qui réalise maintenant correctement tout le « boulot » si je puis dire. À noter que ce script dispose également de certaines fonctionnalités disponibles uniquement dans le cadre une utilisation manuelle en mode SSH sous « root » que je vais vous détailler plus loin. Pour d’ores et déjà satisfaire la curiosité des utilisateurs « initiés », de façon succincte, ce script Python réalise les opérations suivantes : Lecture des fichiers « INFO » et « DEFAULT » (« /usr/syno/etc/certificate/_archive ») Vérification de l’atteinte ou non de la date de renouvellement (minimum T0+60 jours, valeur par défaut inscrite dans le code du Shell script « acme.sh »). Sauvegarde du répertoire « /usr/syno/etc/certificate/_archive » y compris des fichiers « INFO » et « DEFAULT » Récupération des services du certificat originel par défaut selon qu’il a été généré avec une clé de chiffrement de type RSA ou ECDSA. Renouvellement du certificat : On reprend ici la commande originelle de renouvellement du script « acme.sh » à laquelle on a ajouté des paramètres spécifiques (« /usr/local/share/acme.sh/acme.sh --cron –force –debug --log --home /usr/local/share/acme.sh/ ») : « --force » pour le forcer à renouveler le certificat (la simple option « –renew » n’est pas suffisante car elle génère un message d’erreur qui stipule de surcroît d’utiliser l’option « --force », donc on applique cette option directement). « --debug » pour avoir un maximum de messages de traçage des opérations réalisées. « --log » pour récupérer les messages générés dans un fichier « Log » de trace. Lecture des nouveaux fichiers « INFO » et « DEFAULT » générés suite au renouvellement. Mise à jour du fichier « INFO » en inscrivant les services sur le nouveau certificat « par défaut » Renommage de la description de l'ancien certificat en "xxx_old". Distribution les nouveaux fichiers du certificat dans les répertoires système du NAS « /usr/syno/etc/certificate » et « /usr/local/etc/certificate ». Recherche et constitution de la liste des packages et services qui utilisent le certificat. Redémarrage global de ces packages et services en incluant leurs dépendances. Donc comme évoqué précédemment, le script Python « acme_renew.py » peut être utilisé selon deux modes de fonctionnement : En mode dit « Standard ou automatique » : c’est celui qui est typiquement utilisé pour la commande de renouvellement intégrée à la tâche périodique que vous avez définie dans DSM au § 6 ci-dessus et dans lequel la description des paramètres que le script accepte, est précisée. Veuillez-vous y reporter. En mode dit « Manuel » : ce mode correspond à une utilisation directe en lignes de commandes dans une connexion au NAS via une session SSH sous l’utilisateur « root ». Donc, ouvrez une connexion SSH sous « root » et tapez les commandes suivantes : $ cd /volume1/Scripts $ python acme_renew.py -h Avec ce paramètre « -h » vous obtenez une aide sur tous les paramètres utilisables avec le script Python « acme_renew.py » : Les informations fournies par cette option « -h » se suffisent à elles-mêmes. Elles ne seront donc pas décrites/détaillées plus avant. Nota : Dans cette aide le paramètre « ndd.tld » correspond bien évidemment à « l’intitulé » de votre domaine soit « votre-domaine.tld ». Toutefois, dans le cas particulier d’une utilisation avec le paramètre « -c » il convient de préciser ceci : En aucun cas vous ne devez utiliser la commande « python acme_renew.py -c votre-domaine.tld » ou « python3 acme_renew.py -c votre-domaine.tld » dans une fenêtre de console sous WinSCP ! La raison en est, que la console de WinSCP ne supporte pas l’exécution de commandes dites « interactives ». Si d’aventure vous faisiez cette erreur, sachez que vous allez entrer dans une boucle sans fin et que le seul moyen d’en sortir sera de « tuer » le process WinSCP dans le gestionnaire de tâches de Windows. Maintenant vous êtes prévenus ! Par contre, il n’y a aucun souci pour exécuter cette commande interactive dans une fenêtre « Terminal » de PuTTY sur PC (même si celle-ci est lancée à partir de WinSCP) ou d’une fenêtre « Terminal » sur Mac. Voilà c’est fini, profitez bien de votre certificat « wilcard » Let’sEncrypt !!! GRATUIT !!! et ne nécessitant plus d’ouvrir les ports 80 et/ou 443 sur votre NAS pour son renouvellement. À l’usage, on en oublierait presque la chose … Le fichier ".pdf" de cette procédure : Création_Certif_Wilcard_LE_avec_ACME_20210215.pdf Bien évidemment, je prendrais en compte toutes remarques et suggestions visant à corriger si besoin mais surtout à améliorer ce tutoriel. MERCI de vos retours ... Merci à @maxou56 pour ses compléments d’informations liées au monde Mac. Cordialement Oracle7😉

@Thierry94 Oui çà marche avec les @IP_locale_nas:port pour File, Audio, Surv, etc... mais uniquement en http, pas en https Çà passe aussi en https pour @IP_locale_Camera. Ce qui est étonnant c'est qu'avec SSLVPN, il n'y a aucun soucis, TOUT passe en "xxxxx.ndd.tld". Autre constat : en mettant dans les réglages du client : "minimum TLS 1.2" au lieu de "profil default", la communication "semble" plus rapide. Cordialement oracle7😉

@SODEJO et @Thierry94 Pour ma part, cela fonctionne en partie en seulement. J'atteins sans problème mes 2 NAS sur le réseau local avec "nom-du-nasX.ndd.tld" MAIS impossible d'atteindre mes autres périphériques du réseau local avec "xxxxx.ndd.tld". Là je comprends pas trop ????? Cordialement oracle7😉

@Outimeme Bonjour, Bon pour le coup @GrOoT64 a été plus rapide que moi à propos du TLD. Bien sûr, comme je te l'ai dit dans une précédente réponse, il t'évite de récolter des avertissements de connexion non sécurisée d'une part et d'autre part même s'il sa non présence n'est pas bloquante il évite ainsi que tu acceptes la connexion non sécurisée et que cette acception dans le temps devienne si je puis dire une habitude néfaste. Néfaste dans le sens où tu peux avoir aussi ce genre d'alerte en navigant sur d'autres sites non sécurisés et que tu acceptes encore machinalement l'exception de sécurité qui pour le coup peut s'avérer dangereuse selon le site consulté. J'espère ne pas avoir été trop confus dans mon propos. Si cà mouline pendant la validation du certificat c'est que les serveurs de Let'sEncrypt ne peuvent "discuter" avec ton NAS car il ya de fortes chances que ton port 80 ne soit pas ouvert dans ton parefeu (juste le temps de la création du certificat et lors de son renouvellement à échéance de 3 mois). il faut aussi que le port 443 soit ouvert dans ton parefeu. Donc vérifie ces ouvertures et relance la validation de ton certificat. Cela devrait se passer sans problème alors. Cordialement oracle7😉

@GrOoT64 Bonjour, Effectivement c'est mieux avec cela, impéccable ! Merci 😀 🍻 Cordialement oracle7😉

@Kramlech Bonjour, Oui j'ai lu cela sur le forum, mais j'ai un doute car j'ai un certificat qui a été renouvelé automatiquement récemment (-8j) alors le port 80 était ouvert sur ces @IP. Maintenant, @Thierry94 a aussi laissé entendre, sans en être toutefois totalement sûr, que le renouvellement se ferait maintenant uniquement via le port 443 ouvert. Comme mon port 443 l'est aussi (en même temps que ces 2 @IP pour le port 80) pour le fonctionnement du revers proxy, il est tout à fait possible que ce renouvellement de mon certificat soit passé justement par ce port 443 ouvert. Ce qui confirmerait ses dires. Si c'est bien le cas , c'est une très bonne choses pour nous tous qui utilisons ce biais. Il n'y aurait plus besoin de guetter la date fatidique de ce renouvellement pour aller ouvrir le port. Cela dit, il n'y a, à ma connaissance, pas de moyens non plus pour s'assurer que seul le port 443 ouvert suffit, d'où toujours ce doute ... Ton avis STP ? Cordialement oracle7😉

@EVOTk Bonjour, Pour te conforter, c'est exactement la bonne explication ! Cordialement oracle7😉

@GrOoT64 Oui, mais il n'est pas actif pour l'instant. Oui. Cordialement oracle7😉

@GrOoT64 Désolé, je ne comprends pas, tu peux préciser STP ? Cordialement oracle7😉

@Thierry94 Effectivement, dans ce cas il te faut chercher sur la toile un site qui aurait le fichier "apk" de la version précédente. Avec un peu de chance, tous les sites ne sont pas "up to date" ! Cordialement oracle7😉