Mic13710

Voilà, c'est fait. Tuto mis à jour pour DSM7

@KreaNum, pour votre information, le regretté unPixel nous a malheureusement quitté fin 2022. Ce tuto a été créé sous DSM6. Certaines commandes syno ont été modifiées avec DSM7, ce qui explique le problème rencontré. Je ferai à l'occasion une mise à jour du tuto pour indiquer la modification.

😉

Très bien ! Petite remarque pour bien continuer, merci d'éviter de citer l'intégralité du post précédent. Non seulement ça n'apporte rien à la compréhension mais ça alourdit la discussion. Le meilleur moyen d'alerter un membre c'est d'utiliser l'@ comme vous l'avez très bien fait. Si le besoin de citation se fait sentir, vous pouvez la faire sur la partie du texte à laquelle vous répondez (sélection du texte dans le message, et clic sur "citer la sélection". Le texte sélectionné viendra s'incruster dans votre message). Bonne continuation.

Bonjour Kreanum, soyez le bienvenu. Le DS120J ne fait pas encore partie des vieux NAS, que je sâche ! 😉 Je vous invite à consulter la section des tutoriels où vous trouverez des informations très utiles voire indispensables sur l'installation et la sécurisation de votre NAS et aussi des tas de tutos pour son exploitation.

Le problème est maintenant résolu. N'hésitez pas à ouvrir un nouveau message en cas de problème. Ceci est une réponse automatique.

@woweu Bonjour, Vous êtes ici sur un forum traitant principalement des NAS Synology. Votre question est trop vague pour pouvoir y répondre correctement et elle n'est pas obligatoirement liée à un univers NAS. Une petite présentation aurez pu nous éclairer sur votre environnement. Merci de préciser votre demande.

Le problème est maintenant résolu. N'hésitez pas à ouvrir un nouveau message en cas de problème. Ceci est une réponse automatique.

Chez Free c'est la règle pour tout le monde et c'est gratuit. Chez l'agrume les ip sont dynamiques pour les particuliers. Il faut passer à la caisse et je crois savoir qu'il faut prendre un forfait pro.pour pouvoir bénéficier d'une IP fixe. A confirmer. Pour les autres opérateurs français, je ne sais pas. Il faut voir ça avec votre FAI.

Le but du chiffrement c'est tout de même de protéger les données. Sans la clé, et sauf à tomber sur un voleur capable de casser un chiffrage AES ou RSA (il ne doit pas y en avoir des foules), il est impossible de lire les données. Par contre, je crois que si votre NAS tombe en panne, le seul moyen serait de remonter les disques dans un autre NAS Synology pour pouvoir déchiffrer et récupérer vos données. A confirmer.

@PiwiLAbruti j'ai bien parlé de nslookup dans mon message 😉

Sauf cas très particulier, pour des questions de sécurité, on évite de transférer les ports http vers le NAS. Je pense qu'il est inutile dans le cas présent de transférer le 80 et le 5000. Le 443 n'est utile que si le reverse proxy et/ou le serveur web sont utilisés sur le NAS. Et si le reverse proxy permet de rejoindre le 5000 ou le 5001 du NAS, il n'est pas utile de transférer le 5001. D'autres ports sont peut-être à rediriger comme par exemple le 6690 si Drive est utilisé, ou bien le 1194 pour open VPN, etc... Bref, tout dépend des services actifs et des paramétrages du NAS.

Dans l'invite de commande windows : tracert <votre nom de domaine> doit en un saut vous donner le temps de traitement, le nom et l'IP du NAS. Si vous avez plus d'un saut dont le premier correspond à l'IP de la box, votre requête transite par la box. Vous pouvez aussi utiliser nslookup <votre nom de domaine> Cette commande doit vous indiquer l'adresse du serveur qui a résolu le ndd. Ce sera l'IP du NAS si le serveur local à fait son travail.

@oracle7 Je n'ai pas suivi rigoureusement le tuto car je travaille sur une seule session docker pour le renouvellement de deux certificats. En conséquence, j'ai déplacé les variables de chaque certificat dans leur ndd.conf respectif, ce qui explique les structures différentes. Tout fonctionne ainsi depuis des mois sans faillir, jusqu'à aujourd'hui. Je ne vais pas épiloguer des heures sur le fonctionnement du script ni comment il récupère et sauvegarde les variables en y ajoutant un SAVED_. Je n'en ai ni l'envie, ni le temps. Je sais simplement que si les variables nécessaires au déploiement sont présentent dans les fichiers conf (account.conf ou ndd.conf) elles sont utilisées pour le déploiement, peu importe au final dans quel conf elles se trouvent. Ce dont je suis sûr maintenant pour l'avoir testé à l'instant sur mon 718 qui vient lui aussi de rater son déploiement, c'est que le problème n'est pas causé par l'emplacement des variables mais bien par le nom du certificat tel qu'il est enregistré en base 64 dans le conf. J'ai tout simplement remplacé la ligne SAVED_SYNO_Certificate='__ACME_BASE64__START_nom du certificat en base 64__ACME_BASE64__END_' par SYNO_Certificate='nom du certificat' Et là le déploiement s'est déroulé comme un charme. Par ailleurs, la ligne SYNO_Certificate est restée inchangée après le déploiement, ce qui est une bonne chose pour le prochain renouvellement. Ce que je ne comprends pas encore c'est que les variables SYNO sont traitées par synology_dsm.sh. Ce script n'a pas été modifié depuis fin septembre or j'ai eu des renouvellements sur plusieurs NAS après cette date qui se sont déroulés sans aucun problème. C'est peut-être lié à la dernière version foireuse de acme.sh mais je n'en suis pas sûr. Pour moi, le souci est temporairement résolu. J'attends de voir si une nouvelle version de l'un ou l'autre script apportera une solution à ce problème de récupération du nom en base 64.

On n'a pas du tout les mêmes fichiers. Le account.conf (en tout cas chez moi) ne contient QUE les clés API. LOG_FILE="/acme.sh/acme.sh.log" LOG_LEVEL=1 AUTO_UPGRADE='1' #NO_TIMESTAMP=1 UPGRADE_HASH='xxxxxxxxxxxxxxxxxxxxxx' USER_PATH='/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin' SAVED_OVH_AK='XXXXXXXXXXXXXXX' SAVED_OVH_AS='XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX' SAVED_OVH_CK='XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX' Je n'ai rien de plus dans ce fichier Il n'y a aucune donnée utile pour le déploiement. Je n'ai donc rien à modifier dans ce fichier. Mais il est vrai que je ne suis pas tout à fait dans la même configuration que le tuto puisque je renouvelle deux certificats OVH d'un même compte client dans la même instance docker avec les mêmes API. Chez moi, toutes les données utiles pour le déploiement se trouvent dans le fichier ndd.conf du dossier nommé ndd. J'ai un dossier par ndd. Vas à la troisième vue de mon intervention ci-dessous pour voir comment est structuré chez moi un de ces fichiers. Et donc, c'est bien dans ces fichiers que se trouvent chez moi les fameux SAVED_ à modifier, pas du tout dans le account.conf. Pas vraiment non. Lors du déploiement, les fameux SAVED_ sont justement exportés et prennent le pas sur les éventuels export qui ont pu être fait précédemment sur ces mêmes valeurs. C'est exactement ce qui s'est produit lorsque j'ai tenté un export des données (vue 4 du même lien ci-dessus). Le nom du certificat n'est pas passé et a été supplanté par celui du ndd.conf en base 64. Et hormis cette histoire de nom de certificat qui ne passait pas, toutes les valeurs contenues dans les SAVED_ ont bien été rapportées dans les logs, preuve qu'il est nul besoin de les exporter. Et si tu reprends mon message précédent, tu verras que je n'ai pas fait d'export de quoi que ce soit. Je n'ai fait que supprimer les SAVED_ et mettre le nom du certificat en clair. Ensuite, un simple : docker exec Acme sh -c "acme.sh --deploy -d 'ndd' --deploy-hook synology_dsm" a exporté les données et déployé le certificat. Je pense au final qu'il y a un problème sur la conversion base 64 du nom du certificat dans la dernière version 3.0.6 d'acme.sh. qui n'affecte bien entendu que ceux qui spécifient un nom !

@Dimebag Darrell, il me semble pourtant vous avoir expliqué l'intérêt d'un serveur local dans un autre post. Et c'est aussi expliqué par Fenrir dans son tuto. Si votre FAI et votre box autorisent le loopback, le serveur DNS est moins utile, bien que dans ce cas, il permet d'éviter de transiter par la box pour des requêtes locales. Mais comme je vous l'ai expliqué, le serveur local ne peut fonctionner que si vous avez accès aux IP des serveurs DNS propagés par le DHCP de votre routeur pour pouvoir y indiquer l'adresse du NAS comme serveur principal. Sans cela, il faudra le faire au niveau des réglages des terminaux ce qui n'est pas très pratique sur des appareils nomades.

@oracle7 @Einsteinium Suite de mon souci de déploiement. Las de ne pas pouvoir déployer mes certificats à cause de ce foutu nom ignoré par le script, et après divers essais, j'ai appliqué la méthode de @oracle7 à savoir supprimer les "SAVED_" des fichiers conf des certificats. J'ai aussi changé le nom du certificat en base 64 pour le nom enregistré dans DSM. Et là, le déploiement s'est déroulé normalement. Mais ce n'est sans doute pas la meilleure approche car toutes les lignes initialement avec "SAVED_" ont été effacées dans les nouveaux fichiers conf des certificats. J'avais pris la précaution d'en faire une copie avant de les modifier, ainsi je les ai restitués dans leur état d'origine, en espérant que le problème sera résolu dans une nouvelle version d'ici le prochain renouvellement. Après réflexion, il eut été préférable que je supprime simplement les lignes des "SAVED_" et refaire les $export des valeurs avant de lancer le déploiement pour qu'elles soient à nouveau retranscrites dans le conf du certificat. C'est ce que je ferai la prochaine fois si le problème se reproduit.

Ca n'existe pas. Ce n'est pas une sauvegarde dans ce cas, c'est une synchro. Une sauvegarde une fois terminée est déconnectée de la source. Synology Drive n'est rien de plus qu'un cloud. Il ne peut pas se substituer à une vraie sauvegarde.

@Dimebag Darrell, merci de ne pas citer inutilement les posts auxquels vous répondez, ça alourdi la discussion sans rien y apporter. L'intérêt d'un serveur DNS interne c'est de pouvoir utiliser la même url quel que soit l'endroit où on se trouve, chez soi ou à l'extérieur. Par exemple, pour rejoindre Audio station du NAS, vous pouvez paramétrer le reverse proxy pour que l'adresse https://audio.ndd soit dirigée vers localhost:leport http d'audio station. A l'extérieur, les serveurs DNS redirigeront votre requête vers votre routeur qui la transmettra au NAS. Chez vous, c'est le serveur DNS local qui résoudra la même url et la dirigera vers le NAS. Mais pour que ça fonctionne, il faut impérativement que vous puissiez modifier les adresses des serveurs DNS propagées en DHCP par le routeur. Malheureusement certains routeurs n'acceptent pas ces modifications (orange entre autres). Je vous invite à voir le tuto de mise en place du serveur DNS dans la partie tutoriels.

@Dimebag Darrell le reverse proxy ne fait que le relais entre un ndd et une application. Il n'est pas lié uniquement aux accès externes. Si vous avez un serveur DNS privé (celui du NAS par exemple), il pourra faire le même exercice avec les mêmes ndd une fois résolus par le serveur DNS.

Est-ce que tu as plusieurs certificats, et si oui, est-ce que le nom du certificat a été pris en compte par le script comme ceci : SYNO_Certificate='ici le nom du certificat'

@oracle7 je n'ai aucun problème avec mes fichiers account.conf et ndd.conf, et jusqu'à la dernière version de acme.sh, tout fonctionnait parfaitement depuis des mois avec plusieurs renouvellements et déploiements. Je pense que nous avons tous les deux la toute dernière version d'acme.sh (3.0.6 deuxième jus). Malheureusement (pour moi) le renouvellement a été fait avec la première version 3.0.6 et peut-être un mécanisme a été cassé qui ne se voit pas dans les .conf. @Kramlech c'est en faite le même problème de renouvellement apparu avec la dernière version d'acme.sh. Sauf que toi, tu es reparti en cours de route sur une nouvelle install et que ça ne se passe pas correctement. Pour répondre à ton souci de clés : oui, tu peux très bien en créer de nouvelles mais si tu es sûr des anciennes et qu'elles sont toujours valides, ce n'est pas nécessaire. Tu peux vérifier ça dans la console de ton compte ovh. https://api.ovh.com/console/

@oracle7 toutes les données ont été créées avec des export exactement comme dans le github et dans le tuto. Les SAVED dans les fichiers ndd.conf et account.conf sont créés par le script. Je n'ai rien touché dans ces fichiers. Et si tu regardes le tuto, il y a bien des SAVED pour toutes les données exportées par les .conf. De même que le codage en base 64 du nom du certificat qui a été introduit par le script il y a quelques mois de ça. Là aussi je n'ai rien fait d'autre lors du premier déploiement que d'exporter en clair le nom donné dans DSM. Le script a fait le reste. Regardes la ligne SAVED_SYNO_Certificate dans mon ndd.conf, le nom en base 64 est borné __ACME_BASE64. Ce n'est pas de ma propre initiative. D'ailleurs, si tu regardes le fil de discussion du tuto, à un moment j'ai signalé ce changement du nom en dur en base 64. Et pour compléter, la conversion du texte base64 me donne bien le nom du certificat que je souhaite déployer. Lors du déploiement manuel que j'ai tenté aujourd'hui (voir ci-dessus), j'ai bien indiqué le nom du certificat en clair, mais acme.sh ne l'a pas pris en compte. Je viens d'ouvrir un sujet sur github pour ce problème.

@oracle7 merci pour cette info. J'ai ajouter le syno-create mais ce n'est pas ça. Le problème vient de la non prise en compte du nom du certificat. @Einsteinium j'ai trouvé d'où vient le problème. Le déploiement ne se fait pas car le script n'a pas pris en compte le nom du certificat. Pour le déploiement en décembre de l'un des certificats le nom est pris en compte (ligne 3) et le déploiement se fait bien : [Sun Dec 4 00:08:53 UTC 2022] _deployApi='/root/.acme.sh/deploy/synology_dsm.sh' [Sun Dec 4 00:08:53 UTC 2022] _cdomain='ndd.net' [Sun Dec 4 00:08:53 UTC 2022] SYNO_Certificate='Wildcard ndd.net' [Sun Dec 4 00:08:53 UTC 2022] _base_url='http://172.17.0.1:5000' [Sun Dec 4 00:08:53 UTC 2022] Getting API version [Sun Dec 4 00:08:53 UTC 2022] GET [Sun Dec 4 00:08:53 UTC 2022] url='http://172.17.0.1:5000/webapi/query.cgi?api=SYNO.API.Info&version=1&method=query&query=SYNO.API.Auth' [Sun Dec 4 00:08:53 UTC 2022] timeout= [Sun Dec 4 00:08:53 UTC 2022] _CURL='curl --silent --dump-header /acme.sh/http.header -L -g ' [Sun Dec 4 00:08:54 UTC 2022] ret='0' [Sun Dec 4 00:08:54 UTC 2022] Logging into 172.17.0.1:5000 [Sun Dec 4 00:08:54 UTC 2022] POST [Sun Dec 4 00:08:54 UTC 2022] _post_url='http://172.17.0.1:5000/webapi/auth.cgi?enable_syno_token=yes' [Sun Dec 4 00:08:54 UTC 2022] _CURL='curl --silent --dump-header /acme.sh/http.header -L -g ' [Sun Dec 4 00:08:55 UTC 2022] _ret='0' [Sun Dec 4 00:08:55 UTC 2022] token='NFYYbsmbPYtng' [Sun Dec 4 00:08:56 UTC 2022] Getting certificates in Synology DSM [Sun Dec 4 00:08:56 UTC 2022] POST [Sun Dec 4 00:08:56 UTC 2022] _post_url='http://172.17.0.1:5000/webapi/entry.cgi' [Sun Dec 4 00:08:56 UTC 2022] _CURL='curl --silent --dump-header /acme.sh/http.header -L -g ' [Sun Dec 4 00:08:56 UTC 2022] _ret='0' [Sun Dec 4 00:08:56 UTC 2022] escaped_certificate='Wildcard ndd\.net' [Sun Dec 4 00:08:56 UTC 2022] Generate form POST request [Sun Dec 4 00:08:56 UTC 2022] Upload certificate to the Synology DSM [Sun Dec 4 00:08:56 UTC 2022] POST [Sun Dec 4 00:08:56 UTC 2022] _post_url='http://172.17.0.1:5000/webapi/entry.cgi?api=SYNO.Core.Certificate&method=import&version=1&SynoToken=NFYYbsmbPYtng&_sid=JZY_iOUr1T19dcU5UOBsSeQFvHy94qua4IN_UVasNCwpnF9g-d1JPES5RNU9JhZgnZUtEULoix5WhifQ0pc2BU' [Sun Dec 4 00:08:56 UTC 2022] _CURL='curl --silent --dump-header /acme.sh/http.header -L -g ' [Sun Dec 4 00:09:44 UTC 2022] _ret='0' [Sun Dec 4 00:09:44 UTC 2022] http services were NOT restarted [Sun Dec 4 00:09:44 UTC 2022] Success Pour celui du 2 janvier, le nom n'est pas pris en compte (ligne 3) ce qui empêche le déploiement : [Thu Feb 2 00:04:42 UTC 2023] _deployApi='/root/.acme.sh/deploy/synology_dsm.sh' [Thu Feb 2 00:04:42 UTC 2023] _cdomain='ndd.net' [Thu Feb 2 00:04:42 UTC 2023] SYNO_Certificate [Thu Feb 2 00:04:42 UTC 2023] _base_url='http://172.17.0.1:5000' [Thu Feb 2 00:04:42 UTC 2023] Getting API version [Thu Feb 2 00:04:42 UTC 2023] GET [Thu Feb 2 00:04:42 UTC 2023] url='http://172.17.0.1:5000/webapi/query.cgi?api=SYNO.API.Info&version=1&method=query&query=SYNO.API.Auth' [Thu Feb 2 00:04:42 UTC 2023] timeout= [Thu Feb 2 00:04:42 UTC 2023] _CURL='curl --silent --dump-header /acme.sh/http.header -L -g ' [Thu Feb 2 00:04:42 UTC 2023] ret='0' [Thu Feb 2 00:04:42 UTC 2023] Logging into 172.17.0.1:5000 [Thu Feb 2 00:04:42 UTC 2023] POST [Thu Feb 2 00:04:42 UTC 2023] _post_url='http://172.17.0.1:5000/webapi/auth.cgi?enable_syno_token=yes' [Thu Feb 2 00:04:42 UTC 2023] _CURL='curl --silent --dump-header /acme.sh/http.header -L -g ' [Thu Feb 2 00:04:44 UTC 2023] _ret='0' [Thu Feb 2 00:04:44 UTC 2023] token='RabpfZzxqvW0Q' [Thu Feb 2 00:04:44 UTC 2023] Getting certificates in Synology DSM [Thu Feb 2 00:04:44 UTC 2023] POST [Thu Feb 2 00:04:44 UTC 2023] _post_url='http://172.17.0.1:5000/webapi/entry.cgi' [Thu Feb 2 00:04:44 UTC 2023] _CURL='curl --silent --dump-header /acme.sh/http.header -L -g ' [Thu Feb 2 00:04:44 UTC 2023] _ret='0' [Thu Feb 2 00:04:44 UTC 2023] escaped_certificate [Thu Feb 2 00:04:44 UTC 2023] Unable to find certificate: and $SYNO_Create is not set [Thu Feb 2 00:04:44 UTC 2023] Error deploy for domain:ndd.net [Thu Feb 2 00:04:44 UTC 2023] Deploy error. [Thu Feb 2 00:04:44 UTC 2023] Return code: 1 [Thu Feb 2 00:04:44 UTC 2023] Error renew ndd.net. Il n'y a pas de problème dans le fichier ndd.net.conf dans le dossier ndd.net où le nom du certificat est bien indiqué en base64 : Le_Domain='ndd.net' Le_Alt='serv1.ndd.net,*.serv1.ndd.net' Le_Webroot='dns_ovh' Le_PreHook='' Le_PostHook='' Le_RenewHook='' Le_API='https://acme-v02.api.letsencrypt.org/directory' Le_Keylength='4096' Le_OrderFinalize='https://acme-v02.api.letsencrypt.org/acme/finalize/xxxxxxxxxxxxx' Le_LinkOrder='https://acme-v02.api.letsencrypt.org/acme/order/xxxxxxxxxxxxxxxx' Le_LinkCert='https://acme-v02.api.letsencrypt.org/acme/cert/xxxxxxxxxxxxxxxxxxxxxxxxxx' Le_CertCreateTime='1675296385' Le_CertCreateTimeStr='2023-02-02T00:06:25Z' Le_NextRenewTimeStr='2023-04-02T00:06:25Z' Le_NextRenewTime='1680393985' Le_DeployHook='synology_dsm,' SAVED_SYNO_Scheme='http' SAVED_SYNO_Hostname='172.17.0.1' SAVED_SYNO_Port='5000' SAVED_SYNO_Username='user' SAVED_SYNO_Password='password' SAVED_SYNO_DID='' SAVED_SYNO_Certificate='__ACME_BASE64__START_nom du certificat en base 64__ACME_BASE64__END_' SAVED_SYNO_TOTP_SECRET='' J'ai tenté un déploiement manuel avec une tâche planifiée : $ export SYNO_Username='user' $ export SYNO_Password='password' $ export SYNO_Certificate="le nom de mon certificat" docker exec Acme sh -c "acme.sh --deploy -d 'ndd.net' --deploy-hook synology_dsm" Et là aussi le nom du certificat n'est pas pris en compte (ligne 3) : [Thu Feb 2 00:04:42 UTC 2023] _deployApi='/root/.acme.sh/deploy/synology_dsm.sh' [Thu Feb 2 00:04:42 UTC 2023] _cdomain='ndd.net' [Thu Feb 2 00:04:42 UTC 2023] SYNO_Certificate [Thu Feb 2 00:04:42 UTC 2023] _base_url='http://172.17.0.1:5000' [Thu Feb 2 00:04:42 UTC 2023] Getting API version [Thu Feb 2 00:04:42 UTC 2023] GET [Thu Feb 2 00:04:42 UTC 2023] url='http://172.17.0.1:5000/webapi/query.cgi?api=SYNO.API.Info&version=1&method=query&query=SYNO.API.Auth' [Thu Feb 2 00:04:42 UTC 2023] timeout= [Thu Feb 2 00:04:42 UTC 2023] _CURL='curl --silent --dump-header /acme.sh/http.header -L -g ' [Thu Feb 2 00:04:42 UTC 2023] ret='0' [Thu Feb 2 00:04:42 UTC 2023] Logging into 172.17.0.1:5000 [Thu Feb 2 00:04:42 UTC 2023] POST [Thu Feb 2 00:04:42 UTC 2023] _post_url='http://172.17.0.1:5000/webapi/auth.cgi?enable_syno_token=yes' [Thu Feb 2 00:04:42 UTC 2023] _CURL='curl --silent --dump-header /acme.sh/http.header -L -g ' [Thu Feb 2 00:04:44 UTC 2023] _ret='0' [Thu Feb 2 00:04:44 UTC 2023] token='RabpfZzxqvW0Q' [Thu Feb 2 00:04:44 UTC 2023] Getting certificates in Synology DSM [Thu Feb 2 00:04:44 UTC 2023] POST [Thu Feb 2 00:04:44 UTC 2023] _post_url='http://172.17.0.1:5000/webapi/entry.cgi' [Thu Feb 2 00:04:44 UTC 2023] _CURL='curl --silent --dump-header /acme.sh/http.header -L -g ' [Thu Feb 2 00:04:44 UTC 2023] _ret='0' [Thu Feb 2 00:04:44 UTC 2023] escaped_certificate [Thu Feb 2 00:04:44 UTC 2023] Unable to find certificate: and $SYNO_Create is not set [Thu Feb 2 00:04:44 UTC 2023] Error deploy for domain:ndd.net [Thu Feb 2 00:04:44 UTC 2023] Deploy error. [Thu Feb 2 00:04:44 UTC 2023] Return code: 1 [Thu Feb 2 00:04:44 UTC 2023] Error renew ndd.net. Bref, il semblerait qu'il y ait aussi un problème au niveau du script de déploiement. Edit : Je réalise que le renouvellement du 2 février a été fait avec la première version 3.0.6 de acme.sh (celle qui a posé des problèmes à certains lors des récents renouvellements). Sa mise à jour automatique a été faite le 5 février sur ce NAS mais malgré cela, le déploiement ne se fait pas.

@Einsteinium, je viens de m’apercevoir que sur un des NAS dont je m'occupe, les deux certificats sur 2 ndd chez OVH ont bien été renouvelés automatiquement le 2 février avec pour chacun : [Thu Feb 2 00:06:25 UTC 2023] Cert success. [Thu Feb 2 00:06:25 UTC 2023] Your cert is in: /acme.sh/ndd.net/ndd.net.cer [Thu Feb 2 00:06:25 UTC 2023] Your cert key is in: /acme.sh/ndd.net/ndd.net.key [Thu Feb 2 00:06:25 UTC 2023] The intermediate CA cert is in: /acme.sh/ndd.net/ca.cer [Thu Feb 2 00:06:25 UTC 2023] And the full chain certs is there: /acme.sh/ndd.net/fullchain.cer [Thu Feb 2 00:06:25 UTC 2023] _on_issue_success mais n'ont pas été déployés avec pour tous les deux : [Thu Feb 2 00:06:26 UTC 2023] Unable to find certificate: and $SYNO_Create is not set [Thu Feb 2 00:06:26 UTC 2023] Error deploy for domain:ndd.net [Thu Feb 2 00:06:26 UTC 2023] Deploy error. Voila qu'il n'arrive plus à trouver un certificat qu'il vient d'enregistrer !