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

[oracle7]

 Bonjour,

EDIT 20/06/2021

• §4  : Complément à la commande de création du certificat suite aux récentes évolutions du Shell script ACME.
• §6  : Ajout lié au renouvellement.

Pour faciliter la compréhension, le texte lié à cette édition est repéré en bleu.

EDIT 10/01/2021

 

•        § 5.1 : Ajout d’une astuce évitant un problème de renouvellement lié au cookie DID de la double authentification.

EDIT 21/08/2020

• § 6 : Évolution du script Python pour être aussi compatible de la dernière et actuelle version du langage Python : version 3.x.x
• § 10 : Mise à jour du texte d’aide associé à l’option « -h ».
• Suppression des fichiers de trace « cleanlog » et « cleanlogerr » qui n’apportaient rien de plus à la trace existante.
• Remaniement du fichier de trace pour que soit généré un nouveau fichier à chaque exécution du script. On dispose ainsi d’un historique « tournant » basé sur 9 fichiers : « acme_renew_python.log.1 » à « acme_renew_python.log.9 ». Le fichier à l’indice « 1 » étant toujours le dernier donc le plus récent.
• Nouvelle version v1.44 du script Python (à remplacer simplement dans le répertoire « /volume1/Scripts »).

Pour faciliter la compréhension, le texte lié à cette édition est repéré en bleu.

EDIT 11/08/2020

• § 10 : Ajout d’une trace complète et systématique du processus de renouvellement.
• § 10 : Ajout de l’option « -f » au script Python de renouvellement.

La partie configuration du renouvellement automatique du certificat au §6 a été revue grâce à l’aide de @bruno78 que je remercie vivement ici, pour prendre en compte une anomalie liée au Shell script « acme.sh » et à l’environnement particulier du NAS Synology. Cette anomalie ainsi que sa résolution, est décrite au § 10 ci-dessous.

EDIT 01/06/2020

• § 2 : Utilisation du "vrai" root pour la connexion SSH au lieu du "sudo -i"
• § 3.1 : Utilisation de l'Id principal de connexion OVH
• § 5.2.1 : Réaffectations de services à faire suite à la création du certificat en mode Ajout.

 

Objectif de ce tutoriel : Créer un certificat « Wilcard » Let’s Encrypt (LE) afin :

•        d’une part, de prendre en compte tous les domaines de second niveau de votre domaine personnel,
•        et d’autre part, de s’affranchir de la limite fatidique de 256 caractères imposée par Synology pour les SAN (Subject Alternative Name – Autre nom de l’objet) lors de la création des certificats dans DSM.

Pour mémoire, la méthode de création du certificat « wilcard » LE décrite dans le Tutoriel « Certificat TLS/SSL - Let's Encrypt "Wildcard" » de @unPixel utilisait le service ‘SSL For Free’. Malheureusement, ce service n’étant plus gratuit depuis le 18 mai 2020, il convenait alors pour moi de m’orienter sur un autre moyen pour obtenir un certificat « wilcard » LE et gratuit de surcroît.

Nota : ‘SSL For Free’ fournit toujours gratuitement son service mais uniquement pour un seul nom de domaine du type « ndd.tld » (NomDeDomaine.Top-LevelDomain).

En fouillant un peu la toile, j’ai fini par trouver cet autre moyen. Il est basé sur l’utilisation du client ACME via le Shell script « acme.sh » disponible sur GitHub.

Je vous livre donc ci-après la méthode que j'ai suivie. J’ai essayé de la rendre aussi détaillée que possible. En fait elle est conçue pour « les nuls » 😊, mais pas que ...

Sachez que c'est un mixte de différents tutoriels trouvés sur la toile, car aucun pris individuellement ne donnait complètement satisfaction vis-à-vis du but à atteindre et il fallait souvent s’adapter et/ou corriger en fonction de leurs contextes parfois légèrement différents.

Je ne m’en cache pas, je n’ai pas réinventé la roue, vous retrouverez ici certaines explications directement extraites et traduites de ces tutoriels. Selon le cas, le lien vers l’original sera donné.

Mais avant toutes choses, il convient pour mémoire, de faire un petit rappel contextuel.

Depuis que Synology a introduit LE dans la gestion des certificats associés à ses NAS et Routeurs, beaucoup d'entre nous bénéficient du SSL gratuit et c’est très bien. D'un autre côté, beaucoup d'entre nous ne veulent pas exposer les ports 80 et 443 à Internet, y compris l'ouverture de ces ports sur le routeur.

Malheureusement, l'actuelle implémentation Synology de LE ne prend en charge que la méthode de validation dite WEB, basée sur le protocole « HTTP-01 » qui nécessite d'exposer notamment le port 80 à Internet.

Une alternative à cette non exposition est de passer par l’utilisation de la méthode de validation dite par DNS basée sur le protocole « DNS-01 ». Ce protocole présente l’avantage de ne pas avoir besoin d’ouvrir de ports lors de la création du certificat LE mais surtout lors de son renouvellement et là c’est le « plus » indéniable du point de vue sécurité qu’apporte cette méthode.

Mais pour utiliser cette méthode de validation par DNS, il est obligatoire d’avoir la main sur la zone DNS du domaine concerné. En effet, LE vérifie la présence d’un enregistrement de type « TXT » sous la forme de « _acme‑challenge.votre-domaine.tld » contenant la valeur d’autorisation. Cet enregistrement permet de prouver que la personne qui demande le certificat, contrôle également la zone DNS du domaine en question.

Il convient aussi de noter que le protocole « DNS-01 » est utilisé pleinement par les fonctions d’API (Application Programming Interface) développées par nos fournisseurs de domaines tels que OVH et que l’on va utiliser ici.

Pour l’exemple, la méthode présentée ici, utilise les API de mon fournisseur OVH. Mais vous pouvez très bien utiliser les API d’un autre fournisseur car ACME prend en charge de nombreux autres services DNS. Il faudra alors adapter la méthode en fonction de ces autres fournisseurs. Rien de bien compliqué en soit, les paramètres diffèrent quelque peu mais le principe de mise en œuvre reste le même.

Par ailleurs, l’utilisation du Shell script ‘acme.sh’ est rendu possible par le fait que nous pouvons accéder au NAS via une connexion SSH pour le configurer pour renouveler les certificats au lieu d'utiliser le tableau de bord WEB.

Maintenant, cerise sur le gâteau si je puis dire, depuis peu Synology a introduit dans DSM le code nécessaire pour qu’il ne soit plus nécessaire d'exécuter le Shell script ‘acme.sh’ sur votre NAS pour renouveler le certificat. Le Shell script ‘acme.sh’ devra simplement être exécuté sur quelque chose (votre PC/Mac ou autre) qui a accès à l'interface d'administration de DSM. Du coup, les méthodes de déploiement du certificat généré sont considérablement simplifiées et c’est qui va être exploité dans la présente méthode.

Voilà pour le discours préliminaire, on passe aux choses sérieuses …

1         Pré-requis

• ·      Disposer d’un nom de domaine personnel chez OVH.
• ·      Attribuer l’@IP externe de votre Box/Routeur à votre nom de domaine personnel.
  Pour cela, se rendre sur l'espace client d'OVH. Une fois connecté :
  •        Si vous avez une @IP fixe :
    •           aller dans l'onglet : « Web / Domaines / votre-domaine.tld / Zone DNS »
    •           vous devez avoir un enregistrement de type « A » dans le quel votre « votre-domaine.tld » pointe vers cette @IP fixe.
  •           Si vous avez une @IP dynamique :
    •            aller dans l'onglet : « Web / Domaines / votre-domaine.tld / DynHost »
    •            vous devez avoir une ligne avec « votre-domaine.tld » qui a pour cible votre @IP du moment (i.e. l’@IP externe de votre Box/Routeur).
    •           Ce même DynHost doit être également défini sur le NAS (« Panneau de configuration / Accès externe / DDNS » où le nom d’hôte est : « votre-domaine.tld ».

2         Installation du Shell script ‘acme.sh’

L’installation du Shell script ‘acme.sh’ doit s’effectuer dans un répertoire qui n’est pas modifié/réinitialisé lors des mises à jour de DSM. Pour ce faire, on va donc créer un répertoire spécifique d’installation « Certs/Acme_install » sous « /volume1 » et surtout pas sous le répertoire « /root » qui lui est régulièrement « nettoyé » par le système. Ce répertoire « /root » est également utilisé par défaut par ACME. Ceci expliquant cela.

• ·      Sous Windows ouvrir une session SSH sur le NAS (en tant qu’utilisateur « root ») avec « PuTTY » ou « WinSCP »
• ·      Sous Mac ouvrir une session SSH en lançant le « Terminal » puis tapez :
  •        ssh utilisateur-admin@ipdunas (si le port n'est pas 22 alors il faut rajouter « -pXXXXX » où XXXXX = No du port personnalié
  •        sudo -i (pour passer en « root » - c'est la procédure normale).

·         EDIT : Il s'avère que passer sous « root » via un « sudo -i» sur PC comme sur Mac, génère une erreur dans l'exécution de la commande « ./acme.sh». Aussi, je vous invite à suivre le Tuto sur les "Accès SSH et ROOT via DSM6" de      @unPixel et ainsi de configurer un accès par le "vrai" « root ». Cela marche tout de suite bien mieux ...

Nota 1 : Pour ma part sous Windows, je préfère l’utilisation de « WinSCP » à « PuTTY », tout simplement à cause de son interface graphique qui est très agréable de mon point de vue et aussi parce que l’on peut accessoirement directement sélectionner le texte affiché dans la Console pour le Copier/Coller ailleurs dans une autre application. C’est tout bête mais bien pratique au demeurant. Certes « PuTTY » le permet aussi mais je le trouve beaucoup moins souple de ce point de vue, et ce n’est que mon avis ...

Nota 2 : Pour mémoire et ceci est valable pour toute la suite : le symbole « $ » présent en début des lignes de commandes Shell présentées ici, est ce qu’on appelle l’invite de commande du Shell. Dans le cas présent, il est propre à l’outil « WinSCP » que j’ai utilisé pour exécuter les différentes commandes Shell de cette procédure. Bien évidemment, il ne faut pas le sélectionner si vous faites des Copier/Coller du texte de ces commandes.
Je préfère prévenir même si c’est évident pour certains initiés …

• ·         Tapez successivement les commandes suivantes :
  •    On crée le répertoire d’installation d’ACME : « /volume1/Certs/Acme_install » et on s’y place :
  • $ cd /volume1

    $ mkdir -p Certs/Acme_install

    $ cd Certs/Acme_install

  •        On télécharge ACME chez GitHub

  • $ wget https://github.com/acmesh-official/acme.sh/archive/master.tar.gz
     

  •        On décompresse le fichier téléchargé et on se place dans le répertoire qui a été automatiquement créé lors de la décompression :

  • $ tar xvf master.tar.gz

    $ cd acme.sh-master

  •        On lance l’installation d’ACME (pensez avant à remplacer dans la commande : « email@gmail.com » par votre @Mail personnelle)

  • $ ACME_HOME="/usr/local/share/acme.sh"

  • $ CERT_HOME="/volume1/Certs"
    « CERT_HOME » est le répertoire où seront générés les fichiers du certificat. Vous pouvez l’adapter à besoins.
     

  • $ ./acme.sh --install --nocron --home "$ACME_HOME" --cert-home "$CERT_HOME" --accountemail "email@gmail.com"

     

--nocron : spécifie de ne pas installer par défaut le « cron job ». Vous comprendrez de vous-même pourquoi plus loin.

--home : désigne le répertoire « customisé » d’installation du Shell script ‘acme.sh’. C’est un répertoire dit « invariant ». C’est-à-dire qu’il n’est pas modifié par les mises à jour de DSM. Sinon par défaut, le script aurait été installé dans « ~/.acme.sh » où « ~ » correspond au répertoire ‘home’ de l’utilisateur « root » en l’occurrence : « /root ». Pour mémoire le répertoire « /root » est lui, dit « variant », donc sujet à modifications par les mises à jour de DSM.

--cert-home : désigne le répertoire où seront générés les fichiers du certificat « wilcard » LE. Cette disposition permet de les sécuriser d’une part et d’autre part permet de les rendre accessibles facilement sans avoir à replonger dans les acarnes de DSM pour les retrouver en cas de besoin autre.

Nota :Pour votre information, ce répertoire n’est pas un répertoire partagé au sens Synology. De fait, il ne sera donc pas visible sous « File Station » par exemple ce qui quelque part le protège de vos utilisateurs. Il ne sera donc visible qu’au travers d’une connexion directe au NAS dans une session SSH sous l’utilisateur « root ».

Durant la courte installation, vous aurez certainement un message du style :

It is recommended to install socat first.
We use socat for standalone server if you use standalone mode.
If you don't use standalone mode, just ignore this warning.

Il faut savoir que ‘Acme.sh’ recommande l'installation du paquet « socat » pour gérer les certificats en mode standalone, mais comme nous n'allons pas utiliser ce mode, vous pouvez largement ignorer ce message.

Vous trouverez donc, le dossier d'installation d’ACME dans le répertoire : « /usr/local/share/acme.sh ».

• Maintenant, il faut régénérer le fichier « .profile » de l'utilisateur courant (« root ») pour pouvoir utiliser immédiatement les commandes Shell. Pour cela, tapez simplement :

$ source ~/.profile

• ·         Vérifier si besoin les droits d'exécution du fichier « acme.sh » :

$ cd $ACME_HOME

$ ls -al

Normalement c’est bon mais si besoin, tapez : $ chmod a+x acme.sh

• ·         On active la mise à jour automatique du client (c’est préférable mais ce n’est pas une obligation) :

$ ./acme.sh --upgrade --auto-upgrade

Nota 1 : si vous souhaitez désactiver la mise à jour automatique d’ACME, tapez :
$ ./acme.sh --upgrade --auto-upgrade 0

Comme vous pouvez aussi commenter manuellement la ligne : AUTO_UPGRADE="1" dans le fichier « /usr/local/share/acme.sh/account.conf » par l’ajout du caractère « # » en tout début de ligne.

Nota 2 : Si vous êtes curieux et que vous souhaitez voir toutes les commandes disponibles pour ACME, tapez :

$ ./acme.sh --help

NE PAS quitter la session SSH

3         Configuration DNS

3.1        Création des clés

Pour générer un certificat « wilcard » et pouvoir le renouveler automatiquement, on va donc utiliser l’API d’OVH.

Pour ce faire, on va créer une application dans l’API qui va nous permettre de générer trois clés nommées respectivement : « application key », « application secret » et « consumer key ».

Il est aussi une bonne pratique de sécurité que de limiter ce qu'une clé API donnée peut faire, dans le cas où elle serait perdue, volée ou que quelque chose de mal se produirait et ce, pour en limiter les dommages potentiels.

Cela tombe bien, les clés API OVH peuvent être limitées à une zone de domaine spécifique à l'aide d'un mécanisme de modèle simple. On va donc en profiter pour restreindre une clé API OVH à la gestion de « votre-domaine.tld », en utilisant les paramètres suivants :

GET=/domain/zone/votre-domaine.tld/*

&POST=/domain/zone/votre-domaine.tld/*

&PUT=/domain/zone/votre-domaine.tld/*

&GET=/domain/zone/votre-domaine.tld

&DELETE=/domain/zone/votre-domaine.tld/record/*

Il est clair que cela peut facilement être personnalisé pour prendre en charge un ou plusieurs domaines si le besoin en est. Je vous renvoie à la documentation en ligne d’OVH pour plus de détails.

·         On se rend donc sur l’API d’OVH en saisissant l’URL suivante dans un navigateur WEB : https://api.ovh.com/createToken/?GET=/domain/zone/votre-domaine.tld/*&POST=/domain/zone/votre-domaine.tld/*&PUT=/domain/zone/votre-domaine.tld/*&GET=/domain/zone/votre-domaine.tld&DELETE=/domain/zone/votre-domaine.tld/record/*

Nota : Dans le cas où vous ne souhaiteriez pas restreindre la gestion de la clé API OVH à votre domaine, il suffit simplement d’utiliser les paramètres suivants :

?GET=/domain/zone/*

&POST=/domain/zone/*

&PUT=/domain/zone/*

&DELETE=/domain/zone/*/record/*

o   L’URL à utiliser pour aller sur l’API d’OVH, est alors : https://api.ovh.com/createToken/?GET=/domain/zone/*&POST=/domain/zone/*&PUT=/domain/zone/*&DELETE=/domain/zone/*/record/*
 

• ·         Donc avec le premier cas, on arrive sur l’écran suivant :
  Nota : Dans le second cas l’écran est très similaire, je vous laisse vous adapter.

     

 

• ·         On saisit les informations :

o   Account ID : votre identifiant principal de connexion chez OVH
Nota : Si vous utilisez votre @Mail vous aurez un message d’erreur lors de la création des clés.

o   Password : votre mot de passe de connexion chez OVH.

o   Script name : Ce que vous voulez (par ex : « Synology_acme_sh ») mais avec que des caractères, pas d’espaces ni de points et pas de caractères spéciaux sinon cela bloque.

o   Script description : Ce que vous voulez (par ex : « Certificat wilcard LE – ACME ».

o   Validity : Dans le popup sélectionnez l’item « Unlimited ».
 

• ·         On clique en fin sur le bouton « Create keys ».
   
• ·         On obtient l’écran suivant, où il convient immédiatement de copier les clés et de les sauvegarder dans un fichier « .txt » :

3.2        Retour dans la session SSH

• ·         Taper successivement les commandes suivantes :

$ export OVH_END_POINT=ovh-eu

$ export OVH_AK="votre application key"

$ export OVH_AS="votre application secret"

$ export OVH_CK="votre consumer key"

4         Création du certificat

Avant de créer effectivement le certificat il convient de préciser un point sur la méthode de chiffrement associée à la génération du certificat LE.

Sans aucun paramètre spécifique, ACME utilise une clé de chiffrement de type RSA fixée à 2048 bits par défaut.

Dans notre cas, on va directement forcer cette clé RSA à 4096 bits pour renforcer le niveau de sécurité, ce qui se fait par l’emploi du paramètre « -- keylength 4096 » dans la commande de création du certificat.

Maintenant pour ceux qui le souhaitent, on peut aussi passer en mode « paranoïaque » et poussez plus loin les choses en adoptant un chiffrement basé sur une clé ECDSA qui elle s’appuie sur des courbes elliptiques. Malgré une faible longueur, ces clés sont très robustes et peut-être bien plus sécures que les clés RSA et sachant aussi que ces dernières sont déjà bien suffisantes pour nos besoins courants.

Pour comparaison, une clé ECDSA 256 bits est équivalente à une clé RSA 3072 bits, et une clé ECDSA 384 bits est équivalente à une clé RSA 7680 bits !

À noter que LE reconnait les courbes elliptiques P-256 et P-384 mais le P-521 n'est pas encore reconnu.

Donc dans ce dernier cas de figure, le paramètre à employer serait par exemple : « -- keylength ec-394 ». A vous de voir …

 

Bon, il est maintenant vraiment temps de créer le certificat « wilcard » LE pour « votre-domaine.tld » :

• ·         Tapez successivement les commandes suivantes :

$ cd $ACME_HOME

$ export CERT_DOMAIN="votre-domaine.tld"

$ export CERT_WDOMAIN="*.votre-domaine.tld"

$ export CERT_DNS="dns_ovh"

$ ./acme.sh --issue --keylength 4096 -d "$CERT_DOMAIN" -d "$CERT_WDOMAIN" --dns "$CERT_DNS" --set-default-ca --server letsencrypt

Edit du 20/06/2021 :

Suite aux récentes évolutions du Shell script ACME la commande de création du certificat doit être complétée par deux options. En effet, dorénavant lors de la création d'un nouveau certificat, par défaut c'est un certificat ZeroSSL qui est créé par ACME. Donc dans notre cas, comme l'on veux générer un certificat LesEncrypt, on doit ajouter les options suivantes à la commande de création pour forcer la génération du certificat LE :

--set-default-ca --server letsencryp

ainsi le shell script ACME prendra en compte ce choix qu'il retiendra d'ailleurs par la suite lors du renouvellement du certificat.

 

Le processus de création du certificat se déroule et affiche un message du type :

/usr/local/share/acme.sh$ ./acme.sh --issue --keylength 4096 -d "$CERT_DOMAIN" -d "$CERT_WDOMAIN" --dns "$CERT_DNS"

[Sun May 24 22:42:07 CEST 2020] Create account key ok.

[Sun May 24 22:42:07 CEST 2020] Registering account

[Sun May 24 22:42:08 CEST 2020] Registered

[Sun May 24 22:42:08 CEST 2020] ACCOUNT_THUMBPRINT='l7IOxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxfro'

[Sun May 24 22:42:08 CEST 2020] Creating domain key

[Sun May 24 22:42:13 CEST 2020] The domain key is here: /volume1/Certs/votre-domaine.tld/ votre-domaine.tld.key

[Sun May 24 22:42:13 CEST 2020] Multi domain='DNS:votre-domaine.tld,DNS:*.votre-domaine.tld'

[Sun May 24 22:42:13 CEST 2020] Getting domain auth token for each domain

[Sun May 24 22:42:15 CEST 2020] Getting webroot for domain='votre-domaine.tld'

[Sun May 24 22:42:15 CEST 2020] Getting webroot for domain='*.votre-domaine.tld'

[Sun May 24 22:42:15 CEST 2020] Adding txt value: TLMxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxQWk for domain:  _acme-challenge.votre-domaine.tld

[Sun May 24 22:42:15 CEST 2020] Using OVH endpoint: ovh-eu

[Sun May 24 22:42:15 CEST 2020] Checking authentication

[Sun May 24 22:42:16 CEST 2020] Consumer key is ok.

[Sun May 24 22:42:16 CEST 2020] Adding record

[Sun May 24 22:42:17 CEST 2020] Added, sleep 10 seconds.

[Sun May 24 22:42:27 CEST 2020] The txt record is added: Success.

[Sun May 24 22:42:27 CEST 2020] Adding txt value: QXMxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxkJQ for domain:  _acme-challenge.votre-domaine.tld

[Sun May 24 22:42:27 CEST 2020] Using OVH endpoint: ovh-eu

[Sun May 24 22:42:27 CEST 2020] Checking authentication

[Sun May 24 22:42:27 CEST 2020] Consumer key is ok.

[Sun May 24 22:42:27 CEST 2020] Adding record

[Sun May 24 22:42:28 CEST 2020] Added, sleep 10 seconds.

[Sun May 24 22:42:38 CEST 2020] The txt record is added: Success.

[Sun May 24 22:42:38 CEST 2020] Let's check each dns records now. Sleep 20 seconds first.

[Sun May 24 22:42:58 CEST 2020] Checking votre-domaine.tld for _acme-challenge.votre-domaine.tld

[Sun May 24 22:42:58 CEST 2020] Domain votre-domaine.tld '_acme-challenge.votre-domaine.tld' success.

[Sun May 24 22:42:58 CEST 2020] Checking votre-domaine.tld for _acme-challenge.votre-domaine.tld

[Sun May 24 22:42:59 CEST 2020] Domain votre-domaine.tld '_acme-challenge.votre-domaine.tld' success.

[Sun May 24 22:42:59 CEST 2020] All success, let's return

[Sun May 24 22:42:59 CEST 2020] Verifying: votre-domaine.tld

[Sun May 24 22:43:02 CEST 2020] Success

[Sun May 24 22:43:02 CEST 2020] Verifying: *.votre-domaine.tld

[Sun May 24 22:43:06 CEST 2020] Success

[Sun May 24 22:43:06 CEST 2020] Removing DNS records.

[Sun May 24 22:43:06 CEST 2020] Removing txt: TLMxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxQWk for domain: _acme-challenge.votre-domaine.tld

[Sun May 24 22:43:06 CEST 2020] Using OVH endpoint: ovh-eu

[Sun May 24 22:43:06 CEST 2020] Checking authentication

[Sun May 24 22:43:06 CEST 2020] Consumer key is ok.

[Sun May 24 22:43:09 CEST 2020] Removed: Success

[Sun May 24 22:43:09 CEST 2020] Removing txt: QXMxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxkJQ for domain: _acme-challenge.votre-domaine.tld

[Sun May 24 22:43:09 CEST 2020] Using OVH endpoint: ovh-eu

[Sun May 24 22:43:09 CEST 2020] Checking authentication

[Sun May 24 22:43:09 CEST 2020] Consumer key is ok.

[Sun May 24 22:43:13 CEST 2020] Removed: Success

[Sun May 24 22:43:13 CEST 2020] Verify finished, start to sign.

[Sun May 24 22:43:13 CEST 2020] Lets finalize the order, Le_OrderFinalize: https://acme-v02.api.letsencrypt.org/acme/finalize/xxxxxxxxx/xxxxxxxxxxxxxx

[Sun May 24 22:43:14 CEST 2020] Download cert, Le_LinkCert: https://acme-v02.api.letsencrypt.org/acme/cert/0xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx5c1f

[Sun May 24 22:43:15 CEST 2020] Cert success.

-----BEGIN CERTIFICATE-----

xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

-----END CERTIFICATE-----

[Sun May 24 22:43:15 CEST 2020] Your cert is in  /volume1/Certs/votre-domaine.tld/votre-domaine.tld.cer

[Sun May 24 22:43:15 CEST 2020] Your cert key is in  /volume1/Certs/ votre-domaine.tld/votre-domaine.tld.key

[Sun May 24 22:43:15 CEST 2020] The intermediate CA cert is in  /volume1/Certs/votre-domaine.tld/ca.cer

[Sun May 24 22:43:15 CEST 2020] And the full chain certs is there:  /volume1/Certs/votre-domaine.tld/fullchain.cer

 

Voilà déjà une bonne chose de faite …

NE PAS quitter la session SSH

5         Déploiement du certificat

Comme expliqué en préambule, Synology nous a facilité la vie pour le déploiement des fichiers du(des) certificat(s) généré(s). Cela se passe par l’emploi du « Synology DSM deployhook ».

5.1        Cas de la double authentification

Si vous n’utilisez pas la double authentification pour vous connecter à votre NAS, passez directement au §5.2 ci-dessous.

Mais avant de réaliser le déploiement effectif du certificat, il y a encore un point préciser car il y a un paramètre supplémentaire à prendre en compte dans le cas où, comme moi vous utilisez la double authentification pour vous connecter à votre NAS. En effet, si on ne renseigne pas ce paramètre, le processus de double authentification viendrait bloquer le déploiement du certificat tel qu’il sera décrit ci-après. Ce serait dommage convenez-en.

Donc, habituellement lorsqu’on se connecte au NAS après avoir saisi son id/pseudo et son mot de passe, la double authentification réclame la saisie d’un code à six chiffres que l’on obtient à partir d’une application tierce installée idéalement sur un smartphone/iPhone. Pour n’en citer que quelques-unes, il y a : « FreeOTP Authenticator », « Google Authenticator », « Microsoft Authenticator », etc … (le choix est grand ! - pour la mise en place de la double authentification sur le NAS, reportez-vous à l’excellent Tutoriel de @Fenrir sur la sécurisation des accès au NAS).

Bref, on récupère et on saisit donc ce code à six chiffres et on coche la case « Faire confiance à ce périphérique ». Cette dernière action a pour effet caché de créer un « cookie » dans votre navigateur qui lui, évite par la suite que ce code à six chiffres, ne vous soit systématiquement demandé à chaque connexion.

Ce « cookie » stocke en interne un code nommé « DID » dont il nous faut récupérer la valeur pour alimenter le paramètre suscité.

Pour récupérer la valeur de ce code « DID », normalement un simple clic gauche sur le cadenas situé à gauche de la barre d’URL du navigateur, suivi de la sélection de l’item « cookies » permet d’afficher ce code « DID ». Sauf que cela ne marche pas avec le navigateur FireFox. Pour contourner le problème, j’ai installé l’excellent module complémentaire « Cookie Quick Manager » dans FireFox. Ensuite on procède ainsi :

• ·         Se placer sur la page de connexion ou si déjà connecté, sur la page du navigateur affichant le bureau DSM de votre NAS.
• ·         Dans le popup de « Cookie Quick Manager », clic gauche et sélectionner l’item « Rechercher les cookies pour : URL de la page suscitée ». Cela peut-être selon : « https://nom-du-nas.ndd.tld » ou http://@IP_du_NAS:5000 ou encore « https://@IP_du_NAS:5001 ».
• ·         Une nouvelle page s’ouvre dans le navigateur, vous montrant tous le détail du cookie associé à la page du NAS.
• ·         Dans la partie droite de cette page, on trouve la valeur du fameux code « DID ».
• ·         Sélectionnez et Copiez cette valeur et refermez la page du cookie.
• ·         Revenez sur la session SSH et tapez la commande suivante en y collant la valeur du « DID » :

$ export SYNO_DID=xxxxxxxxxxxxxxxValeur_du_DIDxxxxxxxxxxxxxxxxx

Edit du 10/01/2021

 

Suite au retour de plusieurs utilisateurs dont le renouvellement du certificat avait échoué avec un message du style :

« Tue Dec 15 15:58:28 CET 2020] Unable to authenticate to localhost:5000 using http. [Tue Dec 15 15:58:28 CET 2020] Check your username and password. »

voici la « parade ».

En fait, ce message survient parce que le cookie DID est périmé. Il s’avère qu’il n’a en fait qu’une durée de vie d’un mois et qu’il change donc tous les mois.

Aussi, toute l’astuce va être d’aller éditer le cookie et de modifier sa date de péremption pour la repousser aux « calandres grecques ».

Donc pour cela, comme expliqué ci-avant, vous éditez le cookie DID et vous modifiez le champ « expire » en indiquant une date en 2050 par exemple. Cela devrait suffire 😀.

Dans le cas, où le cookie DID aurait changé, il vous faut alors aller modifier, dans une session SSH sous l’utilisateur « root » avec PuTTY ou WinSCP sur Windows ou dans un Terminal sur Mac, le fichier « /volume1/Certs/votre-domaine.tld/votre-domaine.tld.conf » pour mettre en accord la valeur de votre nouveau cookie DID avec le contenu de la variable « SAVED_SYNO_DID » sauvegardée par le système dans ce fichier.

Ajout du 2021-02-15 : Il faut aussi mettre en accord la variable « SAVED_DID » qui se trouve elle, dans le fichier « /usr/local/share/acme.sh/account.conf ».

Toujours pareil, attention lors du copier/coller de la valeur à ne pas prendre de caractères parasites !

N’oubliez pas aussi d’enregistrer le fichier à l’issue de vos modifications.

Ainsi, plus de soucis de renouvellement à ce niveau …

 

5.2        Réalisation du déploiement du certificat

Nota préliminaire : Tout ce qui suit présume que vous n’avez pas quitté la présente session SSH. Sinon, il faut réexporter toutes les variables définies précédemment. Sans quoi rien ne fonctionnera correctement ! Ce serait dommage, non ?

Maintenant, deux cas de figure se présentent selon que l’on procède à un déploiement du nouveau certificat :

• ·         avec un mode « Annule et remplace » du certificat existant marqué « par défaut »,
• ·         ou que l’on se contente d’ajouter simplement le nouveau certificat à la liste existante de vos certificats.

Vous avez le choix, c’est vous qui décidez …

5.2.1        Mode « annule et remplace » du certificat par défaut

Rappel : Ici on va ECRASER le certificat marqué par défaut dans le tableau de bord de DSM. Il n’existera plus !!! Vous êtes prévenus …

• ·         Dans la session SSH tapez successivement les commandes suivantes :

o   Par prudence, on vérifie que l’on est bien toujours placé dans le répertoire : « /usr/local/share/acme.sh ».

$ pwd

o   Selon votre usage, décommentez et exécutez l’une ou deux ou les trois commandes suivantes :

# export SYNO_Scheme="http"
Par défaut : « http » mais on peut fixer à « https »

# export SYNO_Hostname="localhost"
Par défaut : « localhost » mais à spécifier si vous n’utilisez pas sur la présence machine. Les « très initiés » comprendront.

# export SYNO_Port="5000"
Port utilisé pour DSM, par défaut : 5000 pour HTTP et mais on peut fixer à 5001 pour HTTPS.

o   On poursuit les définitions de variables d’environnement :

Attention ici, les « simples cotes » « ' » sont utilisées pour « échapper » les éventuels caractères spéciaux présents dans vos identifiants et mots de masse.

$ export SYNO_Username='DSM_Admin_Username'

$ export SYNO_Password='DSM_Admin_Password!123'

La commande suivante est quant à elle impérative. Elle correspond à la description du certificat visible dans le tableau de bord de DSM. Toutefois pour pouvoir remplacer le certificat par défaut, il est nécessaire de spécifier une chaîne vide pour ce paramètre. Ne me demandez pas pourquoi ! (si un « initié » sait, je corrigerai en conséquence avec l’explication du pourquoi).

$ export SYNO_Certificate=""

·         Et on déploie enfin le certificat …

$ ./acme.sh --deploy -d "$CERT_DOMAIN" --deploy-hook synology_dsm

 

5.2.2        Mode « ajout » du nouveau certificat

Ici, on va simplement ajouter le nouveau certificat à la liste des certificats éventuellement déjà présents sur le NAS.

Le processus est sensiblement le même que celui décrit au §5.2.1 ci-dessus.

• ·         Dans la session SSH tapez successivement les commandes suivantes :

o   Par prudence, on vérifie que l’on est bien toujours placé dans le répertoire : « /usr/local/share/acme.sh ».

$ pwd

o   Selon votre usage, décommentez et exécutez l’une ou deux ou les trois commandes suivantes :

Par défaut : « http » mais on peut fixer à « https »

# export SYNO_Scheme="http"

Par défaut : « localhost » mais à spécifier si vous n’utilisez pas sur la présence machine. Les « très initiés » comprendront.

# export SYNO_Hostname="localhost"

Port utilisé pour DSM, par défaut : 5000 pour HTTP et mais on peut fixer à 5001 pour HTTPS (dans ce dernier, il faut ajouter l'option "--insecure" à la commande de déploiement donnée plus loin).

# export SYNO_Port="5000"

o   On poursuit les définitions de variables d’environnement :

Attention ici, les « simples cotes » « ' » sont utilisées pour « échapper » les éventuels caractères spéciaux présents dans vos identifiants et mots de masse.

$ export SYNO_Username='DSM_Admin_Username'

$ export SYNO_Password='DSM_Admin_Password!123'

 

La commande suivante est quant à elle impérative. Elle correspond à la description du certificat visible dans le tableau de bord de DSM. Toutefois pour pouvoir ajouter le nouveau certificat, il est nécessaire de spécifier une chaîne non vide pour ce paramètre. Là, cela paraît évident … (Quoi que …)

Vous nommez votre certificat comme bon vous semble. Pour ma part je lui donne le nom qui précise mon domaine « ACME_Wilcard_LE_*.ndd.tld » pour plus de clarté. Encore une fois, c’est vous qui voyez …

$ export SYNO_Certificate="Nom_du_certificat"

o   Une dernière variable d’environnement :

Par défaut : ce paramètre est sur « off » et n’est pas enregistré mais on peut le fixer à « 1 » pour indiquer au système de créer le certificat s’il n’existe pas déjà.

$ export SYNO_Create=1
 

·         Et on déploie enfin le certificat …

$ ./acme.sh --deploy -d "$CERT_DOMAIN" --deploy-hook synology_dsm

Dans cette commande, pour le cas où vous le souhaiteriez, on peut préciser un domaine de second niveau. La commande est alors :

$ ./acme.sh --deploy -d "secondNiv.$CERT_DOMAIN" --deploy-hook synology_dsm

Nota : On peut remarquer dans le message ci-dessus la ligne : « http services were NOT restarded », ne sachant pas ce qu’il faut en faire, je l’ai provisoirement ignorée. Je n’ai d’ailleurs pas constaté par la suite de disfonctionnements qui lui soient liés.

Cela dit, je compte sur les « initiés » pour me dire s’il y a une quelconque action à exécuter vis-à-vis de ce message. D’avance merci, je mettrai à jour la présente procédure en conséquence.

 

Toujours est-il, le nouveau certificat est maintenant visible dans « Panneau de configuration / Sécurité /Certificat » de DSM :

Ici par défaut on constate que :

• ·         d’une part le nouveau certificat a été automatiquement marqué pour une utilisation « par défaut »,
• ·   •   et d’autre part là, deux cas de figures peuvent se présenter :
  •         Soit vous êtes dans le cas d’une toute première création du certificat i.e. aucun autre certificat pour « votre-domaine.tld » n’existait auparavant, alors il est obligatoire de réaliser une affectation manuelle du certificat aux services qui vont l’utiliser pour une bonne prise en compte de celui-ci. Pour cela :
    •        Sélectionnez le certificat.
    •        Cliquez sur le bouton « Configurer » et affectez le certificat aux services de votre choix en le sélectionnant dans le popup en regard du service concerné.
  •        Soit vous êtes dans le cas d’une nouvelle création du certificat avec déjà un certificat pour « votre-domaine.tld » existant auparavant, alors avec cette création, le constat est qu’il n’a pas repris les assignations aux services qui existaient pour le certificat précédemment marqué par défaut. Il vous faut alors reprendre ces assignations manuellement. Toujours pareil, vous adaptez à votre besoin …

       Nota : Dans ce dernier cas, sachez que ce comportement est normal puisque l’on crée le certificat.

Un dernier constat : on ne le voit pas sur la copie d’écran, mais bien évidemment, le certificat précédemment marqué pour une utilisation par défaut, n’a pas disparu. Il est bien toujours présent dans la liste des certificats. Il n’est tout simplement plus marqué pour une utilisation par défaut. Rien n’a été perdu, c’est ce qui importe !

NE PAS quitter la session SSH

 

6         Configurer le renouvellement du certificat

Maintenant que le certificat « wilcard » LE a été créé et déployé sur le NAS, il faut assurer son renouvellement à l’échéance fatidique de 3 mois. En fait, cette échéance est variable dans le sens où selon la date de génération du certificat il peut se passer entre 89, 90, 91 et 92 jours. Mais en pratique lors de son exécution, le script « acme.sh » contrôle par défaut si la date courante est supérieure de plus de 60 jours par rapport à la date de création du certificat avant de lancer ou non le renouvellement effectif de celui-ci.

Par sécurité, on ne va pas « s’embêter », on va programmer tout simplement cette opération de contrôle du besoin de renouvellement, avec une exécution hebdomadaire à un horaire de faible charge du NAS (par exemple tous les Lundi et donc a priori la nuit soit à 00h00). Libre à vous de modifier cette périodicité selon vos propres besoins. C’est vous qui voyez …

Mais avant toute choses, on va installer un petit programme/script écrit en langage Python (Encore MERCI à @bruno78 qui l’a développé) destiné à compléter l’action normale du script « acme.sh » en réalisant un certain nombre d’autres opérations spécifiques et rendues nécessaires par l’environnement du NAS Synology (pour les plus curieux, ces actions sont explicitées en détail au § 10 ci-dessous).

Rassurez-vous, vous n’avez pas besoin de connaître le langage Python. Celui-ci est nativement géré par le NAS Synology au travers du package « Python module ». Vérifiez juste que ce package est bien installé sur votre NAS et auquel cas installez le via le centre de paquets.

EDIT 21/08/2020

Le script Python est maintenant compatible de la dernière et actuelle version 3.x.x du langage Python. Si vous envisagez d’utiliser Python3 il vous faut alors installer le package « Python3 » disponible dans la rubrique « Outils de développement » dans le centre de paquets de DSM.

Donc, le package « Python module » ou le package « Python3 » étant installé :

 

• Créez un répertoire spécifique pour accueillir ce script Python :
  • On crée le répertoire : « /volume1/Scripts » et on s’y place :

Nota 1 : Ce chemin peut être tout autre selon vos besoins, mais veillez à rester cohérent dans son utilisation par la suite.
Nota 2 : Ce répertoire, tout comme le répertoire « Volume1/Certs » créé précédemment, n’est pas un répertoire partagé au sens Synology. De fait, il ne sera donc pas visible sous « File Station » par exemple ce qui quelque part le protège de vos utilisateurs. Il ne sera donc visible qu’au travers d’une connexion directe au NAS dans une session SSH sous l’utilisateur « root ».

$ cd /volume1
$ mkdir -p Scripts
$ cd Scripts

• Téléchargez sur votre PC/Mac le fichier du script Python : acme_renew.py
• Copiez/Collez ce fichier sur le NAS dans le répertoire « /volume1/Scripts ». (via WinSCP c’est on ne peut plus simple !).

Le script Python étant en place, on va programmer effectivement l’exécution périodique de ce script.

Nota :En préalable et pour ceux qui seraient tentés de le faire, il faut également savoir qu’Il n'est pas conseillé de configurer directement un « cron job » personnalisé car le conseiller de sécurité DSM va rapidement vous rappeler à l’ordre et vous dira que vous avez un avertissement critique concernant un ou des cron job(s) inconnu(s).

Donc pour ce faire, on va configurer une tâche dans le planificateur de tâches de DSM.

• ·         Dans « Panneau de configuration / Planificateur de tâches », cliquer sur le bouton « Créer » et sélectionner dans le popup : « Tâche planifiée / Script défini par l’utilisateur »

• ·         Dans la fenêtre « Créer une tâche » onglet « Général » nommez la tâche à exécuter périodiquement. Par exemple : « RenewCertif_W_LE ». L’utilisateur doit être « root » et la case « Activé » est cochée.

• ·         Dans l’onglet « Paramètres de la tâche » :

o   Pour la partie « Paramètres généraux » : si vous voulez recevoir par eMail les détails d’exécution de la tâche : cochez la case correspondante et saisissez votre @Mail. Vous pouvez aussi décider de ne recevoir ces eMails uniquement si l’exécution de la tâche se termine de façon anormale. Dans ce cas cochez la case correspondante.

o   Pour la partie « Exécuter la commande » : saisir la commande suivante :

python /volume1/Scripts/acme_renew.py -l votre-domaine.tld

Ou si vous souhaitez utiliser la version sous « Python3 » :

python3 /volume1/Scripts/acme_renew.py -l votre-domaine.tld

Dans cette commande :

-  Le chemin d’accès au script « acme_renew.py » (ici « /volume1/Scripts/ ») devra être modifié selon que vous en aurez défini un autre ci-avant.

-  Le paramètre « -l » est quant à lui optionnel. Libre à vous de l’indiquer ou pas. Néanmois je ne peux que vous conseiller de le mentionner pour le cas où … On n’est jamais trop prudent. Si vous l’indiquez explicitement, sachez qu’à chaque renouvellement, un fichier de « log » nommé « acmelog » sera automatiquement généré dans le répertoire « /volume1/Certs/Acme_renew/ » lui-même créé automatiquement par le script Python. Donc si un quelconque problème survenait, vous disposerez alors d’une trace complète de toutes les opérations réalisées lors du processus de renouvellement du certificat« wilcard » LE. Si tout est OK, vous aurez tout de même une trace mais forcément « light ».

-  Le paramètre « votre-domaine.tld » est quant à lui OBLIGATOIRE et est bien évidemment à remplacer par l’intitulé de votre propre domaine pour lequel le certificat doit être renouvelé.

• ·         Dans l’onglet « Programmer » :

o   Sélectionner « Exécuter les jours suivants »

o   Dans le popup, cochez la case « Lundi ».

o   Dans la zone « Temps » : laisser les valeurs par défaut.

• ·         Valider l’ensemble de votre paramétrage en cliquant sur le bouton « OK ».

EDIT du 20/06/2021 : Suite aux récentes évolutions du Shel script ACME (voir plus haut pour la commande de création du certificat) il n'y a normalement rien à faire si vous disposer déjà d'un certificat LE. Le Shell script ACME de lui même s'adapte et assure le rouvellement de votre certificat comme avant. Toutefois, afin de s'assurer et forcer ce renouvellement avec LetEncrypt, il convient d'ajouter (sous SSH à la fin du fichier) la ligne suivante dans votre fichier "account.conf" (/usr/local/share/acme.sh/account.conf) :

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

 

 

7         En cas de problème suite à une mise à jour de DSM

En cas de problème suite à une mise à jour de DSM, on peut réparer l’environnement ACME en exécutant les commandes suivantes dans une session SSH sous l’utilisateur « root » :

$ cd /usr/local/share/acme.sh

$ ./acme.sh --force --upgrade --nocron --home /usr/local/share/acme.sh
 

Vous pouvez aussi ajouter la ligne suivante dans le fichier « /root/.profile » et régénérer le « .profile » en tapant :

. "/usr/local/share/acme.sh/acme.sh.env"

$ source /root/.profile

8         Arrêter le renouvellement du certificat

Pour arrêter le renouvellement d’un certificat, vous pouvez exécuter dans une session SSH sous l’utilisateur « root » , les commandes suivantes pour supprimer le certificat de la liste de renouvellement :

$ cd /usr/local/share/acme.sh

$ ./acme.sh --remove -d votre-domaine.tld
 

Les fichiers « .cert » et « .key » de votre certificat ne sont pas supprimés du disque.

Vous pouvez supprimer le répertoire correspondant (par exemple : « /volume1/Certs/votre-domaine.tld ») par vous-même.

9         Un dernier truc utile

Vous pouvez éventuellement avoir besoin de convertir votre certificat en un fichier « .p12 » ou « .pfx » exploitable sous Android. C’est utile par exemple, pour un client VPN installé sur le smartphone.

Dans ce cas, vous pouvez exécuter dans une session SSH sous l’utilisateur « root » , les commandes suivantes :

$ ACME_HOME="/usr/local/share/acme.sh"

$ CERT_HOME="/volume1/Certs"

$ cd $ACME_HOME

$ ./acme.sh --toPkcs -d votre-domaine.tld
 

Enter Export Password:

Verifying - Enter Export Password:

[Mon May 25 20:00:28 CEST 2020] Success, Pfx is exported to: /volume1/Certs/votre-domaine.tld/votre-domaine.tld.pfx

« Password » est le mot de passe utilisé pour ouvrir la session SSH.

 

10 Évolution du processus de renouvellement du certificat

EDIT du 11/08/2020 et du 21/08/2020

• Afin d’améliorer la recherche de la (les) cause(s) d’un éventuel dysfonctionnement dans le processus de renouvellement du certificat, la trace complète de toutes les opérations effectuées lors du déroulement de ce processus a été remaniée de façon à fournir un historique « tournant ». Ces informations sont inscrites dans un fichier nommé « acme_renew_python.log.x » qui est automatiquement généré dans le répertoire « /volume1/Certs/Acme_renew ». Cette trace est systématiquement générée que vous utilisiez ou non l’option « -l » pour obtenir un « log » du processus.  Au total, vous disposerez de neuf (9) fichiers de trace sachant que le fichier ayant l’indice « 1 » sera toujours celui correspondant à la dernière exécution du script, donc le plus récent.
• Si pour une quelconque raison vous aviez besoin de renouveler votre certificat LE avant sa date normale de renouvellement, une option dédiée à cet effet à été ajoutée au script Python (v1.40). Cette option « -f » ou « --force » doit toutefois être utilisée avec parcimonie. En effet, LetsEncript limite le nombre de modifications d’un certificat d’un même domaine à cinq (5) par semaines calendaires. Au-delà de ces cinq (5) modifications dans une même semaine, vous serez bloqués et ne pourrez pas renouveler votre certificat durant une semaine à compter de la dernière modification tentée. Vous êtes donc prévenus ...

EDIT du 25/07/2020
Suite aux retours de plusieurs utilisateurs « initiés », il a été fait le constat que le processus de renouvellement du certificat tel qu’il existait, n’était pas pleinement satisfaisant.

En effet, même si en apparence le certificat semblait renouvelé dans le « Panneau de configuration / Sécurité / Certificat » avec une nouvelle date d’expiration affichée en vert et qu’il était bien marqué « par défaut », en fait il ne l’était pas complétement. À l’usage il générait encore des messages liés à une connexion non sécurisée avec une erreur du type « SLL_ERROR_BAD_CERT_DOMAIN ». La raison en était que les fichiers « .pem » du nouveau certificat n’avaient en fait, pas été recopiés partout où ils auraient dû l’être et du coup les navigateurs Web utilisaient toujours les anciens fichiers.

Pour les plus sceptiques vis-à-vis de cette apparence trompeuse et pour bien se rendre compte que c’était toujours l’ancien certificat qui était pris en compte par les navigateurs Web, il suffit effectuer les manipulations suivantes :

• Effacer le cache du navigateur Web.
• Recharger le site web consulté où l’erreur SSL était apparue.
• Examiner le certificat utilisé par le navigateur dans ce cas.
• On constate que c’est toujours l’ancien certificat à la vue de sa date d’expiration.

On obtient aussi la preuve que le processus de renouvellement pour le cas particulier de l’environnement du NAS Synology n’était pas complet, en examinant via une connexion SSH sous « root », les fichiers « .pem » contenus dans le répertoire « /usr/local/etc/certificate/WebStation/vhost_xxxxxx ». Ces fichiers correspondaient exactement à l’ancien certificat.

Par ailleurs, après sa création et/ou son renouvellement, il avait été constaté que le nouveau certificat n’était pas non plus, appliqué et/ou réappliqué aux services à l'image de ce qui existait pour le certificat précédemment actif et marqué par défaut. Il fallait alors reprendre manuellement via le menu « Configurer », toutes les affectations de ce nouveau certificat aux différents services qui l’utilisaient. Opération laborieuse s’il en était …

Nota : Je vous rappelle si besoin en est, qu’après toute création du certificat (qu’il en existe déjà un ou non pour « votre-domaine.tld »), cette opération d’affectation du certificat aux services est obligatoire pour la bonne prise en compte de celui-ci.

Vous en conviendrez donc, du point de vue automatisation ce n’était pas top ! 🤔

Ces différents problèmes nous ont donc conduits @bruno78 et moi-même à plancher sur une automatisation COMPLETE de la procédure de renouvellement du certificat et il faut bien le dire ici, sans les talents de développeur de @bruno78, nous n’aurions pas aujourd’hui une procédure pleinement fonctionnelle et efficiente.

Donc, @bruno78 a développé un script en langage Python nommé « acme_renew.py » qui réalise maintenant correctement tout le « boulot » si je puis dire.

À noter que ce script dispose également de certaines fonctionnalités disponibles uniquement dans le cadre une utilisation manuelle en mode SSH sous « root » que je vais vous détailler plus loin.

Pour d’ores et déjà satisfaire la curiosité des utilisateurs « initiés », de façon succincte, ce script Python réalise les opérations suivantes :

• Lecture des fichiers « INFO » et « DEFAULT » (« /usr/syno/etc/certificate/_archive »)
• Vérification de l’atteinte ou non de la date de renouvellement (minimum T0+60 jours, valeur par défaut inscrite dans le code du Shell script « acme.sh »).
• Sauvegarde du répertoire « /usr/syno/etc/certificate/_archive » y compris des fichiers « INFO » et « DEFAULT »
• Récupération des services du certificat originel par défaut selon qu’il a été généré avec une clé de chiffrement de type RSA ou ECDSA.
• Renouvellement du certificat : On reprend ici la commande originelle de renouvellement du script « acme.sh » à laquelle on a ajouté des paramètres spécifiques (« /usr/local/share/acme.sh/acme.sh --cron –force –debug --log --home /usr/local/share/acme.sh/ ») :
  • « --force » pour le forcer à renouveler le certificat (la simple option « –renew » n’est pas suffisante car elle génère un message d’erreur qui stipule de surcroît d’utiliser l’option « --force », donc on applique cette option directement).
  • « --debug » pour avoir un maximum de messages de traçage des opérations réalisées.
  • « --log » pour récupérer les messages générés dans un fichier « Log » de trace.
• Lecture des nouveaux fichiers « INFO » et « DEFAULT » générés suite au renouvellement.
• Mise à jour du fichier « INFO » en inscrivant les services sur le nouveau certificat « par défaut »
• Renommage de la description de l'ancien certificat en "xxx_old".
• Distribution les nouveaux fichiers du certificat dans les répertoires système du NAS « /usr/syno/etc/certificate » et « /usr/local/etc/certificate ».
• Recherche et constitution de la liste des packages et services qui utilisent le certificat.
• Redémarrage global de ces packages et services en incluant leurs dépendances.

Donc comme évoqué précédemment, le script Python « acme_renew.py » peut être utilisé selon deux modes de fonctionnement :

1. En mode dit « Standard ou automatique » : c’est celui qui est typiquement utilisé pour la commande de renouvellement intégrée à la tâche périodique que vous avez définie dans DSM au § 6 ci-dessus et dans lequel la description des paramètres que le script accepte, est précisée. Veuillez-vous y reporter.
2. En mode dit « Manuel » : ce mode correspond à une utilisation directe en lignes de commandes dans une connexion au NAS via une session SSH sous l’utilisateur « root ».

Donc, ouvrez une connexion SSH sous « root » et tapez les commandes suivantes :

$ cd /volume1/Scripts

$ python acme_renew.py -h

Avec ce paramètre « -h » vous obtenez une aide sur tous les paramètres utilisables avec le script Python « acme_renew.py » :

Citation

/volume1/Scripts$ python acme_renew.py -h

usage:

  $python|python3 acme_renew.py [-v] [-h]

  $python|python3 acme_renew.py [-c] [-l] [-f] [-t] ndd.tld

> Utilisation standard dans le planificateur de taches : il est conseille d'executer le script 1 fois par semaine

  sachant que le renouvellement effectif n'aura lieu que lorsque la date T0+60 jours sera passee

    * dans Parametres de tache > Executer la commande > script defini par l'utilisateur :

          python|python3 <votre chemin>/acme_renew.py ndd.tld

    * ou avec generation d'un log (-l ou --log) : il s'agit du log du script acme.sh

          python|python3 <votre chemin>/acme_renew.py -l ndd.tld

> Utilisation pour tests lors d'une session ssh :

  Le parametre -l (--log) , peut etre utilise en plus de -t (--test)

  Ce log ne concerne que le script acme.sh, pas l'ensemble python

          python|python3 <votre chemin>/acme_renew.py [-l] [-t] ndd.tld

  * force : -f --force : force le renouvellement effectif du certificat, meme si on n'est pas arrive a la date de renouvellement.

                         Le parametre -t (--test) est alors ignore

          python|python3 <votre chemin>/acme_renew.py [-l] -f ndd.tld

          Attention : LetsEncrypt n'autorise que 5 renouvellements de certificat par semaine. Au dela, vous serez bloque.        

> Utilisation pour nettoyer les fichiers log et sauvegardes lors d'une session ssh :

          python|python3 <votre chemin>/acme_renew.py -c ndd.tld          

> Un log dedie au script Python est genere, dans tous les cas : /volume1/Certs/Acme_renew/acme_renew_python.log.x [x de 1 a 9]

> Compatible Python2 <python acme_renew.py ....> et Python3 <python3 acme_renew.py ...>

Argument de Position:

  nddtld         Nom de domaine ndd.tld a traiter pour le renouvellement de certificat

Arguments Optionels:

  -v, --version  Affiche la version du programme et arrete le script

  -h, --help      Montre ce message et arrete le script

  -c, --clean    Effacement de tous les fichiers logs du script, toutes dates,

                       ainsi que des fichiers de sauvegarde crees lors des

                       renouvellements de certificats. Les autres options sont

                       ignorees, le ndd.tld reste obligatoire. Demande confirmation

                        interactive avant la suppression des fichiers. Default =

                        False

  -l, --log         Generation du fichier log lors de l'execution de la commande

                        acme.sh. Default = False

  -f, --force     Force le renouvellement du certificat meme si la date

                        d'expiration n'est pas atteinte. Attention : maximum 5

                        renouvellements par semaine autorises pas LetsEncrypt.

                        Default = False

  -t, --test       Execute le script en mode "test / a blanc". La configuration

                       est analysee, mais aucun renouvellement n'a lieu et aucun

                       fichier n'est modifie. Default = False (c’est-à-dire execution reelle du script)

Les informations fournies par cette option « -h » se suffisent à elles-mêmes. Elles ne seront donc pas décrites/détaillées plus avant.

Nota : Dans cette aide le paramètre « ndd.tld » correspond bien évidemment à « l’intitulé » de votre domaine soit « votre-domaine.tld ».

Toutefois, dans le cas particulier d’une utilisation avec le paramètre « -c » il convient de préciser ceci : En aucun cas vous ne devez utiliser la commande « python acme_renew.py -c votre-domaine.tld » ou « python3 acme_renew.py -c votre-domaine.tld » dans une fenêtre de console sous WinSCP !

La raison en est, que la console de WinSCP ne supporte pas l’exécution de commandes dites « interactives ». Si d’aventure vous faisiez cette erreur, sachez que vous allez entrer dans une boucle sans fin et que le seul moyen d’en sortir sera de « tuer » le process WinSCP dans le gestionnaire de tâches de Windows. Maintenant vous êtes prévenus !

Par contre, il n’y a aucun souci pour exécuter cette commande interactive dans une fenêtre « Terminal » de PuTTY sur PC (même si celle-ci est lancée à partir de WinSCP) ou d’une fenêtre « Terminal » sur Mac.

 

Voilà c’est fini, profitez bien de votre certificat « wilcard » Let’sEncrypt !!! GRATUIT !!! et ne nécessitant plus d’ouvrir les ports 80 et/ou 443 sur votre NAS pour son renouvellement. À l’usage, on en oublierait presque la chose …

Le fichier ".pdf" de cette procédure : Création_Certif_Wilcard_LE_avec_ACME_20210215.pdf

Bien évidemment, je prendrais en compte toutes remarques et suggestions visant à corriger si besoin mais surtout à améliorer ce tutoriel. MERCI de vos retours ...

Merci à @maxou56 pour ses compléments d’informations liées au monde Mac.

Cordialement

Oracle7😉

 

Modifié le 20 juin 2021 par oracle7
Evolutions ACME.sh avec ZeroSSL et LetEncrypt

[alan.dub]

Impressionnant ! 😀

Bravo ! 😀 

[bruno78]

Merci @oracle7 pour ce super Tuto .....

je suis bloqué à l'étape de création du Certificat .... c'est ballot !

• tout d'abord, via putty et après sudo -i pour passer en root, je me fais jeter sur certaine commandes ./acme.sh :

root@ds918blam:/usr/local/share/acme.sh# ./acme.sh --upgrade --auto-upgrade
It seems that you are using sudo, please read this link first:
https://github.com/acmesh-official/acme.sh/wiki/sudo

idem pour la création du certificat. Du coup obligé d'utiliser l'option

--force

• ensuite, sur OVH, je n'ai réussi à créer les API Keys qu'avec mon identifiant OVH, mais pas avec mon login (email).
• et au final, en generant le certificat avec --force et les APi Keys générées avec mon identifiant OVH, j'ai l'erreur suivante (ndd masqué avec xxxx) ainsi que les clés:

[Sat May 30 16:34:13 CEST 2020] Adding txt value: xxxxxxxxxxxxxxxxxx-0Y2a290 for domain:  _acme-challenge.xxxx.eu
[Sat May 30 16:34:13 CEST 2020] Using OVH endpoint: ovh-eu
[Sat May 30 16:34:13 CEST 2020] OVH_API='https://eu.api.ovh.com/1.0'
[Sat May 30 16:34:13 CEST 2020] Checking authentication
[Sat May 30 16:34:13 CEST 2020] domain
[Sat May 30 16:34:13 CEST 2020] GET
[Sat May 30 16:34:13 CEST 2020] url='https://eu.api.ovh.com/1.0/auth/time'
[Sat May 30 16:34:13 CEST 2020] timeout=30
[Sat May 30 16:34:13 CEST 2020] _CURL='curl -L --silent --dump-header /usr/local/share/acme.sh/http.header  -g  --connect-timeout 30'
[Sat May 30 16:34:13 CEST 2020] Please refer to https://curl.haxx.se/libcurl/c/libcurl-errors.html for error code: 60
[Sat May 30 16:34:13 CEST 2020] ret='60'
[Sat May 30 16:34:13 CEST 2020] _ovh_p='[hidden](please add '--output-insecure' to see this value)'
[Sat May 30 16:34:13 CEST 2020] GET
[Sat May 30 16:34:13 CEST 2020] url='https://eu.api.ovh.com/1.0/domain'
[Sat May 30 16:34:13 CEST 2020] timeout=
[Sat May 30 16:34:13 CEST 2020] _CURL='curl -L --silent --dump-header /usr/local/share/acme.sh/http.header  -g '
[Sat May 30 16:34:13 CEST 2020] Please refer to https://curl.haxx.se/libcurl/c/libcurl-errors.html for error code: 60
[Sat May 30 16:34:13 CEST 2020] ret='60'
[Sat May 30 16:34:13 CEST 2020] error
[Sat May 30 16:34:13 CEST 2020] The consumer key is invalid: OlZrPWfCuyLxxxxxxxxxxxxxxxxx
[Sat May 30 16:34:13 CEST 2020] Please retry to create a new one.
[Sat May 30 16:34:13 CEST 2020] Error add txt for domain:_acme-challenge.xxxx.eu

J'ai recréé 2 fois les API Keys, toujours la même erreur. Je cherche .....

[oracle7]

@bruno78

Bonjour,

Désolé pour toi, je crois que tu es le premier à "essuyer les plâtres" 😩

Si tu as utilisé 'sudo -i' c'est que je devines que tu es sur Mac, effectivement c'est la méthode à utiliser pour passer sous 'root' dans cet environnement. En cela, tu as raison. Comme je ne travailles pas sous Mac, je n'ai pu tester la méthode que j'ai décrite dans cet environnement. J'ai fourni ce moyen croyant que ce serait identique puisque en principe les commandes Shell s'appliquent sur le noyau du NAS.

Puisque que cela ne marche pas ('sudo -i'), je t'invite à suivre le Tuto de @unPixel sur les "Accès SSH et ROOT via DSM6" et ainsi te configurer un accès par le "vrai" root. Là cela devrait le faire ...

Dis-moi le résultat en retour, si cela passe alors je modifierai en conséquence le tutoriel pour avertir les utilisateurs Mac du problème.

Pour ce qui est de l'erreur liée à ta "consumer key" : vérifie que tu l'as bien copiée dans la variable OVK_CK lors de son export. Je veux dire pas là, vérifies que tu n'as pas introduit de caractères parasites lors du C/C. Souvent c'est un blanc ou un fin de ligne invisible qui perturbe, du coup la chaine est différente et d'où l'erreur ...

Cordialement

oracle7😉

[Jeff777]

Waouh quel boulot !

Merci @oracle7 . Comme j'ai pour l'instant échoué dans le renouvellement de ma wildcard avec la méthode de @.Shad. en utilisant Docker, je suis bien sûr intéressé par celle-ci d'autant plus qu'elle permet le renouvellement automatique.

Par contre j'ai un doute j'ai bien un domaine chez OVH mais je n'utilise pas leurs DNS (donc je n'ai pas de zone chez OVH) mais DNS serveur sur le NAS et comme DNS secondaire HE (Hurricane Electric).

Est-ce que tu penses que cela peut fonctionner ?

Modifié le 30 mai 2020 par Jeff777

[oracle7]

@Jeff777

Bonjour,

il y a 7 minutes, Jeff777 a dit :

Par contre j'ai un doute j'ai bien un domaine chez OVH mais je n'utilise pas leurs DNS (donc je n'ai pas de zone chez OVH) mais DNS serveur sur le NAS et comme DNS secondaire HE (Hurricane Electric).

Est-ce que tu penses que cela peut fonctionner ?

En principe, l'ouverture de ton domaine "ndd.tld" chez OVH a dû créer automatiquement dans ta Zone DNS, 2 enregistrements "NS" vers les serveurs d'OVH : dns112.ovh.net et ns112.ovh.net. Donc ta Zone DNS chez OVH n'est normalement pas "vide" même si tu ne l'utilises pas.

Du coup, je penses que cela devrait le faire si tu respectes les pré-requis du §1 d'une part et dans ton cas personnel, il me semble qu'il te faudra d'autre part ajouter à minima dans ta Zone DNS chez OVH, un enregistrement CNAME avec "*.ndd.tld." pointant vers "ndd.tld.".

A essayer donc ...

Cordialement

oracle7😉

[bruno78]

Merco @oracle7

effectivement

• si on ne se trompe pas dans la génération des API Keys ni en les recopiant,
• et si on utilise la "vraie" connexion root (càd avec les clés ssh comme tu me l'as indiqué cf tuto "Accès SSH et ROOT via DSM6") et non pas du sudo

alors ca fonctionne !! Il me reste maintenant à déployer le certificat ...

Merci

[bruno78]

Déployement Nickel !!

Merci

[oracle7]

@bruno78

Merci de ton retour, c'est super !

Du coup, grâce à toi (si je puis dire), j'ai modifié le Tuto en ajoutant un avertissement à destination des utilisateurs Mac au §2.

Cordialement

oracle7😉

[Jeff777]

Il y a 1 heure, oracle7 a dit :

En principe, l'ouverture de ton domaine "ndd.tld" chez OVH a dû créer automatiquement dans ta Zone DNS, 2 enregistrements "NS" vers les serveurs d'OVH : dns112.ovh.net et ns112.ovh.net.

Et non puisque je fais partie de ces fous qui ont suivi le tuto de Fenrir jusqu'au bout.

OVH ne fait que me fournir un domaine. Mes DNS sont "DNS Serveur" et "HE" en secondaire. Dans ce cas ma zone est sur mon NAS et transférée chez HE.

 

Il y a 1 heure, oracle7 a dit :

Du coup, je penses que cela devrait le faire si tu respectes les pré-requis du §1 d'une part et dans ton cas personnel, il me semble qu'il te faudra d'autre part ajouter à minima dans ta Zone DNS chez OVH, un enregistrement CNAME avec "*.ndd.tld." pointant vers "ndd.tld.".

Je n'ai donc pas de zone DNS chez OVH et ces enregistrements figurent déjà dans ma zone publique du NAS.

A savoir que c'est là que j'ai mis les enregistrements TXT pour obtenir ma wildcard chez SSLforfree.

Alors je pense que je vais tenter ton tuto qui de plus a été validé par bruno78.

Je te tiens informé.

 

[oracle7]

@Jeff777

Je ne connais malheureusement pas ton type de configuration, du coup je crains de ne pouvoir t'aider efficacement.

Cela dit, en y réfléchissant bien tu devrais pouvoir adapter mon Tuto et t'en sortir.

Bon courage et n'hésites pas me questionner.

Cordialement

oracle7😉

[.Shad.]

@Jeff777 Après quelques recherches, il semble que ce que tu essaies de faire ne soit pas possible, car pour ton cas tu dois passer par le DNS "Manual mode" qui ne permet pas d'ajouter automatiquement des enregistrements TXT dans ta zone DNS (voir https://github.com/acmesh-official/acme.sh/wiki/DNS-manual-mode)

Un moyen de contourner le problème serait d'utiliser un script, qui s'occuperait d'ajouter les enregistrements TXT entre les points 1 et 3 du lien ci-dessus.

J'ai aussi trouvé cet article là : https://fdiv.net/2016/06/23/tweaking-synology-dns-server-great-justice

On peut notamment y lire que le paquet DNS Serveur stocke ses fichiers de configuration de zone dans :

/volume1/@appstore/DNSServer/named/etc/zone/master

Si tu veux un exemple de zone DNS version ligne de commande, en réalité c'est basé sur BIND, qui est le logiciel de DNS par excellence, ça ressemble à quelque chose ainsi :

$TTL    604800
@       IN      SOA     ns.ubuntu-fr.lan admin.ubuntu-fr.lan (
                              1         ; Serial
                         604800         ; Refresh
                          86400         ; Retry
                        2419200         ; Expire
                         604800 )       ; Negative Cache TTL
;
@       IN      NS      ns.ubuntu-fr.lan.
NS      IN      A       10.10.10.10
box     IN      A       192.168.1.10

Au final, DSM se contente de mettre ça en interface visuelle.

Il "suffit" d'ajouter donc les enregistrements TXT par script à cette zone entre les étapes 1 et 3 de mon premier lien. Je mets des guillemets autour de "suffit" car ça dépasse mes compétences en shell pour faire ça proprement.

Pour tout le reste tu peux suivre le tutoriel.

 

Modifié le 30 mai 2020 par .Shad.

[Jeff777]

Merci de ton aide @.Shad.

En effet j'ai suivi le Tuto de @oracle7 jusqu'à la création du certificat et j'ai eu une erreur sur la ligne :

[Sun May 24 22:42:15 CEST 2020] Adding txt value: TLMxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxQWk for domain:  _acme-challenge.votre-domaine.tld

Pour info j'ai eu les quelques problèmes suivants. J'ai du forcer avec le paramètre  "--force" les instructions d'installation.

Pour l'API OVH, pour me connecter j'ai dû utiliser l'identifiant (l'email qui me sert normalement à me connecter ne fonctionnait pas)

Enfin j'ai bien sûr remplacé dns_ovh par mon dns soit ns.ndd.ovh dans la ligne :

$ export CERT_DNS="dns_ovh"

Si je pouvais utiliser un DNS de OVH comme dns secondaire cela permettrait peut-être de résoudre le problème mais ce n'est pas possible.

Bien sûr je pourrais changer mes DNS pour ceux de OVH mais cela condamnerait ma redondance de NAS.

Je vais regarder attentivement ce que tu me suggères.

 

[bruno78]

Bonjour,

je reviens sur la question du renouvellement tous les 3 mois.

• dans les tâches planifiées, on choisit une date à T0+85 jours, et on donne une période de 3 mois au script.
• Donc si je comprends bien, on aura un premier renouvellement dans 85  jours, mais le suivant ne sera que 3 mois après, et non pas 85 jours. Donc pas de marge ?
• Par ailleurs, j'ai fait un test du script ce matin. Ci-dessous le retour du script :

Tâche : Renew Certif LE WildCard
Heure de début : Sun, 31 May 2020 07:12:36 GMT
Heure d’arrêt : Sun, 31 May 2020 07:12:37 GMT
État actuel : 0 (Normal)
Sortie standard/erreur :
[Sun May 31 07:12:36 CEST 2020] ===Starting cron===
[Sun May 31 07:12:37 CEST 2020] Already uptodate!
[Sun May 31 07:12:37 CEST 2020] Upgrade success!
[Sun May 31 07:12:37 CEST 2020] Auto upgraded to: 2.8.6
[Sun May 31 07:12:37 CEST 2020] Renew: 'xxxxxxx.eu'
[Sun May 31 07:12:37 CEST 2020] Skip, Next renewal time is: Wed Jul 29 16:26:24 UTC 2020
[Sun May 31 07:12:37 CEST 2020] Add '--force' to force to renew.
[Sun May 31 07:12:37 CEST 2020] Skipped xxxxx.eu
[Sun May 31 07:12:37 CEST 2020] ===End cron===

Que faut'il en conclure ?

• Certificat créé hier, donc il "skip" la demande de renouvellement aujourd'hui estimant que c'est trop tôt, pas nécessaire  ?
• date de prochain renouvellement 29 juillet 16:26 UTC 2020, soit 60 jours après la création ?
• si on période de 3 mois pour la tache periodique est trop longue, puiqu'a priori on ne peut pas faire une tâche avec une période de 2 mois, alors une tâche planifiée mensuelle ne serait'elle pas la solution ?

Bruno78

@Jeff777,

j'ai eu exactement ce problème (devoir mettre --force).

En fait cela ne fonctionne pas même avec --force. Je suppose que tu as du passer en root avec un sudo ?

C'était mon cas (sur PC avec Putty, je passais par un compte admin puis sudo -i), et il a fallu, sur les conseils bien avisés d' @oracle7, que je configure une "vraie" connexion root (voir tuto "Accès SSH et ROOT via DSM6"). Ca te règlera au moins ce problème là. Pour le reste, c'est au delà de mes compétences actuelles .....

Bruno78

Modifié le 31 mai 2020 par bruno78
typo

[Jeff777]

@bruno78

J'étais sur putty  en root avec sudo -i.

Comme toi j'ai eu un warning qui me renvoyait sur une page web qui donnait comme solution d'employer le paramètre --force. Je ne suis pas sur Mac mais sur Windows 10.

Je n'avais pas vu que tu avais également eu le problème de connexion sur l'API  OVH avec l'email. 

Donc nous avons rencontré les mêmes difficultés cela ne dépend pas du système d'exploitation.

Ce soir j'essaierai le manual mode mais je n'aurai pas de renouvellement auto 😟

 

 

 

 

[Jeff777]

Edit :

Il y a 1 heure, bruno78 a dit :

En fait cela ne fonctionne pas même avec --force.

J'avais mal compris. Chez moi cela a marché avec force. C'est donc ça la différence avec MAC.

 

[bruno78]

Ah mais oui mais non, .... je n'avais pas fait attention à la remarque .... mais je suis également sur PC sous Win10. Donc sous Win10, avec putty, je n'ai pas réussi à faire fonctionner acme.sh même avec --force tant que je me connectais avec un compte admin "normal" puis avec sudo -i. Il a fallu que je passe une vraie connexion root/ssh pour que cela fonctionne correctement.

Désolé si j'ai pu laisser à penser que j'étais sous MAC .... . J'ai l'impression que quelle que soit la plateforme, il ne faut pas utiliser sudo dans ce genre d'opération.

Après, si tu dis que pour toi cela a fonctionné avec --force .... . très bien mais peut-être avons-nous d'autres différences de configuration qui font que cela a fonctionné chez toi ?

Mais ne serait-ce que pour la première commande, si exécutée sous sudo :

root@ds918blam:/usr/local/share/acme.sh# ./acme.sh --upgrade --auto-upgrade
It seems that you are using sudo, please read this link first:
https://github.com/acmesh-official/acme.sh/wiki/sudo
root@ds918blam:/usr/local/share/acme.sh#

Il fait une remarque sur l'utilisation du sudo, mais a priori pas d'erreur signalée. Et pourtant, si on va vérifier le fichier account.conf, on s'aperçoit que la commande n'a pas été exécutée, le fichier n'est pas mis à jour. Donc je crains que l'utilisation du sudo apporte des problèmes pas forcement très visibles (droits, .... ). C'est pour cela que du coup je ne saurais que trop recommander de ne pas utiliser sudo, et de n'utiliser que la connexion root/ssh, histoire d'être sûr à 100%

[Jeff777]

Bon effectivement j'avais doublement mal compris. En fait suite à la lecture du lien j'avais juste ajouté --force après l'instruction et cela avait fonctionné.

Je vais recommencer avec la connection root/ssh mais je doute que cela suffise dans mon cas.

[oracle7]

@bruno78

Bonjour,

Il y a 3 heures, bruno78 a dit :

Certificat créé hier, donc il "skip" la demande de renouvellement aujourd'hui estimant que c'est trop tôt, pas nécessaire  ?

Oui, cela me paraît logique comme comportement.

Il y a 3 heures, bruno78 a dit :

date de prochain renouvellement 29 juillet 16:26 UTC 2020, soit 60 jours après la création ?

C'est étonnant, chez moi il a bien pris en compte 3 mois : créé le 25/5/20020 --> validité 22/08/2020.

Il y a 3 heures, bruno78 a dit :

si on période de 3 mois pour la tache periodique est trop longue, puiqu'a priori on ne peut pas faire une tâche avec une période de 2 mois, alors une tâche planifiée mensuelle ne serait'elle pas la solution ?

Effectivement, j'ai constaté cela lors de la programmation de la tâche : j'ai donc choisi par défaut de sélectionner "tous les 3 mois" puisqu'il est impossible d'affiner.. Cela dit, je me demande si tu n'aurais pas tout compte fait raison, en proposant une tâche planifiée mensuelle.

Malheureusement, pour vérifier cela il nous faut attendre chaque échéance pour constater le comportement effectif. Je n'ai pas d'autre solution en magasin pour l'instant ... A moins que tu ais une idée ?

@Jeff777

Peut-être que dans ton cas la solution serait d'effectuer la création du certificat en mode "DNS manuel". Dans ce cas cela t'impose d'aller en plus créer à la main dans ta Zone DNS d'OVH les enregistrements "TXT" nécessaires, avec les valeurs reçues dans le message de retour lors de la création.

Je t'invite à regarder ce post où j'avais décrit la méthode par DNS Manuel lors de mes premiers errements sur le sujet. Certes, il te faudra adapter, mais l'essentiel y est. Au final, c'est peut-être bien un mixte de tout cela qui te conviendra personnellement. Enfin je te le souhaite...

 

Il y a 3 heures, Jeff777 a dit :

Enfin j'ai bien sûr remplacé dns_ovh par mon dns soit ns.ndd.ovh dans la ligne :

$ export CERT_DNS="dns_ovh"

J'attire ton attention sur le fait que la variable d'environnement "CERT_DNS" correspond au script ".sh" que ACME va employer selon le fournisseur de domaine. Ce script est situé dans "/usr/local/share/acme.sh/dnsapi". Donc ta modification ne me semble pas correcte. A voir ...

Cordialement

oracle7😉

Modifié le 31 mai 2020 par oracle7

[CyberFr]

Dans un remarquable tuto @oracle7 a écrit

Citation

Un dernier constat : on ne le voit pas sur la copie d’écran, mais bien évidemment, le certificat précédemment marqué pour une utilisation par défaut, n’a pas disparu. Il est bien toujours présent dans la liste des certificats. Il n’est tout simplement plus marqué pour une utilisation par défaut. Rien n’a été perdu, c’est ce qui importe !

Je m'apprête à mettre en œuvre ce tuto mais je me pose une question. J'ai déjà un certificat qui pointe sur mon nom de domaine et qui d'ailleurs porte le même nom que le domaine. La création du nouveau certificat ne va-t-elle pas écraser le certificat existant ?

[bruno78]

Non, pas d'écrasement, à condition de bien choisir la methode de déploiement avec mode ajout .... (ce que j'ai fais). Et ensuite tu configures comme tu veux depuis l'interface DSM.

[Jeff777]

Il y a 1 heure, oracle7 a dit :

Dans ce cas cela t'impose d'aller en plus créer à la main dans ta Zone DNS d'OVH les enregistrements "TXT" nécessaires,

@oracle7  Je n'ai pas de zone DNS d'OVH et ne peux pas la créer car je n'utilise pas les DNS d'OVH.

OVH est juste mon fournisseur de domaine. 

Pour le certificat wildcard SSL for free je saisis les enregistrements TXT dans ma zone publique de DNS Serveur sur le NAS (ns.mondomaine.ovh)

Il n'y a peut-être pas de solution avec OVH vu que je n'ai pas de zone OVH.

Modifié le 31 mai 2020 par Jeff777

[oracle7]

@Jeff777

il y a 5 minutes, Jeff777 a dit :

Pour le certificat wildcard SSL for free je saisis les enregistrements TXT dans ma zone publique de DNS Serveur sur le NAS (ns.mondomaine.ovh)

Il n'y a peut-être pas de solution avec OVH vu que je n'ai pas de zone OVH.

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

Cordialement

oracle7😉

[Jeff777]

Aucune raison d'être désolé.....je continue à apprendre.

Mon certificat expire le 7/7 j'ai peut-être le temps de trouver une alternative.

[CyberFr]

Merci  @bruno78 pour ta réponse.