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

[FranckCShark]

Bonjour,

Cette nuit tache automatisée de renouvellement du certificat 01/05/2021

-- Ancien certificat par DEFAULT, a renouveler : EJLscU 

-- Fichier de configuration du ndd.tld : /volume1/Certs/XXXX.com/XXXX.com.conf 
-- Date de renouvellement autorisee (T0+60 jours par defaut) : Thu Apr 1 17:22:36 UTC 2021 
-- La date de renouvellement du certificat est atteinte 
-- On peut lancer la procedure de renouvellement 

.............

-- Renouvellement certificat via acme.sh 
-- commande acme.sh : bash /usr/local/share/acme.sh/acme.sh --cron --force --debug --log /volume1/Certs/Acme_renew/acmelog --home /usr/local/share/acme.sh 

-- Nouveau certificat par DEFAULT : EJLscU 
--- Le certificat n'a pas ete renouvele. 
--- => Consulter le log : /volume1/Certs/Acme_renew/acmelog 
--- Fin de la procedure

Le certificat n'a à priori pas été renouvelé. Est-ce que j'aurais fait une boulette ? merci de votre aide.

 

 

[bruno78]

Bonjour @Funroc,

peux-tu stp fournir le log acmelog ? (attention à bien l'anonymiser, ou alors par MP)

Cependant, avec un DS1621+, je conseillerai (sans vouloir botter en touche) d'utiliser la méthode via docker décrite ici :

Cdt, bruno78

[FranckCShark]

Log Deleted 

Modifié le 5 avril 2021 par Funroc

[bruno78]

@Funroc

je pense que l'erreur rencontrée est là :

[Mon Apr 5 00:00:09 CEST 2021] validationUrl='eu.api.ovh.com/auth/?credentialToken=QsX7XyN26fsToATtzPxi03luZ1JMDty7957Jhcdv2BXQNlh8orcVjetMvmznY5Se'
[Mon Apr 5 00:00:09 CEST 2021] consumerKey='[hidden](please add '--output-insecure' to see this value)'
[Mon Apr 5 00:00:09 CEST 2021] Please open this link to do authentication: eu.api.ovh.com/auth/?credentialToken=QsX7XyN26fsToATtzPxi03luZ1JMDty7957Jhcdv2BXQNlh8orcVjetMvmznY5Se
[Mon Apr 5 00:00:09 CEST 2021] Here is a guide for you: github.com/acmesh-official/acme.sh/wiki/How-to-use-OVH-domain-api
[Mon Apr 5 00:00:09 CEST 2021] Please retry after the authentication is done.
[Mon Apr 5 00:00:09 CEST 2021] Error add txt for domain:_acme-challenge.nnd.tld
[Mon Apr 5 00:00:09 CEST 2021] _on_issue_err
[Mon Apr 5 00:00:09 CEST 2021] Please check log file for more details: /volume1/Certs/Acme_renew/acmelog

En général cela arrive lorsque les tokens sur le site OVH n'ont pas été créés avec une validité permanente, et donc là il y a fort à parier qu'ils ont expirés ....

Modifié le 5 avril 2021 par bruno78

[FranckCShark]

il y a 6 minutes, bruno78 a dit :

@Funroc

je pense que l'erreur rencontrée est là :

[Mon Apr 5 00:00:09 CEST 2021] validationUrl='eu.api.ovh.com/auth/?credentialToken=QsX7XyN26fsToATtzPxi03luZ1JMDty7957Jhcdv2BXQNlh8orcVjetMvmznY5Se'
[Mon Apr 5 00:00:09 CEST 2021] consumerKey='[hidden](please add '--output-insecure' to see this value)'
[Mon Apr 5 00:00:09 CEST 2021] Please open this link to do authentication: eu.api.ovh.com/auth/?credentialToken=QsX7XyN26fsToATtzPxi03luZ1JMDty7957Jhcdv2BXQNlh8orcVjetMvmznY5Se
[Mon Apr 5 00:00:09 CEST 2021] Here is a guide for you: github.com/acmesh-official/acme.sh/wiki/How-to-use-OVH-domain-api
[Mon Apr 5 00:00:09 CEST 2021] Please retry after the authentication is done.
[Mon Apr 5 00:00:09 CEST 2021] Error add txt for domain:_acme-challenge.nnd.tld
[Mon Apr 5 00:00:09 CEST 2021] _on_issue_err
[Mon Apr 5 00:00:09 CEST 2021] Please check log file for more details: /volume1/Certs/Acme_renew/acmelog

En général cela arrive lorsque les tokens sur le site OVH n'ont pas été créés avec une validité permanente, et donc là il y a fort à parier qu'ils ont expirés ....

Merci, je vais regarder calmement.

[FranckCShark]

Il y a 2 heures, bruno78 a dit :

Bonjour @Funroc,

peux-tu stp fournir le log acmelog ? (attention à bien l'anonymiser, ou alors par MP)

Cependant, avec un DS1621+, je conseillerai (sans vouloir botter en touche) d'utiliser la méthode via docker décrite ici :

Cdt, bruno78

J'ai tenté Docker, je coince encore sur la fin mais ça devrait le faire. J'ai déjà mes certificats avec des clés à vie. J'en suis à l'importation. Je ferai un retour sur le sujet, j'ai une commande qui est passée en SSH et pas en tache planifiée.

Merci de ton aide. 👋

[Diplo95]

Bonjour,

je suis en train de réaliser ce tuto et je bloque au point 5. Je précise que j'ai une double authentification. J'ai donc trouvé le cookie DID et j'ai donc copié sa valeur et tapé la commande :

$ export SYNO_DID=xxxxxxxxxxxxxxxValeur_du_DIDxxxxxxxxxxxxxxxxx

En voulant appliquer l'edit du 10/01/2021, je suis parti à la recherche de mon fichier /volume1/Certs/votre-domaine.tld/votre-domaine.tld.conf

Voici son contenu :

Je n'ai pas de variable « SAVED_SYNO_DID »

D'ailleurs, en réfléchissant, je ne comprends pas à quel moment cette variable se créer. En effet, je ne fais qu'un export de cette variable (plus haut) mais ensuite, je n'en fais rien.

Est-ce que vous pouvez me dire ce que j'ai loupé ?

Edit :

en me relisant je pense que je ne suis pas assez précis dans ma pensée. Ce que je voulais dire c'est que, si je comprends bien, export créé la variable et la rend variable d'environnement. Par contre, je ne vois pas l'opération qui l'aurait inscrite dans le fichier votre-domaine.tld.conf

Modifié le 6 avril 2021 par Diplo95
Reformulation

[oracle7]

@Diplo95

Bonjour,

Il y a 15 heures, Diplo95 a dit :

D'ailleurs, en réfléchissant, je ne comprends pas à quel moment cette variable se créer. En effet, je ne fais qu'un export de cette variable (plus haut) mais ensuite, je n'en fais rien.

Je crains que tu vas un peu trop vite en besogne dans ta réflexion. Tu parles d'opérations réalisées mais pas dans le bon ordre. Je m'explique :

1. Dans un premier temps (et seulement la première fois que le processus est déroulé) pour que le déploiement puisse de faire correctement, il faut exporter les variables d'environnement : SYNO_Scheme, SYNO_Hostname, SYNO_Ports, SYNO_Username, SYNO_Password, SYNO_Certificate et SYNO_DID.
   Pour cette dernière seulement si on utilise la 2FA et il faut avoir aussi préalablement (avant de recopier proprement sa valeur) vérifié la date d'expiration du cookie DID en ayant pris soin de la repousser "aux calandres grecques".
    
2. Ensuite on lance la commande de déploiement du certificat.
    
3. A partir de là SEULEMENT, le script "acme.sh" va sauvegarder (donc écrire) les valeurs des variables d'environnement sus-citées dans le fichier ndd.tld.conf avec le préfixe "SAVED_".
   Il sauve aussi (avec le même prefixe) les variables OVH_AK, OVH_AS dans le fichier /usr/local/share/acme.sh/account.conf ainsi que la variable OVH_CK mais elle, sans prefixe. Il sauve aussi dans ce fichier la variable SYNO_DID mais cette fois sous le nom SAVED_DID.

Voilà en espérant que ce sera plus clair pour toi.

Cordialement

oracle7😉

[Diplo95]

Merci @Oracle10 pour ton aide précieuse sur ce sujet.

Si je comprends bien, et en l'appliquant à mon cas : comme je pars d'une partition vierge (en effet, mon NAS est neuf et après avoir sécurisé son accès, je m'attaque au déploiement d'un certificat wildcard), il faut d'abord que je fasse la partie 5.2, en ayant pris soin d'exporter toutes les variables nécessaires au fonctionnement du script acme.sh.

Une fois que le certificat sera déployé, on verra alors apparaître les noms de variables citées dans le tuto dans les fichiers correspondants.

Ce qui m'a un peu perturbé, c'est ce passage :

Citation

 

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

 

Comme ce passage est avant la partie 5.2 du tuto, je ne trouvais pas ces variables dans les fichiers et n'osais pas procéder au déploiement.

[oracle7]

@Diplo95

Bonjour,

il y a 58 minutes, Diplo95 a dit :

Merci @Oracle10 pour ton aide précieuse sur ce sujet.

Pas de soucis mais moi c'est @oracle7 !!!

Sinon, je comprends que l'edit du 10/01/2021 t'ai perturbé mais il faut bien voir que c'est un "edit" et sa position n'est peut-être pas très heureuse mais difficile d'insérer ce type de précision sans tout réécrire ...

Bonne continuation et n'hésites pas à reposter si tu as besoin d'éclairssissements.

Cordialement

oracle7😉

[Diplo95]

Citation

Pas de soucis mais moi c'est @oracle7 !!!

@oracle7 oups, la bourde ! Désolé !!

Ce tuto est une mine d'information ! Je m'y suis perdu car malheureusement je n'ai pas les connaissances pour comprendre tout ce que je fais : il y a des actions que je fais à l'aveugle. D'un autre côté, ça aiguise la curiosité et pousse à s'améliorer.

J'ai une dernière question (pour le moment) concernant l'utilisation de WinSCP. Est-ce que l'environnement shell est réinitialisé lorsqu'on ferme la console, ou quand on ferme la connexion ? (c'est pour savoir ou j'en suis avec mes variables)

Modifié le 7 avril 2021 par Diplo95

[oracle7]

@Diplo95

Bonjour,

il y a 7 minutes, Diplo95 a dit :

Est-ce que l'environnement shell est réinitialisé lorsqu'on ferme la console, ou quand on ferme la connexion ? (c'est pour savoir ou j'en suis avec mes variables)

Absolument, les variables sont crées en mémoire et ne vivent que le temps de ta session SS . Donc si tu fermes/clos ta session SSH même sans quitter WinSCP et a fortiori si tu quittes WinSCP ou puTTY (si ouvert seul), il te faudra réexporter TOUTES les variables depuis le début afin de reprendre le processus acme.sh où tu t'étais arrêté. C'est contraignant mais on ne peux faire autrement et c'est même logique comme comportement.

Cordialement

oracle7😉

[Diplo95]

J'apporte un complément à ton information (je viens de le trouver en cherchant un peu). Ça peut peut-être aider qqn.

Si on choisit d'utiliser WinSCP pour effectuer ce tuto, on va donc utiliser son outil "Console". Or, tant que cette console est active, on ne peut plus manipuler les fichiers par l'interface graphique : il faut de temps en temps la fermer.

Je confirme que dans ce cas, si l'on ne fait que fermer la console sans mettre fin à la connexion avec le NAS, l'environnement n'est pas réinitialisé et les variables sont toujours présentes. Pour le vérifier, il suffit de taper la commande

$ export

Son résultat donnera le listing de toutes les variables exportées.

[oracle7]

@Diplo95

Bonjour,

Oui tu as raison mais je mettrai juste un bémol : la fenêtre de la console de WinSCP ne supporte pas les commandes dites interactives et plante complètement WinSCP en cas d'usage de ces dernières.

C'est pour cela qu'il est préférable de travailler avec une console puTTY ouverte à partir de WinSCP. En plus cette console supporte mieux les C/C que celle de WinSCP. Mais c'est juste mon avis ...

Cordialement

oracle7😉

[Diplo95]

@oracle7

Merci : je n'avais tout simplement pas vu la possibilité d'ouvrir une session Putty par WinSCP !!

Je m'endormirai un peu moins bête ce soir !

[Diplo95]

@oracle7

Je reviens déjà avec un problème lors du déploiement du certificat. J'utilise le mode ajout de certificat. J'ai essayé en http et en https, mais j'ai toujours un problème d'identification :

 

J'ai essayé en modifiant des paramètres dans mon Syno :

• j'ai enlevé la bascule automatique de http vers https
• j'ai simplifié mon mdp en enlevant les caractères spéciaux
• j'ai essayé avec localhost ou l'adresse ip locale

Je précise que j'arrive à me connecter à mon NAS avec ces identifiants et mdp lorsque je passe par une page web.

Est-ce que j'ai encore loupé un truc évident ? Merci

[oracle7]

@Diplo95

Bonjour,

il y a 7 minutes, Diplo95 a dit :

J'ai essayé en http et en https

Si tu renseignes SYNO_Scheme avec la valeur "hhtps" il faut ajouter dans la commande de déploiement l'option "--insecure". Mais il est préférable de tout faire en HTTP car tu es sur ton réseau local donc pas de risques ...

Chez quel fournisseur de domaine es-tu ? C'est bien OVH ? Dans la zone DNS de ton domaine chez ton fournisseur : tu ne dois pas avoir d'enregistrements "challenge" de présents. Comme ton domaine doit bien pointer sur ton @IP externe si @IP fixe ( avec un enregistrement A) ou vers ton DynDNS si @ip dynamique (pas d'enregistrement A mais DynDNS défini sur ton @IP externe). Le domaine wilcard "*.ndd.tld" doit aussi y être définit avec un enregistrement CNAME pointant sur ton domaine.

Vérifies bien tes C/C de valeurs dans les variables d'environnement (passes par un éditeur de texte pour t'assurer qu'il n'y a pas de caractères invisibles : blancs, fin de ligne, etc ...).

Vérifies bien aussi tes clés AK, AS et CK.

Attention pas de caractères spéciaux dans l'ID et dans le MdP. C'est important, dis-toi que tu es sous UNIX donc un système très sensible à cela ! et il interdit l'usage de certains caractères pas forcément dits spéciaux ou "exotiques" tels que % \ / * ? : " < > | @ . N'utilises que les lettres majuscules, minuscules et des chiffres.

Vérifies encore ton DID et sa validité (chaque MàJ de FF par ex ramène sa validité à 1 mois).

Le port 80 est-il bien transféré de la box vers le NAS et ouvert dans le pare-feu du NAS ?

Après, difficile de t'en dire plus à ce stade. Normalement en suivant à la lettre le TUTO tu ne devrais pas avoir de soucis.

Cordialement

oracle7😉

 

[Diplo95]

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

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

@oracle7Je n'arrive toujours pas à me logger et j'ai toujours l'erreur :

Unable to authenticate to localhost:5000 using http.
Check your username and password.

Or, je ne vois pas les variables SAVED_SYNO_DID et SAVED_DID dans les fichiers correspondants. J'essaye donc de les rajouter à la main. Est-ce qu'elles sont identiques et égales à cette variable :

SYNO_DID=xxxxxxxxxxxxxxxValeur_du_DIDxxxxxxxxxxxxxxxxx

 

[oracle7]

@Diplo95

Bonjour,

Il y a 9 heures, Diplo95 a dit :

Or, je ne vois pas les variables SAVED_SYNO_DID et SAVED_DID dans les fichiers correspondants. J'essaye donc de les rajouter à la main. Est-ce qu'elles sont identiques et égales à cette variable :

SYNO_DID=xxxxxxxxxxxxxxxValeur_du_DIDxxxxxxxxxxxxxxxxx

Oui c'est ce qu'il faut faire et tu recopies la valeur du cookie DID dans ces deux variables.

Cordialement

oracle7😉

[Diplo95]

@oracle7
On est d'accord qu'il faut aussi les xxxxxx avant et après ?

Envoyé de mon SM-G973F en utilisant Tapatalk

[oracle7]

@Diplo95

Bonjour,

il y a 1 minute, Diplo95 a dit :

On est d'accord qu'il faut aussi les xxxxxx avant et après ?

NON absoluement pas, les xxxxxx avant et après ne sont là pour l'exemple pour signifier que la valeur est longue tout simplement.

Donc tu remplaces xxxxxxxxxxxxxxxValeur_du_DIDxxxxxxxxxxxxxxxxx par la chaine de la valeur du DID soit quelque chose comme cela : V6lG0Qcq5zibpmFb5LFYGdYmTvRnQ.........

Je comprends mieux maintenant pourquoi ta connexion ne se fait pas 😜

Cordialement

oracle7😉

[Diplo95]

Salut @oracle7,

j'ai failli ne pas poser la question trouvant que c'était trop bête ! J'ai bien fait de ne pas me censurer.

Effectivement, la connexion se fait maintenant. Mais j'ai un nouveau message d'erreur :

L'erreur 18 est la suivante :

 

Citation

 

CURLE_PARTIAL_FILE (18)

A file transfer was shorter or larger than expected. This happens when the server first reports an expected transfer size, and then delivers data that doesn't match the previously given size.

 

Est-ce que tu aurais une piste pour expliquer ceci ? Merci

[Diplo95]

@oracle7

J'ai un peu cherché par moi-même sur le github et j'ai trouvé une variable qui n'est pas abordée par ton tuto. Je l'ai donc rajoutée en lançant cette commande :

$ export HTTPS_INSECURE=1

Et cette fois, c'est un succès :

Par contre, je ne sais pas à quoi elle sert. C'est peut-être à rajouter dans ton tuto ?

[oracle7]

@Diplo95

Bonjour,

Je découvre cette variable, peux-tu STP me donner le lien Github où tu as trouvé cette info.

Je pense qu'elle est l'équivalent de l'option --insecure que l'on ajoute à la commande de deploiement lors que SYNO_Scheme est  positionnée sur https. Mais je peux me tromper  ...

Cordialement

oracle7😉

 

[Diplo95]

@oracle7

Le lien vers l' "issue" :

https://github.com/acmesh-official/acme.sh/issues/3215?_pjax=%23js-repo-pjax-container