Certificat Let's Encrypt avec acme.sh & api Ovh en Docker - Problème de renouvellement avec acme.sh

[Kramlech]

Bonjour à tous

Je me permet de créer un nouveau sujet lié à l'excellent tutoriel de @Einsteinium car depuis quelques temps, il semble y avoir un problème de renouvellement.

Je préfère dissocier ce problème du sujet principal, car dans le sujet d'origine, il y a déjà 23 pages de messages principalement liés à l'implémentation de la solution, et il est difficile de retrouver ce qui concerne ce problème bien précis. J'ai aussi constaté que ce problème est apparu dans le tutoriel de @oracle7 qui est l'équivalent de celui de Einsteinum, mais sans Docker (sujet qui fait 37 pages !!! et dans lequel il est tout aussi difficile de retrouver ses petits !!!).

Donc, voici un résumé du problème tel que je le constate :

• J'ai installé ce principe de renouvellement du certificat via Docker fin 2020
• Tout fonctionnait bien jusqu'en décembre 2022, date de mon dernier renouvellement de certificat.
• Il y a quelques jours, j'ai reçu un mail de Let's Encrypt qui m'indiquait que mon certificat allait expirer.
• Et là, c'est le drame .... 😪

En effet, recevoir ce mail signifie que le renouvellement ne s'est pas fait. Car théoriquement la procédure renouvelle le certificat tous les deux mois, c'est à dire avant que Let's Encrypt n'envoie les mails.

Une petite recherche dans les logs m'a permis de constater que, depuis début février c'est à dire la date a laquelle le certificat devrait être renouvelé, j'avais systématiquement le message d'erreur :

[Sun Feb 12 00:10:06 UTC 2023] error {"message":"This credential is not valid","httpCode":"403 Forbidden","errorCode":"INVALID_CREDENTIAL"}

[Sun Feb 12 00:10:06 UTC 2023] The consumer key is invalid: xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

Dans les conversations existantes au niveau des tutoriel, @Diplo95 a évoqué cette erreur, mais la discussion a vite dérivée sur d'autres problèmes.

A lire le fil des discutions, il semblerait que le problème vienne de la version 3.0.6 de acme.sh. Mais je n'ai pas trouvé la confirmation que de revenir à la version 3.0.5 résolve le problème. Est-ce que quelqu'un peut confirmer ou infirmer cette piste ?

Merci à tous pour votre aide.

[Einsteinium]

Bonjour,

De ce que je vois, c’est un problème de jeton d’accès ovh.

j’ai pas été voir les dates de publication des versions, mais mon dernier update avec succès date du 8 février pour information.

Je viens d’aller voir github… je me rappel qu’il y avait un problème avec watchtower sur les update de cette image, donc j’avais stoppé une semaine le stack… Le 4 février j’ai relancé le stack… donc en fessant cela… même si j’étais en 3.0.6, je suis repassé directement en 3.0.5 😉

Donc si tu l’as pas compris, supprime et refais le docker 😉 

Tu ne perd rien de tes configs 😉

[oracle7]

@Einsteinium

Bonjour,

Pour comprendre, car chez moi j'ai eu une mise à jour de l'image acme le 5/2/2023 :

et re-création auto du conteneur Acme :

et pourtant je suis toujours en v3.0.6 :

Au final, mon renouvellement est prévu pour le 22/2, je verrai bien à ce moment là de quoi il retourne ...

Par ailleurs, je n'ai pas vu sur Github d'issues publiées concernant ce problème de "consumer key invalid".

Cordialement

oracle7😉

[Kramlech]

@Einsteinium Après suppression du docker, et recréation via Portainer, je suis toujours en version 3.0.6 :

root@DS716:~# docker exec Acme acme.sh --version
https://github.com/acmesh-official/acme.sh
v3.0.6

 

[Einsteinium]

@Kramlech @oracle7 J’ai été voir directement en manuel, effectivement version 3.0.6, après il est vrai que acme ce met à jour indépendamment du docker, donc c’est que le problème ne vient pas de la version, ayant eu mon update il y a 4 jours sans soucis.

[Mic13710]

@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 !

[oracle7]

@Mic13710

Bonjour,

En 12/2022, j'ai eu aussi cette erreur de déploiement. J'ai exporté la variable d'environnement $SYNO_Create= 1 et relancer manuellement le déploiement. Tout c'est bien passé. J'ai donc ajouté cette variable dans mon fichier account.conf.

Ensuite, j'ai (pour d'autres raisons) réinstallé le conteneur acme et regénéré un certificat. Tout s'est bien passé y compris le déploiement mais c'était en v3.0.5.

A voir maintenant lors du renouvellement à venir dans quelques jours. Je croise les doigts avec cette v3.0.6 ...🤞🤔

Cordialement

oracle7😉

[Mic13710]

@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.

[Kramlech]

Voici les dernières nouvelles :

• Hier, j'ai donc supprimé le docker puis je l'ai recréé
• Cette nuit la procédure de mise à jour s'est lancée
• Et voila le résultat :

[Mon Feb 13 00:10:06 UTC 2023] validationUrl='https://www.ovh.com/auth/sso/api?credentialToken=60bd72c3c6f0924d6d6b82cf804579bb43cf137c18b0062cb045205d6140f247'
[Mon Feb 13 00:10:06 UTC 2023] consumerKey='[hidden](please add '--output-insecure' to see this value)'
[Mon Feb 13 00:10:06 UTC 2023] Please open this link to do authentication: https://www.ovh.com/auth/sso/api?credentialToken=60bd72c3c6f0924d6d6b82cf804579bb43cf137c18b0062cb045205d6140f247
[Mon Feb 13 00:10:06 UTC 2023] Here is a guide for you: https://github.com/acmesh-official/acme.sh/wiki/How-to-use-OVH-domain-api
[Mon Feb 13 00:10:06 UTC 2023] Please retry after the authentication is done.
[Mon Feb 13 00:10:06 UTC 2023] Error add txt for domain:_acme-challenge.xxxx.fr
[Mon Feb 13 00:10:06 UTC 2023] _on_issue_err

Donc en fait, il ne fait même pas le deployement...

Ce qui me parait bizarre, c'est que si je teste les URLs qu'il donne dans le message, j'arrive systématiquement sur un écran d'identification de OVH. Or comme jamais je ne donne mes identifiants OVH, c'est normal que ça plante ...

De plus, à la fin de la log, j'ai ça :

[Mon Feb 13 00:10:07 UTC 2023] Return code: 1
[Mon Feb 13 00:10:07 UTC 2023] Error renew xxxx.fr.
[Mon Feb 13 00:10:07 UTC 2023] di='/acme.sh/mydomain.com/'
[Mon Feb 13 00:10:07 UTC 2023] d='mydomain.com'
[Mon Feb 13 00:10:07 UTC 2023] _renewServer
[Mon Feb 13 00:10:07 UTC 2023] Using config home:/acme.sh
[Mon Feb 13 00:10:07 UTC 2023] ACME_DIRECTORY='https://acme-v02.api.letsencrypt.org/directory'
[Mon Feb 13 00:10:07 UTC 2023] DOMAIN_PATH='/acme.sh/mydomain.com'
[Mon Feb 13 00:10:07 UTC 2023] Renew: 'mydomain.com'
[Mon Feb 13 00:10:07 UTC 2023] Le_API='https://acme-v02.api.letsencrypt.org/directory'
[Mon Feb 13 00:10:07 UTC 2023] Renew to Le_API=https://acme-v02.api.letsencrypt.org/directory
[Mon Feb 13 00:10:07 UTC 2023] Using config home:/acme.sh
[Mon Feb 13 00:10:07 UTC 2023] ACME_DIRECTORY='https://acme-v02.api.letsencrypt.org/directory'
[Mon Feb 13 00:10:07 UTC 2023] Skip invalid cert for: mydomain.com
[Mon Feb 13 00:10:07 UTC 2023] Return code: 2
[Mon Feb 13 00:10:07 UTC 2023] Skipped mydomain.com
[Mon Feb 13 00:10:07 UTC 2023] _error_level='1'
[Mon Feb 13 00:10:07 UTC 2023] _set_level='2'
[Mon Feb 13 00:10:07 UTC 2023] The NOTIFY_HOOK is empty, just return.
[Mon Feb 13 00:10:07 UTC 2023] ===End cron===

Il semble vouloir faire un renew sur "mydomain.com" !!! C'est quoi ça ?

Il y a aussi un point qui m'intrique : la procédure se lance toutes les nuits à minuit, mais je n'ai rien dans mon planificateur de taches qui gère ça...

Je crois que je vais tout supprimer et tout recommencer depuis le début....Ca ne pose pas de problème de créer un nouvelle clé d'API ?

[oracle7]

@Mic13710

Bonjour,

Il y a un truc qui m'interpelle dans ton fichier account.conf.

Certes, tu est conformes au TUTO mais quand on regarde sur le github, les variables d'environnement exportées pour le déploiement (voir https://github.com/acmesh-official/acme.sh/wiki/deployhooks#20-deploy-the-cert-into-synology-dsm et https://github.com/acmesh-official/acme.sh/wiki/Synology-NAS-Guide), aucune n'est préfixée avec la chaine 'SAVED_' . Je cite :

Citation

# export SYNO_Scheme="http" # Can be set to HTTPS, defaults to HTTP
# export SYNO_Hostname="localhost" # Specify if not using on localhost
# export SYNO_Port="5000" # Port of DSM WebUI, defaults to 5000 for HTTP and 5001 for HTTPS
export SYNO_Username="DSM_Admin_Username"
export SYNO_Password="DSM_Admin_Password"
export SYNO_Certificate="acme.sh certificate" # Description text in Control Panel -> Security -> Certificates
export SYNO_Create=1 # defaults to off, this setting is not saved.  By setting to 1 we create the certificate if it's not in DSM
acme.sh --deploy -d example.com --deploy-hook synology_dsm

ET

Citation

$ cd /usr/local/share/acme.sh
# Single quotes prevents some escaping issues if your password or username contains certain special characters
$ export SYNO_Username='Admin_Username'
$ export SYNO_Password='Admin_Password!123'
# export SYNO_Hostname="localhost" # Specify if not using on localhost
$ export SYNO_Scheme="https"
$ export SYNO_Port="5001"
# You must specify SYNO_Certificate, for the default certificate, we use an empty string
# Please be aware that the empty string only works if you haven't added/changed the description for
# the default certificate. If you have, you'll need to specify the description here.
$ export SYNO_Certificate=""
$ ./acme.sh --deploy --insecure --home . -d "$CERT_DOMAIN" --deploy-hook synology_dsm

Chez moi, elles ne le sont pas (jamais été d'ailleurs) et je n'ai aucun soucis avec ceci :

Citation

SYNO_Create=1
SYNO_Scheme='http'
SYNO_Hostname='172.18.0.1'
SYNO_Port='5000'
SYNO_Username='User_admin_DSM'
SYNO_Password='password'
SYNO_DID=''
SYNO_Certificate='Certif_Acme_LE_Docker'

OK, tu vas me dire "mais cela a déjà marché avec" mais je dirais que pour moi ce n'est pas le fonctionnement normal. D'où des comportements erratiques ...

Autre question : pourquoi utiliser une description de certificat codée base 64 ?

SAVED_SYNO_Certificate='__ACME_BASE64__START_nom du certificat en base 64__ACME_BASE64__END_'

Sauf erreur de ma part, il me semblait bien que cette description était du simple texte tel que le dit le guide de déploiement :

export SYNO_Certificate="acme.sh certificate" # Description text in Control Panel -> Security -> Certificates

Du coup, je serais tenté de dire que le script acme.sh n'interprète pas (ou mal) ce texte quand il est codé base64 et donc ne reconnait pas le domaine associé correspondant, ce qui pourrait expliquer alors sa non prise en compte. Voilà ce n'est que mon interprétation et je peux me tromper ...

@Kramlech

il y a une heure, Kramlech a dit :

Il semble vouloir faire un renew sur "mydomain.com" !!! C'est quoi ça ?

Il y a aussi un point qui m'intrique : la procédure se lance toutes les nuits à minuit, mais je n'ai rien dans mon planificateur de taches qui gère ça...

C'est le cron interne à acme.sh qui est lancé toutes les nuits à la même heure. Regardes bien tes logs, tu verras la répétition journalière. Pour moi, après avoir (si besoin) mis à jour le script, il teste simplement via la procédure renew si la date d'échéance du renouvellement est atteinte et si oui il enchaine sur le renouvellement sinon il sort. par exemple :

Citation

[Mon Feb 13 00:10:01 UTC 2023] Running cmd: cron
[Mon Feb 13 00:10:01 UTC 2023] Using config home:/acme.sh
[Mon Feb 13 00:10:01 UTC 2023] default_acme_server='https://acme-v02.api.letsencrypt.org/directory'
[Mon Feb 13 00:10:01 UTC 2023] ACME_DIRECTORY='https://acme-v02.api.letsencrypt.org/directory'
[Mon Feb 13 00:10:01 UTC 2023] ===Starting cron===
[Mon Feb 13 00:10:01 UTC 2023] Using config home:/acme.sh
[Mon Feb 13 00:10:01 UTC 2023] ACME_DIRECTORY='https://acme-v02.api.letsencrypt.org/directory'
[Mon Feb 13 00:10:01 UTC 2023] GET
[Mon Feb 13 00:10:01 UTC 2023] url='https://api.github.com/repos/acmesh-official/acme.sh/git/refs/heads/master'
[Mon Feb 13 00:10:01 UTC 2023] timeout=
[Mon Feb 13 00:10:01 UTC 2023] _CURL='curl --silent --dump-header /acme.sh/http.header  -L  -g '
[Mon Feb 13 00:10:01 UTC 2023] ret='0'
[Mon Feb 13 00:10:01 UTC 2023] Already uptodate!
[Mon Feb 13 00:10:01 UTC 2023] Upgrade success!
[Mon Feb 13 00:10:01 UTC 2023] Using config home:/acme.sh
[Mon Feb 13 00:10:01 UTC 2023] ACME_DIRECTORY='https://acme-v02.api.letsencrypt.org/directory'
[Mon Feb 13 00:10:01 UTC 2023] Auto upgraded to: 3.0.6
[Mon Feb 13 00:10:01 UTC 2023] Using config home:/acme.sh
[Mon Feb 13 00:10:01 UTC 2023] ACME_DIRECTORY='https://acme-v02.api.letsencrypt.org/directory'
[Mon Feb 13 00:10:01 UTC 2023] _stopRenewOnError
[Mon Feb 13 00:10:01 UTC 2023] _server
[Mon Feb 13 00:10:01 UTC 2023] _set_level='2'
[Mon Feb 13 00:10:01 UTC 2023] di='/acme.sh/ndd.tld/'
[Mon Feb 13 00:10:01 UTC 2023] d='ndd.tld'
[Mon Feb 13 00:10:01 UTC 2023] _renewServer
[Mon Feb 13 00:10:01 UTC 2023] Using config home:/acme.sh
[Mon Feb 13 00:10:01 UTC 2023] ACME_DIRECTORY='https://acme-v02.api.letsencrypt.org/directory'
[Mon Feb 13 00:10:01 UTC 2023] DOMAIN_PATH='/acme.sh/ndd.tld'
[Mon Feb 13 00:10:01 UTC 2023] Renew: 'ndd.tld'
[Mon Feb 13 00:10:01 UTC 2023] Le_API='https://acme-v02.api.letsencrypt.org/directory'
[Mon Feb 13 00:10:01 UTC 2023] Renew to Le_API=https://acme-v02.api.letsencrypt.org/directory
[Mon Feb 13 00:10:01 UTC 2023] Using config home:/acme.sh
[Mon Feb 13 00:10:01 UTC 2023] ACME_DIRECTORY='https://acme-v02.api.letsencrypt.org/directory'
[Mon Feb 13 00:10:01 UTC 2023] Skip, Next renewal time is: 2023-02-22T00:58:12Z
[Mon Feb 13 00:10:01 UTC 2023] Add '--force' to force to renew.
[Mon Feb 13 00:10:01 UTC 2023] Return code: 2
[Mon Feb 13 00:10:01 UTC 2023] Skipped ndd.tld
[Mon Feb 13 00:10:01 UTC 2023] _error_level='3'
[Mon Feb 13 00:10:01 UTC 2023] _set_level='2'
[Mon Feb 13 00:10:01 UTC 2023] ===End cron===

 

Cordialement

oracle7😉

 

[Mic13710]

@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]

@Mic13710

Bonjour,

Je ne met pas en doute ce que tu dis et te crois bien volontier mais j'aimerai bien alors comprendre pourquoi je n'ai JAMAIS eu/constaté chez moi le comportement du script acme.sh que tu décris pour le fichier account.conf. Bizarre, bizarre plus que bizarre ... Toutefois, après vérification du fichier ndd.tld.conf (je ne pensais plus à celui-là !), effectivement les variables y sont préfixées avec "SAVED_" et le SYNO_Certificate y est aussi codé base64.

PAr ailleurs, moi aussi j'ai suivi le présent TUTO sous docker mais à la seule différence que je suis parti directement avec un fichier docker-compose plutot que la tâche programmée et que j'ai repris mes clés OVH existantes ainsi que le fichier account.conf (variables non préfixées) que j'utilisais précédemment avec la méthode de mon TUTO. Ni plus ni moins.

Cordialement

oracle7😉

 

[Kramlech]

Ok pour votre discussion, mais elle est sans rapport avec mon problème, non ?

Il y a 5 heures, Kramlech a dit :

Donc en fait, il ne fait même pas le déploiement...

Ce qui me parait bizarre, c'est que si je teste les URLs qu'il donne dans le message, j'arrive systématiquement sur un écran d'identification de OVH. Or comme jamais je ne donne mes identifiants OVH, c'est normal que ça plante ...

 

Il y a 5 heures, Kramlech a dit :

Il semble vouloir faire un renew sur "mydomain.com" !!! C'est quoi ça ?

 

[Mic13710]

@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/

[Kramlech]

Dernières nouvelles :

• J'ai créé de nouvelles clés API
• J'ai modifié les clés dans le fichier account.conf
• Mais j'ai oublié de sauvegarder le fichier !!!!!
• J'ai lancé la génération des certificats en ligne de commande comme indiqué dans le tuto (donc toujours avec les anciennes clés)
• ... et là tout a fonctionné : les certificats ont été crées ...

root@DS716:~# docker exec Acme sh -c "acme.sh --issue --keylength 4096 -d 'xxxx.fr' -d '*.xxxx.fr' --dns dns_ovh"
[Mon Feb 13 17:22:32 UTC 2023] Using CA: https://acme-v02.api.letsencrypt.org/directory
[Mon Feb 13 17:22:32 UTC 2023] Multi domain='DNS:xxxx.fr,DNS:*.xxxx.fr'
[Mon Feb 13 17:22:32 UTC 2023] Getting domain auth token for each domain
[Mon Feb 13 17:22:35 UTC 2023] Getting webroot for domain='xxxx.fr'
[Mon Feb 13 17:22:35 UTC 2023] Getting webroot for domain='*.xxxx.fr'
[Mon Feb 13 17:22:35 UTC 2023] Adding txt value: bVqZVR4V-3vh3oq1JGEx2qI8p4Qmgfz8_4pLit-Iwkg for domain:  _acme-challenge.xxxx.fr
[Mon Feb 13 17:22:35 UTC 2023] Using OVH endpoint: ovh-eu
[Mon Feb 13 17:22:35 UTC 2023] Checking authentication
[Mon Feb 13 17:22:36 UTC 2023] Consumer key is ok.
[Mon Feb 13 17:22:37 UTC 2023] Adding record
[Mon Feb 13 17:22:38 UTC 2023] Added, sleep 10 seconds.
[Mon Feb 13 17:22:48 UTC 2023] The txt record is added: Success.
[Mon Feb 13 17:22:48 UTC 2023] Adding txt value: _fOw4V6AXqmGJBHNPHxjPx5i8dhzoSP0VqWiW5HQdzc for domain:  _acme-challenge.xxxx.fr
[Mon Feb 13 17:22:48 UTC 2023] Using OVH endpoint: ovh-eu
[Mon Feb 13 17:22:48 UTC 2023] Checking authentication
[Mon Feb 13 17:22:48 UTC 2023] Consumer key is ok.
[Mon Feb 13 17:22:49 UTC 2023] Adding record
[Mon Feb 13 17:22:50 UTC 2023] Added, sleep 10 seconds.
[Mon Feb 13 17:23:00 UTC 2023] The txt record is added: Success.
[Mon Feb 13 17:23:00 UTC 2023] Let's check each DNS record now. Sleep 20 seconds first.
[Mon Feb 13 17:23:20 UTC 2023] You can use '--dnssleep' to disable public dns checks.
[Mon Feb 13 17:23:20 UTC 2023] See: https://github.com/acmesh-official/acme.sh/wiki/dnscheck
[Mon Feb 13 17:23:20 UTC 2023] Checking xxxx.fr for _acme-challenge.xxxx.fr
[Mon Feb 13 17:23:21 UTC 2023] Domain xxxx.fr '_acme-challenge.xxxx.fr' success.
[Mon Feb 13 17:23:21 UTC 2023] Checking xxxx.fr for _acme-challenge.xxxx.fr
[Mon Feb 13 17:23:21 UTC 2023] Domain xxxx.fr '_acme-challenge.xxxx.fr' success.
[Mon Feb 13 17:23:21 UTC 2023] All success, let's return
[Mon Feb 13 17:23:21 UTC 2023] Verifying: xxxx.fr
[Mon Feb 13 17:23:22 UTC 2023] Pending, The CA is processing your order, please just wait. (1/30)
[Mon Feb 13 17:23:24 UTC 2023] Success
[Mon Feb 13 17:23:24 UTC 2023] Verifying: *.xxxx.fr
[Mon Feb 13 17:23:25 UTC 2023] Pending, The CA is processing your order, please just wait. (1/30)
[Mon Feb 13 17:23:27 UTC 2023] Success
[Mon Feb 13 17:23:27 UTC 2023] Removing DNS records.
[Mon Feb 13 17:23:27 UTC 2023] Removing txt: bVqZVR4V-3vh3oq1JGEx2qI8p4Qmgfz8_4pLit-Iwkg for domain: _acme-challenge.xxxx.fr
[Mon Feb 13 17:23:28 UTC 2023] Using OVH endpoint: ovh-eu
[Mon Feb 13 17:23:28 UTC 2023] Checking authentication
[Mon Feb 13 17:23:28 UTC 2023] Consumer key is ok.
[Mon Feb 13 17:23:31 UTC 2023] Removed: Success
[Mon Feb 13 17:23:31 UTC 2023] Removing txt: _fOw4V6AXqmGJBHNPHxjPx5i8dhzoSP0VqWiW5HQdzc for domain: _acme-challenge.xxxx.fr
[Mon Feb 13 17:23:31 UTC 2023] Using OVH endpoint: ovh-eu
[Mon Feb 13 17:23:31 UTC 2023] Checking authentication
[Mon Feb 13 17:23:32 UTC 2023] Consumer key is ok.
[Mon Feb 13 17:23:35 UTC 2023] Removed: Success
[Mon Feb 13 17:23:35 UTC 2023] Verify finished, start to sign.
[Mon Feb 13 17:23:35 UTC 2023] Lets finalize the order.
[Mon Feb 13 17:23:35 UTC 2023] Le_OrderFinalize='https://acme-v02.api.letsencrypt.org/acme/finalize/127395905/164589429676'
[Mon Feb 13 17:23:36 UTC 2023] Downloading cert.
[Mon Feb 13 17:23:36 UTC 2023] Le_LinkCert='https://acme-v02.api.letsencrypt.org/acme/cert/03bc2517f7ac3725b7f15e3f08b10e092256'
[Mon Feb 13 17:23:36 UTC 2023] Cert success.
-----BEGIN CERTIFICATE-----
xxxxxxxxxxxxx
-----END CERTIFICATE-----
[Mon Feb 13 17:23:36 UTC 2023] Your cert is in: /acme.sh/xxxx.fr/xxxx.fr.cer
[Mon Feb 13 17:23:36 UTC 2023] Your cert key is in: /acme.sh/xxxx.fr/xxxx.fr.key
[Mon Feb 13 17:23:36 UTC 2023] The intermediate CA cert is in: /acme.sh/xxxx.fr/ca.cer
[Mon Feb 13 17:23:36 UTC 2023] And the full chain certs is there: /acme.sh/xxxx.fr/fullchain.cer

Va comprendre Charles !!!!

Pour finir, j'ai aussi lancé manuellement le déploiement en ligne de commande ... et tout est OK

Il ne me reste plus qu'a attendre deux mois pour voir si le prochain renouvellement se fera bien !

Conclusion : encore un truc informatique qui tombe en marche sans qu'on ne sache bien pourquoi !!! Ou est le temps de mes débuts en informatique (sur cartes perforées pour donner une idée) où l'informatique était encore une science exacte !!! 😭

[Mic13710]

il y a 25 minutes, Kramlech a dit :

Pour finir, j'ai aussi lancé manuellement le déploiement en ligne de commande ... et tout est OK

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'

[Kramlech]

Je n'ai qu'un seul certificat, et dans account.conf, je n'ai que le ligne " SAVED_SYNO_Certificate='xxxx_wilcard'"

Et le compte rendu du déploiement c'est :

root@DS716:~# docker exec Acme sh -c "acme.sh --deploy -d 'xxxx.fr' --deploy-hook synology_dsm"
[Mon Feb 13 17:28:51 UTC 2023] Logging into 172.17.0.1:5000
[Mon Feb 13 17:28:52 UTC 2023] Getting certificates in Synology DSM
[Mon Feb 13 17:28:52 UTC 2023] Generate form POST request
[Mon Feb 13 17:28:52 UTC 2023] Upload certificate to the Synology DSM
[Mon Feb 13 17:30:57 UTC 2023] http services were NOT restarted
[Mon Feb 13 17:30:57 UTC 2023] Success

 

[.Shad.]

Le 13/02/2023 à 18:53, Kramlech a dit :

Conclusion : encore un truc informatique qui tombe en marche sans qu'on ne sache bien pourquoi !!! Ou est le temps de mes débuts en informatique (sur cartes perforées pour donner une idée) où l'informatique était encore une science exacte !!! 😭

Tu es tombé sur une màj foireuse, ça arrive, d'ailleurs quand on regarde les releases sur le GH, aucune trace de la 3.0.6 : https://github.com/acmesh-official/acme.sh/releases
Rien ne t'aurait empêché de restaurer une sauvegarde de ce dossier avec une version antérieure de acme.sh

L'intérêt d'utiliser docker-compose est qu'on peut facilement choisir la version qu'on utilise, ça combiné avec la mise à 0 de la variable auto-upgrade, et on a quelque chose de beaucoup plus fiable.

Ah, et bon courage pour faire les programmes actuels sur cartes perforées. 😄 

Modifié le 16 février 2023 par .Shad.

[Mic13710]

@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.

[Kramlech]

Il y a 10 heures, .Shad. a dit :

Ah, et bon courage pour faire les programmes actuels sur cartes perforées. 😄 

C'est bon, j'ai pris ma retraite !!! Maintenant je fais m'amuse avec les NAS !!!

[oracle7]

@Mic13710

Bonjour,

il y a 34 minutes, Mic13710 a dit :

supprimer les "SAVED_" des fichiers conf des certificats

Il ne faut le faire QUE dans le fichier "account.conf" et hors variables liées à OVH qui doivent rester en "SAVED_OVH_xx".

Dans le fichier domaine.tld.conf, ce sont bien des sauvegardes (avec préfixe "SAVED_") des valeurs des variables du fichier account.conf. Sauf erreur de ma part (mais c'est difficile à suivre dans le script acme.sh) elles ne sont utilisées (transposées dans leur forme normale i.e. sans le préfixe "SAVED_") que si le script ne les trouve pas dans le fichier account.conf.

il y a 26 minutes, Mic13710 a dit :

refaire les $export des valeurs avant de lancer le déploiement

C'est un passage incontournable à partir du moment où on reprend le processus car les "export" des variables d'environnement sont perdus du fait que l'on a attaqué/démarré une nouvelle session de shell.

Je t'invite aussi à lire ma réponse dans ce post :

Cordialement

oracle7😉

 

[Mic13710]

il y a 15 minutes, oracle7 a dit :

Il ne faut le faire QUE dans le fichier "account.conf" et hors variables liées à OVH qui doivent rester en "SAVED_OVH_xx".

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.

il y a 48 minutes, oracle7 a dit :

C'est un passage incontournable à partir du moment où on reprend le processus car les "export" des variables d'environnement sont perdus du fait que l'on a attaqué/démarré une nouvelle session de shell.

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 !

[oracle7]

@Mic13710

Bonjour,

il y a 10 minutes, Mic13710 a dit :

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.

Eh bien c'est que cela coince car le TUTO dit au point B 2 (déploiement automatique) :

Citation

2) On ré édite notre fichier "account.conf" créé au point 2B, on y rajoute :

SAVED_SYNO_Scheme='http'
SAVED_SYNO_Hostname='172.17.0.1'
SAVED_SYNO_Port='5000'
SAVED_SYNO_Username='nom utilisateur'
SAVED_SYNO_Password='le password'
SAVED_SYNO_DID=''
SAVED_SYNO_Certificate='description du certificat mise dans le DSM'

C'est là que je dis qu'il ne faut pas préfixer avec "SAVED_" les variables ajoutées. Par ailleurs, il me semble que ces variables sont indépendantes du domaine à déployer mais plutot liées à l'environnement de connexion au NAS.

Au passage pourquoi tu n'as pas fait cet ajout ? ce n'est pas un reproche c'est juste pour comprendre ta démarche.

il y a 23 minutes, Mic13710 a dit :

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.

Désolé, mais sur ce second point je crois que tu te fourvois, les fameux SAVED_ ne sont pas exportées d'une part (rien vu dans le code acme.sh à ce niveau mais si tel est le cas merci de BV m'indiquer les n° de lignes concernées dans le code) et d'autre part, les données utiles à l'environnement du déploiement (connexion au NAS) sont dans le fichier account.conf.

Je t'invite à examiner le script de déploiement pour t'en rendre compte. Il ne prend en compte que les variables non préfixées pour les exporter elles. C'est le rôle de la fonction "_getdeployconf()" (incluse dans le script acme.sh) utilisée/appelée pour chaque variable dès le début du script "synology_dsm_deploy.sh". Je ne l'invente pas c'est le code ... 🤔

il y a 18 minutes, Mic13710 a dit :

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.

Par ailleurs, je n'ai pas vu dans le code a priori d'endroit où il relit le fichier domaine.tld.conf pour l'exploiter. Je n'ai vu par contre que des instructions de sauveagarde des variables en les préfixant. Là aussi si tu sais quelles lignes sont concernées par la relecture de ces variables et leur exportation, je serais content de les examiner.

Sinon au final, on va bien finir par trouver d'où vient cette anomalie de déploiement 😜

Cordialement

oracle7😉

 

[Mic13710]

@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.