[TUTO] Certificat Let's Encrypt avec acme.sh & api Ovh en Docker (DSM6/7) (Update 07/09/22)

[MilesTEG1]

Corolaire : swag utilise quoi comme outils pour récupérer les certificats ? Il ne me semble pas que ce soit Acme...

[oracle7]

@MilesTEG1

Bonjour,

Sauf erreur de ma part, ce ne serait Cerbot ?

Cordialement

oracle7😉

[MilesTEG1]

Ha oui, ça me parle quelque peu ça, Certbot 🙂

Merci @oracle7 😇

[oracle7]

@Audio

Bonjour,

Citation

Il y a 3 heures, Audio a dit :

Lorsque je lance la commande docker exec -it acme /bin/sh j'obtiens un message d'erreur disant qu'il n'existe de pas de conteneur acme

/volume1$ docker exec -it acme /bin/sh
Error: No such container: acme

Non, ce n'est pas une question de répertoire mais plutot n'aurais-tu pas par hazard nommé ton conteneur "Acme" (avec un A majuscule) ? Le shell est sensible à la casse.  Donc si Oui, tapes la commande : docker exec -it Acme /bin/sh

Cordialement

oracle7😉

[.Shad.]

@oracle7 @MilesTEG1 Il suffit de monter les certificats dans un volume docker, et de remonter ce volume dans le conteneur Nginx. C'est ce que je fais sur mon VPS dans le conteneur d'acme :

version: "2.1"
services:

   acme:
      image: neilpang/acme.sh
      container_name: acme
      network_mode: bridge
      environment:
         - CF_Token=or18fsOvEP_yjOwZZBHiVzn2ggXXXXXXXXXXXXX
      volumes:
         - acme-certs:/acme.sh
      labels:
         - "com.centurylinklabs.watchtower.enable=true"
      command: daemon
      restart: unless-stopped
      
volumes:

   acme-certs:
      external: true

Et dans mon conteneur SWAG :

version: "2.1"
services:

   swag:
      [...]
      volumes:
         # config
         - /opt/swag/config:/config
         # acme.sh certs
         - acme-certs:/acme-certs
      [...]
      
volumes:

   acme-certs:
      external: true

[Diplo95]

Bonjour à tous,

j'ai un soucis lors du renouvellement de mon certificat depuis quelques jours. J'ai lu les commentaires récents et je l'attribue donc éventuellement au déploiement de la version 3.0.6 du script Acme. Tout d'abord, voici mon message d'erreur :

Le planificateur de tâches a terminé une tâche planifiée.

Tâche : RenewCertifLE_Docker
Heure de début : Sun, 05 Feb 2023 05:00:01 GMT
Heure d'arrêt : Sun, 05 Feb 2023 05:00:02 GMT
État actuel : 1 (Interrompu)
Sortie/erreur standard :
/usr/local/bin/acme.sh: eval: line 2401: **************: not found
[Sun Feb 5 04:00:02 UTC 2023] SYNO_Username & SYNO_Password must be set
[Sun Feb 5 04:00:02 UTC 2023] Error deploy for domain:gpointeau.fr
[Sun Feb 5 04:00:02 UTC 2023] Deploy error.

Il se trouve que les ************* correspondent à une partie de mon mot de passe pour accéder au compte créé exclusivement pour le renouvellement de mon certificat Let's Encrypt. Je rajoute que ce renouvellement se passait sans aucun soucis jusqu'à maintenant.

 

Pour faire un test, je souhaite donc revenir à la version 3.0.5 du script Acme. C'est là que mes lacunes apparaissent. J'ai suivi le tuto de la première page, mais je ne trouve plus le fichier docker-compose.yml en Cbis. Je pense donc que j'ai dû faire uniquement la partie C.

J'ai donc modifié la tache récurrente en :

docker pull neilpang/acme.sh:3.0.5
docker stop Acme
docker rm Acme
docker image prune -f
docker volume ls -qf dangling=true | xargs -r docker volume rm
docker run -d --cpu-shares=10 --memory=134217728 --name=Acme -v /volume1/docker/Acme:/acme.sh:rw --restart always 

J'ai lancé manuellement cette tâche, mais la version du script reste toujours la même : 3.0.6.

Pouvez-vous m'expliquer comment revenir à la version 3.0.5 svp ?

Merci

[oracle7]

@Diplo95

Bonjour,

il y a 39 minutes, Diplo95 a dit :

J'ai lancé manuellement cette tâche, mais la version du script reste toujours la même : 3.0.6.

Si dans ton fichier account.conf tu laisses la commande : AUTO_UPGRADE à 1 alors automatiquement ton script acme.sh sera mis à jour à la version actuelle 3.0.6 même après avoir installer la nouvelle image 3.0.5. Logique, non ?

Donc tu modifies tel que : AUTO_UPGRADE='0'

Par ailleurs, le log que tu donnes est explicite :

il y a 39 minutes, Diplo95 a dit :

[Sun Feb 5 04:00:02 UTC 2023] SYNO_Username & SYNO_Password must be set

Vérifies donc ton fichier account.conf, il doit comporter ces deux variables d'environnement correctement renseignées.

il y a 39 minutes, Diplo95 a dit :

je ne trouve plus le fichier docker-compose.yml en Cbis.

Le voici, il existe pourtant bien en 1ère page du TUTO : nettoies tes lunettes ! 🤪

version: "2.1"
services:
  acme:
    cpu_shares: 10
    mem_limit: 128M
    container_name: Acme
    network_mode: bridge
    labels:
      - com.centurylinklabs.watchtower.enable=true
    volumes:
      - /volume1/docker/Acme:/acme.sh:rw
    restart: unless-stopped
    image: neilpang/acme.sh:latest
    command: daemon

Cordialement

oracle7😉

[Mic13710]

Pour info, Neilpang a fait une maj de acme.sh il y a deux jours, sans changement du numéro de version.

https://github.com/acmesh-official/acme.sh/commit/a5fbf3fb806dd32fda16b7442b28e52dd20b58d8

Je n'ai pas bien compris quelle a été la modification, mais la mise à jour a été faite ce matin sur mon NAS.

A voir si cela corrige les bugs rencontrés par certains ces derniers jours.

[oracle7]

@Mic13710

Bonjour,

J'ai eu aussi cette mise à jour ce matin avec effectivement la correction de l'erreur 22 que certains ici ont relaté ici :

Mais ce qui est bizarre c'est que le script est en version 3.0.6 et je n'ai trouvé (mal cherché peut-être !) sur github de mention de cette version. Dans les releases, on ne voit que la version 3.0.5 en latest qui date de Nov 2022 ?????

Cordialement

oracle7😉

[Mic13710]

Bizarre ce que tu me dis.

Sur ce lien https://github.com/acmesh-official/acme.sh/blob/master/acme.sh

c'est bien la 3.0.6

[Diplo95]

Merci @oracle7 de te pencher sur mon problème. J'aurais dû rentrer en peu plus dans les détails :

1. Pour le AUTOUPGRADE :
Je ne savais pas. Cependant, après avoir défini la tâche paramétrable comme ceci :

docker pull neilpang/acme.sh:3.0.5
docker stop Acme
docker rm Acme
docker image prune -f
docker volume ls -qf dangling=true | xargs -r docker volume rm
docker run -d --cpu-shares=10 --memory=134217728 --name=Acme -v /volume1/docker/Acme:/acme.sh:rw --restart always neilpang/acme.sh:latest daemon

et changé account.conf comme ceci :

LOG_FILE="/acme.sh/acme.sh.log"
LOG_LEVEL=1

AUTO_UPGRADE='0'

#NO_TIMESTAMP=1

USER_PATH='/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin'
SAVED_OVH_AK='**************'
SAVED_OVH_AS='*************************'
SAVED_OVH_CK='**************************'

DEFAULT_ACME_SERVER='https://acme-v02.api.letsencrypt.org/directory'

SAVED_SYNO_Scheme='http'
SAVED_SYNO_Hostname='192.168.*.*'
SAVED_SYNO_Port='443'
SAVED_SYNO_Username='*******************'
SAVED_SYNO_Password='*********************'
SAVED_SYNO_DID=''
SAVED_SYNO_Certificate='ACME_Wilcard_LE_*.*************.fr'
UPGRADE_HASH='***************************************'

lorsque je lance manuellement la tache, je m'attends donc à avoir la version 3.0.5 du script acme.sh. Or :

 

2. J'ai lu comme toi le message d'erreur et j'ai bien vérifié les variables du fichier account.conf -> elles sont correctes et ne créaient pas d'erreur jusque là.

J'ai un doute sur un caractère que j'ai utilisé dans mon MDP : '&' . En effet, dans mon message d'erreur, il recopie le mot de passe après ce caractère. Peut être est un caractère qui induit une particularité, y compris entre ' '.

 

3. J'aurais dû être beaucoup plus précis en effet. Je trouve bien le fichier docker-compose en première page du post (d'ailleurs comment sais tu que je porte effectivement des lunettes 🙂 ). Je ne le retrouve par contre dans aucun de mes dossiers sur le NAS.

[oracle7]

Bonjour,

@Mic13710

Oui effectivement tu as raison, je n'ai pas regardé dans le script lui même mais on ne le voit que là cette version.

@Diplo95

1 - Je ne comprend pas 🤔  tu installes une version docker du script acme.sh et tu indiques dans ton fichier account.conf qu'il doit accéder à ton NAS via son @IP locale (sur ton réseau local en 192.168.x.x) en HTTP et de surcroît sur le port 443. Ce n'est pas cohérent à mon sens.

Reprends le TUTO et tu verras que l'on indique au point B2) l'@IP du conteneur soit 172.17.0.1. De plus, le port d'accès normal du NAS en HTTP (sauf si tu l'as changé dans DSM), est le port 5000 et pas 443 ! (pour info le port 443 est habitellement le port des flux HTTPS en mode Web et en HTTPS le port d'accès "normal" du NAS est le port 5001). Je crains que tu ne mélanges les notions...🥴

2 - Pour mémoire, le NAS fonctionne sous un OS qui est un "UNIX adapté" et comme tout système basé sur UNIX il ne faut utiliser de caractères dits "réservés" par le shell dans les noms de fichiers/dossiers mais aussi dans les mots de passe. Donc exit le caractère '&' et tout autre cartères dit "spécial"; n'utilises que [a-z A-Z 0-9 -] ainsi tu n'auras pas de soucis d'interprétation du shell et donc d'erreurs parfois difficiles à interpréter à cause de ces caractères spéciaux.

3 -

Il y a 3 heures, Diplo95 a dit :

Je ne le retrouve par contre dans aucun de mes dossiers sur le NAS.

Evidemment, tu ne peux le trouver (actuellement) car ce fichier docker-compose.yml est à créer par toi sur le NAS, donc si tu ne l'as pas fait, tout s'explique ... Donc avec un éditeur de texte en UTF8 tu le crées, par exemple dans le répertoire acme de ton conteneur docker soit : " /volume1/docker/acme/script_install ". Ainsi en te plaçant dans ce répertoire ( cd /volume1/docker/acme/script_install ) tu peux lancer/créer et arrêter à ta guise ton conteneur acme avec respectivement les commandes :  " docker-compose up -d  /  docker-compose down ". C'est bien plus souple que d'utiliser un docker run, mais ce n'est que mon avis ...

Cordialement

oracle7😉

 

[Diplo95]

@oracle7

Je comprends toutes les remarques que tu me fais et elles sont toutes cohérentes. MAIS : tout fonctionnait à merveille depuis des mois avec la configuration que j'avais. Je sais que ce n'est pas un argument recevable lorsque soudainement ça bugge, et c'est donc l'occasion de repartir sur des bases plus saines.

1. Je suis d'accord avec tes remarques. Cependant, je ne me rappelle plus pourquoi j'avais dû adapter le fichier account.conf à l'époque.
J'ai changé les ports d'accès à mon NAS en suivant les très bons tutos trouvés sur ce forum.
Je pense que tu as raison pour le port 443 : c'est l'unique port d'entrée à mon NAS, mais depuis l'extérieur uniquement, grâce à l'utilisation du reverse proxy. Je vais revoir cet aspect.

2. Je vais donc essayer en enlevant tous les caractères spéciaux. Mais encore une fois, tout fonctionnait bien jusqu'à il y a quelques jours. Est-ce que ça ne baisse pas le niveau de protection du mot de passe ?

3. J'ai bien lu le tuto, et plusieurs fois. Je ne comprends toujours pas l'utilité du docker-compose.yml. En effet, n'est-ce pas la tache planifiée quotidienne qui crée le docker ?

[oracle7]

@Diplo95

Bonjour,

Il y a 15 heures, Diplo95 a dit :

J'ai changé les ports d'accès à mon NAS en suivant les très bons tutos trouvés sur ce forum.

Oui c'est une bonne pratique mais cela est valable pour un accès depuis l'extérieur. Dans le cas présent, n'oublies pas que tu es sous docker pour l'exécution du script acme.sh et qu'en l'occurence ce script travaille uniquement en local. Il n'y a donc pas de problème de sécurité (à moins que tu ais des pirates "cachés" chez toi🤣). En conséquence, on utilise le port NORMAL HTTP (5000) pour accèder au NAS et normalement tu fais cela en plus via un utilisateur dédié qui a des droits restreints.

Il y a 15 heures, Diplo95 a dit :

Est-ce que ça ne baisse pas le niveau de protection du mot de passe ?

On croit généralement bien faire en ajoutant des caractères spéciaux à ses identifiants/mots de passe et certes humainement cela semble plus difficile à lire(et à se souvenir) mais informatiquement parlant cela n'amène aucune complexité supplémentaire mais plutôt des problèmes car souvent ces caractères spéciaux sont des caractères réservés du système d'exploitation et du coup les interpréteurs de commandes s'y perdent et génèrent des erreurs. De plus cryptographiquement parlant, un caractère dit spécial n'apporte qu'un bit supplémentaire alors qu'ajouter tout simplement un caractère standard (majuscule ou minuscule ou chiffre) en apporte onze, ce qui rallonge drastiquement le temps de déchiffrement pour un malveillant.

Moralité, les identifiants et surtout les mots de passe, pour être efficaces doivent être très long (au moins > 12 caractères avec que des majuscules ou minuscules ou chiffres).

Il y a 15 heures, Diplo95 a dit :

Je ne comprends toujours pas l'utilité du docker-compose.yml. En effet, n'est-ce pas la tache planifiée quotidienne qui crée le docker ?

Le fichier docker-compose.yml est une autre façon de créer/exécuter/supprimer un conteneur docker. Il est plus simple à manipuler qu'une commande docker run .... avec tout son lot de paramètres.

Effectivement, ici c'est la tâche planifiée qui, tous les jours, supprime systèmatiquement l'image acme, la recrée et relance la création du conteneur acme. C'est à mon sens exagéré car souvent les mises à jour d'images sont très espacées, en tout cas elles n'ont pas lieu tous les jours. Du coup, mais ce n'est que mon avis, il n'est pas utile de recréer le conteneur tous les jours. Une fois lancé on le laisse tourner mais ici c'est le choix qui a été fait. Saches qu'il y a par ailleurs d'autres moyens (watchtower sous docker en autres) pour mettre à jour automatiquement l'image acme quand elle en a besoin. Donc si tu conserves la tâche programmée, oublies l'usage d'un fichier docker-compose. Je t'invite aussi à lire attentivement l'excellent TUTO : Docker introduction de @.Shad. où il explique parfaitement qu'il est préférable d'utiliser un fichier docker-compose ce qui est bien plus souple à l'usage pour l'utilisateur lambda (et le "pro"). Maintenant ce que j'en dis, c'est toi qui voit ...

Cordialement

oracle7😉

 

[Audio]

Le 03/02/2023 à 19:04, oracle7 a dit :

Non, ce n'est pas une question de répertoire mais plutot n'aurais-tu pas par hazard nommé ton conteneur "Acme" (avec un A majuscule) ? Le shell est sensible à la casse.  Donc si Oui, tapes la commande : docker exec -it Acme /bin/sh

Cordialement

oracle7😉

Merci @oracle7

Effectivement mon conteneur est libellé "Acme", comme indiqué dans le Tuto. De plus la commande ne passe pas à partir de WinSCP, il faut la passer à partir de Putty.

Sinon la version en cours chez moi est bien 3.0.6. Je vais voir s'il y a lieu de faire un downgrade vers 3.0.5 ou pas.

Cordialement Audio

[oracle7]

@Audio

Bonjour,

Il y a 2 heures, Audio a dit :

De plus la commande ne passe pas à partir de WinSCP, il faut la passer à partir de Putty.

C'est normal car WinSCP n'est pas lancé en "root" (on ne peut pas que je sache), seul Putty permet de passer en "root" pour exécuter ce type de commande.

Cordialement

oracle7😉

[Mic13710]

il y a une heure, oracle7 a dit :

WinSCP n'est pas lancé en "root" (on ne peut pas que je sache)

Il est possible de lancer WinSCP en root avec une clé comme expliqué dans le tuto du regretté unpixel

 

[Audio]

Il y a 1 heure, Mic13710 a dit :

Il est possible de lancer WinSCP en root avec une clé comme expliqué dans le tuto du regretté unpixel

 

@oracle7 et @Mic13710

WinSCP peut être lancé en root, ça fonctionne très bien et j'ai effectivement suivi le Toto de @unPixel il y a un moment déjà pour installer plus commodément les tuto acme.sh d' @oracle7 et celui sous Docker d'@Einsteinium

Cordialement

Audio

[oracle7]

@Audio

Bonjour,

Oui désolé, j'avais oublié cette possibilité car je ne l'ai jamais mis en place, j'accède personnellement en SSH uniquement par un utilisateur dédié et seulement ensuite si vraiment necéssaire, je passe sous 'root' avec un 'sudo su -' sinon en préfixant les commandes shell qui le nécessitent, avec le prefixe sudo, c'est largement suffisant, cela évite, du moins minimise les erreurs quand on a trop de droits ...

EDIT : @Mic13710

Mais à la réflexion, WinSCP est une application Windows donc pas lançable en 'root' même si l'utilisateur Win est administrateur du PC. On navigue avec elle dans l'arborescence interne de DSM par exemple mais impossible de modifier un fichier dont le propriétaire est 'root'.

Par contre, WinSCP peut, elle, lancer directement un teminal/console sous root via certains outils comme PuTTY par ex, mais seulement après avoir préalablement suivi la procédure du TUTO de unpixel.

Ce n'est donc pas la même chose. Il faut bien différentier WinSCP de PuTTY !

Cordialement

oracle7😉

Modifié le 7 février 2023 par oracle7

[Mic13710]

Il y a 16 heures, oracle7 a dit :

impossible de modifier un fichier dont le propriétaire est 'root'.

Ca c'est toi qui le dit. As tu au moins essayé ?

Moi je t'affirme que ça marche. Tu peux créer, modifier un fichier root et même définir ses droits utilisateur directement dans l'interface. Lors de la sauvegarde, il faut simplement indiquer la clé pour confirmer le status root et c'est OK.

Par contre, il est bien évident qu'on ne peut pas passer des commandes dans WinSCP et qu'il faut pour cela ouvrir le terminal ou putty, tous deux intégrés dans l'interface.

[ssj4gokusama]

Bonjour,

Je n'arrive plus à importer automatiquement le certificat depuis le planificateur de tâches.  Le rapport m'indique ceci : 

Citation

Tâche : Import certif
Heure de début : Sun, 12 Feb 2023 12:32:47 GMT
Heure d'arrêt : Sun, 12 Feb 2023 12:32:47 GMT
État actuel : 1 (Interrompu)
Sortie/erreur standard :
/usr/local/bin/acme.sh: eval: line 2401: syntax error: unexpected ")"
[Sun Feb 12 11:32:47 UTC 2023] Deploy error.

Pour information, c'est la v3.0.6 de Acme, j'ai refais à zéro mon fichier account.conf (si jamais c'est ce fichier qui provoque l'erreur) et en changeant le mot de passe de l'utilisateur dédié à l'importation du certificat.

 

Si quelqu'un aurait une idée pour résoudre le problème.

Merci

Modifié le 12 février 2023 par ssj4gokusama

[Eridani78]

@Einsteinium,  @oracle7

Je suis en version acme.sh V3.0.6 et DSM 7 et je me suis aperçu que depuis quelques temps, j'avais le même problème que @Diplo95.

[Sun Feb 5 04:00:02 UTC 2023] SYNO_Username & SYNO_Password must be set
[Sun Feb 5 04:00:02 UTC 2023] Error deploy for domain:mondomaine.net
[Sun Feb 5 04:00:02 UTC 2023] Deploy error.

Mon script de déployement automatique fonctionnait correctement puis est passé un jour avec l'erreur ci-dessus.

Lorsque l'on regarde le code acme.sh, il apparait que le nom des constantes déclarées dans le fichier de configuration n'est plus sous la forme :

SAVED_SYNO_Username

SAVED_SYNO_......

mais

SYNO_Username

SYNO_...

Il semblerait donc que le tuto soit à mettre à jour ... enfin si je ne me trompe pas ...

Modifié le 15 février 2023 par Eridani78

[Einsteinium]

Déjà répondu, j’ai vue ses variables la est aucun soucis.

[oracle7]

@Eridani78

Bonjour,

Je serais assez d'accord avec toi pour l'usage des variable d'environnement car sauf erreur de ma part, lorsque l'on épluche le code du script de déploiement "synology_dsm.sh" on voit bien qu'il utilise les variables d'environnement non préfixées par "SAVED_" qu'il relit depuis le fichier "account.conf".

  # Get Username and Password, but don't save until we successfully authenticate
  _getdeployconf SYNO_Username
  _getdeployconf SYNO_Password
  _getdeployconf SYNO_Create
  _getdeployconf SYNO_DID
  _getdeployconf SYNO_TOTP_SECRET
  if [ -z "${SYNO_Username:-}" ] || [ -z "${SYNO_Password:-}" ]; then
    _err "SYNO_Username & SYNO_Password must be set"
    return 1
  fi

Ensuite il les sauvegarde en les préfixant avec "SAVED_" dans le fichier domaine.tld.conf.

A mon humble avis donc pour éviter l'erreur que tu as citée il faut que dans le fichier account.conf les variables ne soient pas préfixées avec "SAVED_". Perso, je fonctionne comme cela et aucuns soucis.

ATTENTION cette disposition ne concerne pas les variables liée aux clés OVH "SAVED_OVH_xx" !!!

Cordialement

oracle7😉

 

[oracle7]

Bonjour,

A la vue des derniers échanges, je craignais le pire avec cette version 3.0.6 du script acme.sh pour mon renouvellement de certificat arrivant à échéance ce jour, que néni ! 🤗 😀

Il s'est passé sans encombres ainsi que son déploiement.👍🥳

Cordialement

oracle7😉