[TUTO]Création d'un Certificat "wilcard" Let'sEncrypt avec la méthode "acme.sh"

[vincentbls]

il y a 48 minutes, bruno78 a dit :

@vincentbls

oui ca doit passer manuellement. Sauvegarde tes anciens fichiers *.pem avant. Ensuite, je ne suis pas certain de la nécessité de redemarrer, ou pas, nginx.  Il me semble avoir constaté que cela est pris en compte même sans redemarrer nginx, ... mais bon au cas ou ....

Finalement il suffit simplement de réimporter manuellement dans DSM (et en remplacement) le certificat qui est dans /volume1/docker/acme/nomdomaine.nd.

Mais ça casse tout l'intérêt de la procédure effectivement... ☹️

[TuringFan]

Bonsoir @oracle7,

C'est bon tout fonctionne nickel ! Merci pour tes réponses sur le forum et les MP.
Vivement ton prochain tuto !

Merci également @vincentbls pour le coup du saut de ligne à supprimer !

Par contre un truc que je ne suis pas certain d'avoir bien compris, à quoi correspond la partie ci-dessous (le https bloque systématiquement chez moi).

Le 30/05/2020 à 10:35, oracle7 a dit :

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.

Bonne soirée,

[oracle7]

@TuringFan

Bonjour,

Parfait, je suis bien content que tu ais pu faire cette génération.

Ces déclarations de variables d'environnement sont normalement à faire si on ne souhaite pas suivre les valeurs par défaut utilisées par ACME.

Typiquement par défaut ACME utilise HTTP et port 5000 mais on pourrait très bien passer par HTTPS et port 5001.  Le code interne de ACME prévoit cette possibilité. Cela dit, j'avoue ne pas l'avoir testée, mais ce qui est tout de même étonnant, vu ce que tu dis, c'est que cela ne marche pas. Peut-être un bug du code ?

Pour SYNO_Hostename, j'ai repris cela depuis un tuto "US". Ils n'en disaient pas beaucoup plus sur l'usage exact mais j'ai cru comprendre que c'est pour désigner une autre machine sur laquelle on peut faire la génération. J'espère ne pas avoir mal interprété ! Dans notre cas et pour faire "simple", il vaut mieux rester sur la valeur par défaut "localhost". Au moins c'est sûr cela marche avec cette valeur.

Cordialement

oracle7😉

[Jeff777]

il y a une heure, oracle7 a dit :

Pour SYNO_Hostename, j'ai repris cela depuis un tuto "US". Ils n'en disaient pas beaucoup plus sur l'usage exact mais j'ai cru comprendre que c'est pour désigner une autre machine sur laquelle on peut faire la génération

Bonjour @oracle7

Je confirme que cela  fonctionne. Je viens de créer un certificat sur mon deuxième NAS à l'aide de son hostname à partir du premier NAS.

Je pense que l'on doit pouvoir lors des renouvellements déployer le même certificat sur les deux NAS.

Edit : il est bien par défaut mais les services ne lui sont pas affectés. Cela ne te surprendra pas 😄

 

Modifié le 26 juin 2020 par Jeff777

[oracle7]

@Jeff777

il y a 39 minutes, Jeff777 a dit :

Je confirme que cela  fonctionne. Je viens de créer un certificat sur mon deuxième NAS à l'aide de son hostname à partir du premier NAS.

Je pense que l'on doit pouvoir lors des renouvellements déployer le même certificat sur les deux NAS.

Eh bien tant mieux !

En principe un certificat est indépendant du NAS vu qu'il concerne ton domaine, donc je ne vois pas pourquoi on ne pourrait pas le déployer sur plusieurs NAS. Je le fais déjà pour mon routeur.

Cordialement

oracle7😉

[Jeff777]

il y a 1 minute, oracle7 a dit :

En principe un certificat est indépendant du NAS vu qu'il concerne ton domaine

Oui mais pour mon cas il faut qu'il soit présent sur les deux nas pour assurer la redondance en cas de crash d'un des deux .

[Jeff777]

@bruno78

@oracle7 @.Shad.

Bon je serai très prudent. J'ai peut-être une piste pour l'automatisation de l'affectation des services. Du moins dans le cas du remplacement d'un certificat.

Je l'ai fait en staging car je n'ai plus de cartouche pour le faire hors staging  j'ai donc un certificat "fake" mais les services lui sont affectés.

D'autre part, même si je suis chez OVH je n'utilise pas les DNS d'OVH mais DNSServeur et un DNS secondaire chez HE.

Le certificat a été obtenu sur un deuxième NAS en utilisant acme sur le premier.

Alors question : Si la procédure est délocalisée du NAS dont on veut renouveler le certificat (sur un autre NAS ou peut-être un Rasberry) est-ce que cela pourrait fonctionner?

Modifié le 26 juin 2020 par Jeff777

[oracle7]

@Jeff777

C'est vrai que c'est une piste intéressante pour ceux qui ont plusieurs NAS et/ou qui disposent de RPI à d'autres fins.

Maintenant, mon soucis lorsque j'ai proposé cette procédure, était (et est toujours) que le maximum d'utilisateurs, entends par là parmi les utilisateurs qui n'ont qu'un seul NAS à leur disposition, puissent générer et renouveler ensuite leur certificat de façon totalement transparente.

On n'est plus très loin du but d'après @bruno78 , perso je préfère le laisser terminer tranquillement ses tests.

Cordialement

oracle7😉

 

 

[TuringFan]

Il y a 4 heures, oracle7 a dit :

@TuringFan

Bonjour,

Parfait, je suis bien content que tu ais pu faire cette génération.

Ces déclarations de variables d'environnement sont normalement à faire si on ne souhaite pas suivre les valeurs par défaut utilisées par ACME.

Typiquement par défaut ACME utilise HTTP et port 5000 mais on pourrait très bien passer par HTTPS et port 5001.  Le code interne de ACME prévoit cette possibilité. Cela dit, j'avoue ne pas l'avoir testée, mais ce qui est tout de même étonnant, vu ce que tu dis, c'est que cela ne marche pas. Peut-être un bug du code ?

Pour SYNO_Hostename, j'ai repris cela depuis un tuto "US". Ils n'en disaient pas beaucoup plus sur l'usage exact mais j'ai cru comprendre que c'est pour désigner une autre machine sur laquelle on peut faire la génération. J'espère ne pas avoir mal interprété ! Dans notre cas et pour faire "simple", il vaut mieux rester sur la valeur par défaut "localhost". Au moins c'est sûr cela marche avec cette valeur.

Cordialement

oracle7😉

Merci pour les explications,

[PPJP]

Bonjour,

Comme prévu, je viens de repasser sur ce forum.

Le renouvellement automatique du certificat LE générique n’y figurant pas, je me suis libéré un petit créneau pour essayer de vous aider.

 

Je n’ai pas suivi le tuto pour installer acme,sh

Je me suis simplement positionné dans le dossier /usr/local/share/acme.sh

installé acme par curl https://get.acme.sh | sh

 

J’ai ensuite réalisé la création initiale du certificat :

définir la clé l’API key : export GANDI_LIVEDNS_KEY="?????????????"

(pour OVH cela aurait été export OVH_AK="???" et export OVH_AS="???")

lancer la demande de certificat par la commande :

/usr/local/share/acme.sh/acme.sh --issue -d nom_domaine.tld -d *.nom_domaine.tld --dns dns_gandi_livedns -- keylength ec-384 --home /usr/local/share/acme.sh --nocron --force

(pour OVH il aurait fallu -dns dns_ovh)

rajouté les deux enregistrements TXT dans la zone DNS du domaine (infos récupérés dans le message de l’étape précédente)

relancer la demande de certificat par la même commande que précédemment

Les fichiers de certificats créés ont ensuite été injectés par l’interface du syno.

 

Le renouvellement automatique sera réalisé par un script lancé quotidiennement (en root) par le planificateur de tâche.

Le script joint n’est qu’une ébauche et demande à être adapté et finalisé.

Il doit être paramétré avant utilisation (paramétrage en début de script).

Par défaut, il réalise le renouvellement tous les 84 jours.

 

Il relance les packages concernés par ce certificat (et non arrêtés avant le renouvellement).

Cela n’est pas forcément obligatoire et peut être supprimé en commentant la ligne 202 du script.

Ces redémarrages avaient été introduits suite au constat de l’arrêt de certains paquets par UnPixel sur un précédent tuto, ce que je n’ai jamais constaté chez moi.

 

PS commande à renseigner dans le planificateur de tâche :

bash /volume1/script/forum/majcertificat_v04.sh (à adapter selon l’emplacement du script)

ou pour avoir une trace de la dernière exécution :

bash /volume1/script/forum/majcertificat_v04.sh > /volume1/script/forum/certificat/majcertificat.log 2>&1

Enfin on peut ajouter un paramètre( de 0 à 90)) si l’on veut une périodicité de renouvellement différente.

Par exemple pour tester durant une courte période  un renouvellement tous les 2 jours :

bash /volume1/script/forum/majcertificat_v04.sh 2 > /volume1/script/forum/certificat/majcertificat.log 2>&1

 

Bon tests pour ceux qui aiment les risques!

majcertificat_v04.sh

[bruno78]

Bonjour @PPJP,

inutile de préciser que je vais regarder de près ce script. Merci pour ce travail dont je suis bien incapable (et j'ai assez peu de temps libre en ce moment , donc ca traine )

De mon côté, j'étais (je suis encore ... ) bloqué à l'étape de récupération de la liste des packages concernés et actifs, puis à leur redemarrage ... en essayant d'exploiter la sortie de la commande # synoservicecfg --status .... et c'est galère !

[oracle7]

@PPJP

J'ai examiné ton script et ma foi c'est un excellent travail que tu as fais là. Je t'en remercie vivement car mon niveau de connaissances en script Shell ne m'aurait pas permis de coder aussi bien que tu l'as fait.

Pour aller un peu plus loin dans l'automatisation, je te propose une évolution, si tu le veux bien, afin d'ajouter ceci à ton script :

• Dans le cas d'OVH, il serait bien de pouvoir éviter à d'avoir à Copier/Coller les clés OVH_AK et OVH_AS dans le script. En effet, c'est ce C/C qui souvent pose problème car il arrive que certains utilisateurs recopient aussi de façon aveugle, des caractères parasites qui viennent modifier la chaîne et génère des messages d'erreurs. Ce serait donc bien de pouvoir récupérer ces clés automatiquement. Ton avis STP ?
  Pour ton info si besoin en est, ces clés sont sauvegardées dans le fichier "account.conf" situé dans le répertoire "/usr/local/share/acme.sh". Elles sont respectivement inscrites dans ce fichier, lors de la création du certificat par ACME, à l'aide de deux variables d'environnement "SAVED_OVH_AK" et "SAVED_OVH_AS" . Il suffirait (si je puis dire) de les relire pour alimenter l'export des clés que tu fais ensuite en début de script.
  Autre argument, ces clés peuvent changer si l'on recrée pour X raison un autre certificat LE en lançant tout le processus, notamment après un changement d'@MAIL (pour mémoire, cette dernière est utilisée dans le processus de validation interne des clés par OVH).
  Je pense que cela doit être aussi faisable pour d'autres fournisseurs MAIS là en se limitant aux principaux (maxi 3 à 5 par ex), pas tous bien évidemment - à discuter des quels seraient retenus dans la mesure où on dispose aussi des infos correspondantes pour le faire. Là, il faudrait recceuillir du retour d'autres utilisateurs sur ce point. Sinon, on s'en tient à OVH uniquement, puisque le TUTO est basé sur l'utilisation de leurs API. C'est juste qu'il serait dommage à mon sens de ne pas pouvoir étendre la portée du TUTO.

Par ailleurs, je modifierai le TUTO pour recommander d'utiliser le répertoire "Volume1/Scripts" pour y stocker le présent Shell script.

Cordialement

oracle😉

[PPJP]

@bruno78

Le script que j'ai fourni est buggé!

Je viens de m'en apercevoir car j'avais programmé une tâche pour le lancer périodiquement pour test.

Il ne fonctionne pas pour les clé elliptiques. (que j'avais mis en exemple pour le paramétrage du script alors que je n'avais pas testé cette configuration!)

Il ne doit donc être lancé que pour des clé RSA.

Je pense le corriger rapidement, mais les test seront long (j'ai déjà épuisé mon quota pour la semaine et des tests en staging ne me semblent pas suffisants pour valider un script)

Il y a de nombreuses combinaisons à tester (RSA vers RSA, EDSA vers EDSA, RSA vers EDSA, EDSA vers RSA)

Désolé

@oracle7

Il y a 11 heures, oracle7 a dit :

Pour ton info si besoin en est, ces clés sont sauvegardées dans le fichier "account.conf" situé dans le répertoire "/usr/local/share/acme.sh". Elles sont respectivement inscrites dans ce fichier, lors de la création du certificat par ACME, à l'aide de deux variables d'environnement "SAVED_OVH_AK" et "SAVED_OVH_AS" . Il suffirait (si je puis dire) de les relire pour alimenter l'export des clés que tu fais ensuite en début de script.

Pouvez vous me transmettre une copie de ce fichier (expurgé des données personnelles)

Chez moi ce fichier ne mentionne pas de clés.

Il y a 11 heures, oracle7 a dit :

Par ailleurs, je modifierai le TUTO pour recommander d'utiliser le répertoire "Volume1/Scripts" pour y stocker le présent Shell script.

Pourquoi? ce fichier peut être mis n'importe où à partir du moment où c'est un emplacement non concerné par les mise à jour DSM.

Noz vat JC ☺️

[bruno78]

Bonjour @PPJP, @oracle7,

je n'ai pas encore testé le script de @PPJP. Je comprends bien le redémarrage des packages (IsPkg=true) et la distribution des fichiers *.pem du nouveau certificat. Je suis arrivé au même résultat.

Mais si je comprends bien, on ne redémarre pas les services (IsPkg=false) ? Par exemple, pas de redémarrage de smbftpd/ftpd ou de ReverseProxy/a0c1ca98-2ef5-4c98-85c1-xxxxxx ? Dans ces cas là on enregistre bien les nouveaux *.pem, mais pas de redémarrage ?

Merci de votre éclairage avisé

Bruno78

 

[oracle7]

@PPJP

Bonjour,

Il y a 9 heures, PPJP a dit :

Il ne fonctionne pas pour les clé elliptiques.

OK mais c'est très étonnant cela, es-tu certain qu'il n'y a pas autre chose qui fait planté le script ? En toute logique, j'ai du mal à comprendre en quoi un paramétrage de longueur de clé de chiffrement peut impacter ainsi le fonctionnement d'un script. J'ai bon, Oui/Non ?

Il y a 9 heures, PPJP a dit :

Il y a de nombreuses combinaisons à tester (RSA vers RSA, EDSA vers EDSA, RSA vers EDSA, EDSA vers RSA)

Pourquoi, envisager des conversions de clés (RSA vers EDSA, EDSA vers RSA) ? Cela ne me parait pas utile à moins que tu n'ai une bonne raison en magasin. Pour mémoire le choix de la clé de chiffrement est fixée initialement lors de la constitution de la commande de création du certificat. L'utilisateur devrait à mon sens, recréer un certificat s'il souhaite changer la longueur de la clé de chiffrement lorsque la date d'expiration du certificat est atteinte.

Par ailleurs, je aperçois qu'à l'usage, tel que le script est actuellement, il faille allez modifier manuellement le script pour l'adapter au contexte propre de l'utilisateur. Dans mon idée initiale, l'objectif était de faire le plus simple possible pour que le processus soit réalisable par le plus grand nombre.

Aussi, je pense qu'il serait bien que le script ne soit pas modifiable pour éviter ainsi tous problèmes avec des utilisateurs non avertis. En conséquence, il serait nécessaire donc pour cela, qu'il accepte des paramètres supplémentaires qui seraient eux, définis lors de la constitution de la commande à insérer dans le planificateur de tâches et uniquement à ce moment là, et qui permettraient de prendre en compte notamment :

• le domaine de l'utilisateur : "ndd.tld"
• Le type de clé de de chiffrement (i.e. la valeur du paramètre "-- keylenght") : 2048 (défaut), 4096, ec-256, ec-394)
• le nombre de jour pour le renouvellement : mais cela tu l'as déjà pris en compte.

Bien évidemment, avec un contrôle de la présence ou non de ces paramètres qui rejette l'exécution du script si ces derniers sont incorrects et/ou absents, selon.

Désolé de "rallonger la sauce", mais cela me paraît important d'ajouter ces éléments. Enfin, si tu le veux bien 😏

Il y a 10 heures, PPJP a dit :

Chez moi ce fichier ne mentionne pas de clés.

C'est normal car tu n'as pas déroulé le processus de création de la même façon. Avec le Tuto, ces clés sont "exportées" une première fois pour la création du certificat. ACME.sh les inscrit alors temporairement chez OVH pour l'authentification du domaine puis les supprime de chez OVH (voir le log de création que j'ai fourni dans le Tuto). Donc ensuite, pour le renouvellement, ACME.sh a besoin de les retrouver quelque part puisque il n'y a plus  d'enregistrement correspondant chez OVH (dans la zone DNS du domaine), d'où leur sauvegarde dans le fichier "account.conf". Cette façon de procéder, me paraît très sécurisante, pas de clés personnelles chez un tiers !

Comme demandé, je te joins donc le fichier "account.conf" : account.conf expurgé des informations personnelles.

Une dernière question : peut-on purement et simplement remplacer dans le gestionnaire de tâches, l'actuelle commande de renouvellement (celle du Tuto) qui est active dans le gestionnaire de tâches, par celle que tu proposes avec l'usage du script ? N'y-a-t-il pas une manipulation autre à effectuer vis à vis du "cron" pour prendre en compte ce changement ? J'avoue ne pas trop maîtriser ce point.

Encore MERCI à toi de bien vouloir nous aider pour finaliser de processus d'automatisation complet.

@bruno78

Il y a 3 heures, bruno78 a dit :

Mais si je comprends bien, on ne redémarre pas les services (IsPkg=false) ? Par exemple, pas de redémarrage de smbftpd/ftpd ou de ReverseProxy/a0c1ca98-2ef5-4c98-85c1-xxxxxx ? Dans ces cas là on enregistre bien les nouveaux *.pem, mais pas de redémarrage ?

@PPJP m'arrêtera si je dis une bêtise ..., mais n'est-ce pas tout simplement, parce que justement ces services ne sont pas des packages qu'ils n'ont pas besoin d'être redémarrés ?

Cordialement

oracle7😉

 

[bruno78]

Hello,

j'ai aussi par exemple le cas d'AudioStation :

            "display_name" : "AudioStation - audio",
            "isPkg" : false,
            "owner" : "root",
            "service" : "AudioStation",
            "subscriber" : "AppPortal"
         },
         {
            "display_name" : "AudioStation - 45000",
            "isPkg" : false,
            "owner" : "root",
            "service" : "AudioStation_AltPort",
            "subscriber" : "AppPortal"

isPkg est à "false", et pourtant AudioStation est bien un package. Je me demande que faire dans ce cas ....??? redemarrage ?

Je peux tester 1 par un, pour ceux qui sont configurés chez moi, quoi faire (si redemarrage necessaire ou pas), mais je préfèrerai une règle générale, connaitre le principe de la mécanique mise en place. Sinon c'est difficilement généralisable.

[oracle7]

@bruno78

Arrêtes moi si je dis encore une bêtise, mais n'existerait-il pas deux types de packages ?

• Ceux qui sont actifs en permanence parce qu'ils écoutent par ex un ou des ports comme Webdav et auquel cas il faille les redémarrer,
• et ceux qui ne sont actifs que lorsqu'on s'en sert, par ex AudioStation et auquel cas ils n'auraient pas besoin d'être redémarrés systématiquement.

J'essaie comme toi de comprendre le mécanisme, d'où ces suppositions ...

Cordialement

oracle7😉

[bruno78]

@oracle7,

là, c'est au-delà de mes connaissances. je ne peux faire que des suppositions. Et dans le doute, je redémarre tout ce qui touche au certificat .... mais c'est un peu bourrin ! encore des essais à faire (et là tu m'as donné une nouvelle piste à explorer .... 🙂 )

[PPJP]

Il y a 17 heures, bruno78 a dit :

Mais si je comprends bien, on ne redémarre pas les services (IsPkg=false)

Le redémarrage des services n’est pas nécessaire,

Je ne suis même pas certain que ce soit utile pour tous les packages avec (IsPgg = True)

 

Il y a 12 heures, oracle7 a dit :

En toute logique, j'ai du mal à comprendre en quoi un paramétrage de longueur de clé de chiffrement peut impacter ainsi le fonctionnement d'un script.

Tout simplement parce que le dossier où acme met les fichiers du certificat ne porte pas le même nom selon que c’est une clé RSA ou EDSA.

La rajout de quelques lignes de code sera suffisant pour remédier au problème.

Mais je ne pourrai faire de tests que la semaine prochaine (quota LE).

 

Il y a 12 heures, oracle7 a dit :

Pourquoi, envisager des conversions de clés (RSA vers EDSA, EDSA vers RSA) ? Cela ne me parait pas utile à moins que tu n'ai une bonne raison en magasin. Pour mémoire le choix de la clé de chiffrement est fixée initialement lors de la constitution de la commande de création du certificat. L'utilisateur devrait à mon sens, recréer un certificat s'il souhaite changer la longueur de la clé de chiffrement lorsque la date d'expiration du certificat est atteinte.

Si un utilisateur éprouve le besoin de changer de type de clé de chiffrement, n’est-il pas plus simple de changer un paramètre de ce script et de le relancer avec le paramètre 0 que de relancer la création d’un certificat en suivant votre tuto qui est un processus assez lourd (je reconnais ne n’avoir lu qu’en diagonale),

 

Il y a 13 heures, oracle7 a dit :

Aussi, je pense qu'il serait bien que le script ne soit pas modifiable pour éviter ainsi tous problèmes avec des utilisateurs non avertis. En conséquence, il serait nécessaire donc pour cela, qu'il accepte des paramètres supplémentaires qui seraient eux, définis lors de la constitution de la commande à insérer dans le planificateur de tâches et uniquement à ce moment là, et qui permettraient de prendre en compte notamment :

• le domaine de l'utilisateur : "ndd.tld"
• Le type de clé de de chiffrement (i.e. la valeur du paramètre "-- keylenght") : 2048 (défaut), 4096, ec-256, ec-394)
• le nombre de jour pour le renouvellement : mais cela tu l'as déjà pris en compte.

Ce serait faisable,mais il faudrait rajouter d’autres paramètres comme l’API DNS à utiliser.

Et il resterait le problème des clés d’accès à cet API

Elles sont différentes selon les API ( nombre, noms, longueurs …) et ces API sont nombreuses !!

Comme je n’utilise pas acme je n’ai jamais pris le temps de vraiment de détailler son fonctionnement.

Je ne sais pas exactement quelles sont infos que l’on peut trouver dans le fichier account.conf.

Si c’est simple dans le cas d’un certificat unique, qu’en est-il dans le cas de l’existence de plusieurs certificats (chez un ou plusieurs registrars) ?

 

L’objectif d’un script ‘généraliste’ me semble trop ambitieux.

Ce qui me semble envisageable, c’est un script limité à un certificat LE unique dont le DNS est soit chez OVH, soit chez Gandi.

 

Il y a 13 heures, oracle7 a dit :

Une dernière question : peut-on purement et simplement remplacer dans le gestionnaire de tâches, l'actuelle commande de renouvellement (celle du Tuto) qui est active dans le gestionnaire de tâches, par celle que tu proposes avec l'usage du script ? N'y-a-t-il pas une manipulation autre à effectuer vis à vis du "cron" pour prendre en compte ce changement ?

Oui.

Vous pouvez vérifier dans la crontab que vous n'avez pas de lignes correspondantes (je ne pense pas).

Il y a 12 heures, bruno78 a dit :

dans le doute, je redémarre tout ce qui touche au certificat

Il n’est pas utile de redémarrer AudioStation,

Il y a 12 heures, bruno78 a dit :

Et dans le doute, je redémarre tout ce qui touche au certificat .... mais c'est un peu bourrin !

Surtout le temps d’exécution du script va sérieusement augmenter.

PS:

Il y a 13 heures, oracle7 a dit :

Avec le Tuto, ces clés sont "exportées" une première fois pour la création du certificat. ACME.sh les inscrit alors temporairement chez OVH pour l'authentification du domaine puis les supprime de chez OVH (voir le log de création que j'ai fourni dans le Tuto). Donc ensuite, pour le renouvellement, ACME.sh a besoin de les retrouver quelque part puisque il n'y a plus  d'enregistrement correspondant chez OVH (dans la zone DNS du domaine), d'où leur sauvegarde dans le fichier "account.conf"

Ces clés sont uilisées pour permettre l’accès à l’API.

Les valeurs TXT inscrites dans le DNS sont différentes à chaque exécution par LE, ce ne sont pas les clés API .

 

[bruno78]

Merci @PPJP,

je vais donc refaire des tests un peu plus complets ce weekend, en ne redémarrant que les packages (isPkg=True).

Bruno78

[oracle7]

@PPJP

Bonjour,

Il y a 7 heures, PPJP a dit :

 

Il y a 20 heures, oracle7 a dit :

En toute logique, j'ai du mal à comprendre en quoi un paramétrage de longueur de clé de chiffrement peut impacter ainsi le fonctionnement d'un script.

Tout simplement parce que le dossier où acme met les fichiers du certificat ne porte pas le même nom selon que c’est une clé RSA ou EDSA.

OK, il me semblait que le dossier (avec son chemin) où sont générés les fichiers du certificat, était défini avant la première commande de création du certificat, au moyen de l'export de la variable d'environnement 'CERT_HOME' et qu'il était automatiquement nommé avec l'intitulé du domaine concerné par le certificat. Mais effectivement en regardant de plus près le code d'acme.sh, dans le cas d'une clé ECDSA, le suffixe "_ecc" est rajouté au nom définit initialement. Maintenant je comprends mieux ...

Il y a 7 heures, PPJP a dit :

L’objectif d’un script ‘généraliste’ me semble trop ambitieux.

Ce qui me semble envisageable, c’est un script limité à un certificat LE unique dont le DNS est soit chez OVH, soit chez Gandi.

OK, pas de soucis pour revoir à la baisse les ambitions : on s'en tiendra alors à OVH tout cours pour ne pas introduire une quelconque confusion au près des utilisateurs. Et pas de paramètre supplémentaire liée à la clé de chiffrement. L'utilisateur fera son choix dès le départ. S'il veux en changer ensuite, pas la peine de compliquer le processus du Tuto pour cela, je maintiens qu'il n'aura qu'à relancer le processus avec son nouveau paramétrage.

Le seul paramètre sera donc celui que tu as introduit : nombre de jours pour le cycle de renouvellement.

On reste dans la simplicité ...

Il y a 7 heures, PPJP a dit :

Et il resterait le problème des clés d’accès à cet API

Je ne comprends pas non plus pourquoi il y aurait cette nécessité, ces clés d'API une fois générées, sont copiées dans des variables d'environnement qui sont utilisées ensuite par acme.sh pour la création du certificat.

Il y a 7 heures, PPJP a dit :

Les valeurs TXT inscrites dans le DNS sont différentes à chaque exécution par LE, ce ne sont pas les clés API .

OK certes, mais elles ressemblent étonnamment aux clés API que l'on insère manuellement dans des enregistrements TXT lorsqu'on déroule le processus acme.sh dans sa version "simple"/"basique". Voilà le pourquoi de mon interprétation de cette sauvegarde dans le fichier 'account.conf' et de leur utilité présumée. D'autant plus qu'elles portent le même nom au préfixe 'SAVED_' près et que le code d'acme.sh semble les utiliser, mais je peux me tromper...

Cordialement

oracle7😉

[bruno78]

Bonjour,

je viens de refaire un essai. Pour ce qui touche au package WebStation, ça fonctionne bien. 👍. Renouvellement du certificat puis redémarrage du package, et le nouveau certificat est bien pris en compte. Donc OK.

Mais pour le FTPS,

{
            "display_name" : "FTPS",
            "isPkg" : false,
            "owner" : "root",
            "service" : "ftpd",
            "subscriber" : "smbftpd"
         },

le nouveau certificat n'est pas pris en compte (essais sous FileZilla et WinSCP). Il faut donc surement redémarrer un service sur le DSM ??

[oracle7]

@bruno78

Bonjour,

Intuitivement, j'aurais essayé de relancer tout simplement le processus SMB ...

Cordialement

oracle7😉

[bruno78]

bonjour @oracle7,

pour le FTPS, finalement c'est le process ftpd qu'il faut redemarrer via la commande initctl.

root@xxxxxx:/# initctl restart ftpd
ftpd start/running, process 13147
root@dxxxxx:/#

Et du coup le bon certificat est immediatement utilisé pour ce service.

Je vais regarder si et comment ce serait généralisable ....

[bruno78]

Bonsoir,

j'ai donc aujourd'hui généralisé le script de renouvellement. Je ne lance pas réellement le renouvellement (acme.sh), mais je simule le résultat en termes de redémarrage de packages et daemons compte tenu de ma configuration.

A partir du fichier INFO du certificat LE, j'obtiens la liste suivante des packages et daemons à redémarrer :

--- Commandes restart Packages & Service Enable & daemon ---
    ---- cmd [00]  /usr/syno/bin/synopkg restart AudioStation
    ---- cmd [01]  /usr/syno/bin/synopkg restart VPNCenter
    ---- cmd [02]  /usr/syno/bin/synopkg restart SynologyMoments
    ---- cmd [03]  /usr/syno/bin/synopkg restart SynologyDrive
    ---- cmd [04]  /usr/syno/bin/synopkg restart LogCenter
    ---- cmd [05]  /usr/syno/bin/synopkg restart ReplicationService
    ---- cmd [06]  /usr/syno/bin/synopkg restart MailPlus-Server
    ---- cmd [07]  /usr/syno/bin/synopkg restart FileStation
    ---- cmd [08]  /usr/syno/bin/synopkg restart WebStation
    ---- cmd [09]  initctl --restart ftpd

Avant de le lancer en automatique, je teste une à une chaque commande. Et là je m’aperçois des contraintes suivantes :

• le restart de SynologyDrive arrête le package SynologyMoments, mais ne le redémarre pas. Il faut donc penser à redémarrer SynologyMoments après SynologyDrive
• le restart de ReplicationService arrête le package VMM Manager, mais ne le redémarre pas. Il faut donc redémarrer VMM après le redémarrage de ReplicationService
• le restart de MailPlus-Server arrête le package MailPlus, mais ne le redémarre pas. Il faut donc le redémarrer ensuite
• le restart de WebStation arrête les package Apache2.2, Apache2.4 et PhpMyAdmin., mais ne les relance pas. Il faut donc les relancer ensuite.
• (... peut-être d'autres impacts que je n'ai pas vu .... ???)

=> il y a t'il une liste de dépendances des packages qui pourrait être utilisée pour que ces constatations ne soient pas empiriques ? Et être sur que cette liste est complète. Là c'est ce que j'ai pu constater de visu, mais j'ai pu rater quelque chose qui serait moins évident ! Ou alors simplement faire une liste exhaustive des packages enable/running avant le renouvellement, et s'assurer après que tout est de nouveau en service, même si pas explicitement touché par le certificat ?

Par ailleurs, le redémarrage des packages est relativement long. Bien plus long en tout cas que le temps de mise à jour lorsque l'on passe par l'interface graphique du DSM pour affecter un certificat à un service ou un package. Je suis donc à peu prêt certain que DSM ne redémarre pas les packages lors d'une mise à jour de certificat. Que peut'il faire d'autre ... ????

Bruno78

Modifié le 5 juillet 2020 par bruno78