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

[_DR64_]

@oracle7,

Dernier petit point, je viens de configurer le renouvellement automatique du certificat via les tâches planifiées , j'ai fermé le port 80 pour "TOUS"  et testé. Tout fonctionne parfaitement, cependant j'ai ça :

Par rapport à ta capture, je vois tous mes domaines de reverse proxy. Normal ? Tu n'as rien toi sur ta capture (peut-etre une VM... )

Edit : Je ne peux pas exporter ce certificat et l'importer dans sur mon routeur. Normal ?

Merci

Modifié le 1 juin 2020 par GrOoT64

[oracle7]

@bruno78

Je reviens sur la problématique du renouvellement que tu as évoquée dans une réponse précédente :

Le 31/05/2020 à 07:27, bruno78 a dit :

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 ?

J'ai examiné le corps du Shell scrypt "acme.sh", effectivement par défaut si la date de renouvellement n'est pas atteinte, le script la programme 60 jours après (variable DEFAULT_RENEW=60).

Toutes fois, cette valeur par défaut de 60 jours peut-être modifiée en spécifiant l'instruction "--days XXX" avec "XXX" = nombre de jours pour le prochain renew.

Attention cette commande "--days XXX" ne peut être utilisée qu'en conjonction de la commande "--issue".

Donc là, on pourrait fixer les fameux 85 jours pour assurer le renouvellement avec juste un peu de marge avant l'échéance effective et donc l'ajouter ("--days 85") à la commande de création du certificat. Ton avis ?

Reste, après le problème de la tâche "cron" qui n'est a priori pas affinable dans DSM au niveau de sa période de reproduction. Affaire à creuser donc ...

Cordialement

oracle7😉

 

@GrOoT64

il y a 34 minutes, GrOoT64 a dit :

Par rapport à ta capture, je vois tous mes domaines de reverse proxy. Normal ? Tu n'as rien toi sur ta capture (peut-etre une VM... )

Non pas de VM, mais un GRAND MERCI pour ta remarque, car (et je n'y avais pas prété suffisamment attention) mes attributions du certificat aux services étaient restées sur celles du certificat précédent par défaut. Voilà pourquoi on ne voyait rien sur ma capture d'écran.

En conséquence, il faut que je reprenne mon commentaire de constat dans le tuto. Les assignations ne sont pas reprises automatiquement. Il faut les configurer toutes manuellement ce qui je trouve n'est pas plus mal au final.

il y a 34 minutes, GrOoT64 a dit :

Edit : Je ne peux pas exporter ce certificat et l'importer dans sur mon routeur. Normal ?

Je n'ai pas procédé de cette façon. J'ai importé directement sur le routeur les fichiers . key, .crt et .csr depuis une copie sur mon PC de ceux situés dans le répertoire de génération "/volume1/Certs" (que je garde précieusement !). Donc pas d'import de fichiers .pem.

Cordialement

oracle7😉

Modifié le 1 juin 2020 par oracle7

[bruno78]

il y a une heure, oracle7 a dit :

@bruno78

Il y a 1 heure, bruno78 a dit :

Je n'ai pas trouvé comment remplacer l'ancien certificat par le nouveau dans DSM.

Du coup en conjonction de l'instruction "--staging" et en employant tout simplement la méthode "annule et remplace" du § 5.2.1 ? A voir ...

Donc si je comprends bien, il faut que je fasse : 

1. deployement "annule et remplace" du certificat par defaut : 
   • SYNO_Certificate=""

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

2. Puis job periodique de renouvellement, avec éventuellement --force, --staging, --days, .... (je viens de voir les dernières reponses)

[oracle7]

@bruno78

1 - OUI, si tu veux effectivement remplacer le certificat par défaut existant, mais je te rappelle qu'il sera ECRASE et donc irrécupérable !

2 - Je ne saurais dire si on peut mettre la commande "--days XXX" dans la commande que l'on met dans le planificateur de tâches de DSM. J'avais plutôt compris qu'elle était à ajouter à la commande "--issue" utilisée pour la création du certificat et/ou lors du renouvellement avec "--force" (au lieu de "--renew" qui génère un message d'erreur). mais j'ai peut-être mal interprété les choses, non ?

Maintenant, il faut voir si c'est possible, car je n'ai pas vu jusqu'à présent ce genre d'option dans les différents tutos trouvés sur la toile, pour la commande à mettre dans le gestionnaire de tâches de DSM.

Cordialement

oracle7😉

 

[bruno78]

Merci @oracle7, 

je vais relire tout cela à tête reposée, il y a beaucoup d’informations dans ces 3 pages de TUTO, extrêmement intéressant. faut que je remette un peu tout cela dans l'ordre, et sans faire de bêtise !

Bruno78

[oracle7]

A tous,

J'ai mis à jour le tutoriel pour tenir compte des premiers retours effectués.

• § 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.

Cordialement

oracle7😉

[.Shad.]

@Jeff777

Tu dois t'orienter vers ce que je t'avais proposé, donc vers un script qui ajoute les enregistrements acme challenge TXT à la zone DNS du NAS. Si tu résous ça tu ne devrais rencontrer aucun problème selon moi.

Modifié le 2 juin 2020 par .Shad.

[Jeff777]

Bonjour @.Shad. et merci pour ton aide.i

Je n'ai pas renoncé ! Je suis de genre têtu 😆

Maintenant que je suis rassuré sur la possibilité d'obtenir une wildcard en manuel je suis reparti sur le Tuto de @oracle7 pour essayer de le faire fonctionner avec des DNS non OVH.

En passant : un détail sur le tuto : Cela fait deux fois que j'ai pris exactement les noms donnés par le tuto (trop fénéant) : Synology_acme_sh et  Certificat wilcard LE – ACME pour l'API qui me sont refusés. J'ai été obligé de supprimer les caractères spéciaux. Bon peut-être j'ai laissé un espace quelque part.... sans garantie.

Donc, déjà, j'ai opté pour un vrai root.

J'arrive sans encombre jusqu'à la création du certificat :

 

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

Et là ça plante toujours au même endroit :

Dans l'API j'ai mis mon DNS  : ns.mondomaine.ovh à la place du dns_ovh. Et ce qui ne fonctionne pas c'est que celui-ci autorise le protocole http-01 et non dns-01. C'est cela??

Dans ce cas comment autoriser dns-01....j'espère ne pas faire de bêtises. Je suis limite !

Modifié le 2 juin 2020 par Jeff777

[bruno78]

Bonjour à vous,

grace à l'option --staging , j'ai refais quelques essais ce matin. J'arrive bien à forcer le renouvellement de certificat (--force --staging) bien que la date de renouvellement ne soit pas atteinte, par contre  même en prenant la méthode dite "annule et remplace", je me retrouve avec un nouveau certificat importé dans DSM, nouvelle date d'expiration, mais toujours par defaut et vièrge de tout service. J'ai l'impression que l'on n'évitera  pas, quelle que soit la méthode, le fait de reconfigurer à la main, à chaque renouvellement, nos services sur le nouveau certificat.

Remarque : lorsque l'on crée un certificat LE avec l'option --staging, le detail du certificat indique : Emis par : FAKE LE Intermediate X1
 

Cdt,

Bruno78

[oracle7]

@Jeff777

Bonjour,

Il y a 6 heures, Jeff777 a dit :

Dans l'API j'ai mis mon DNS  : ns.mondomaine.ovh à la place du dns_ovh.

Je n'ai pas dû suffisamment attiré ton attention dans ma précédente réponse :

Le 31/05/2020 à 11:02, oracle7 a dit :

Le 31/05/2020 à 07:25, 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 ...

Désolé, mais remplacer "dns_ovh" par "ns.mondomaine.ovh" comme tu sembles le faire, ne peut pas marcher ! Et de fait, je crains que tu n'ai pas bien compris le mécanisme mis en oeuvre.

Je t'explique :

Avec cette variable "CERT_DNS", le script "acme.sh" sait qu'il doit exécuter le Shell script spécifique au fournisseur OVH en l'occurrence le script "dns_ovh" situé dans le répertoire "/usr/local/share/acme.sh/dnsapi" sur ton NAS. Sans cette variable, le Shell script "acme.sh" ne peut deviner seul quel fournisseur de domaine tu as.

Par exemple, si tu avais été, pour ton domaine, chez "Cloudflare" ou chez Microsoft avec "Azure" il t'aurait fallut renseigner la dite variable avec respectivement "dns_cf" ou "dns_azure".

Il faut bien voir que ces Shell scripts sont SPECIFIQUES à chaque fournisseur de domaine pour attaquer leurs API respectives sur leurs serveurs DNS.

Je crois, mais je peux me tromper, comme tu es ton propre serveur DNS, tu n'as pas l'API nécessaire, ni le script adéquat pour aller examiner ta zone DNS sur ton propre serveur DNS pour, entres autres actions, y inscrire temporairement des enregistrements "TXT" afin de vérifier l'authentification de ton domaine. C'est ce que font précisément ces scripts lors du processus de création du certificat.

J'espère ne pas avoir été trop confus dans mon explication. Il est parfois difficile de décrire de tels mécanismes simplement.

@bruno78

Il y a 4 heures, bruno78 a dit :

J'ai l'impression que l'on n'évitera  pas, quelle que soit la méthode, le fait de reconfigurer à la main, à chaque renouvellement, nos services sur le nouveau certificat.

J'en suis arrivé au même constat que toi. Après tout, ce n'est qu'un moindre mal et pas la mer à boire, non ? A moins que l'on trouve une solution pour automatiser cela, mais j'en doute.

J'ai donc laissé un commentaire en ce sens dans le tutoriel.

Cordialement

oracle7😉

[bruno78]

@oracle7,

reconfiguration manuelle à chaque renouvellement : non bien sûr ce n'est pas la mer à boire (ca peut même avoir certaines vertues). ...  mais cela aurait été the cherry on the cake !...... . Je vais continuer à chercher sur ce sujet, .... étant moi aussi un peu têtu !

Bon courage, Bruno78

Modifié le 2 juin 2020 par bruno78

[Jeff777]

Bonsoir @oracle7

Il y a 8 heures, oracle7 a dit :

Avec cette variable "CERT_DNS", le script "acme.sh" sait qu'il doit exécuter le Shell script spécifique au fournisseur OVH en l'occurrence le script "dns_ovh"

Oui effectivement je n'avais pas compris. Je pensais qu'il fallait remplacer dns_ovh par le dns d'ovh que l'on utilisait et comme je n'en utilisais pas j'ai mis mon propre dns.

C'est beaucoup plus clair pour moi mais d'après ce que tu dis à la fin de ton post c'est pas gagné. J'essaierai cela demain matin et regarderai le log.

@.Shad. m'a donné quelques pistes mais il va falloir que je muscle sérieusement mes compétences 😅

 

A+

 

[Jeff777]

Bonjour à tous,

Effectivement avec dns_ovh la création du certificat bloque au moment de l'authentification de mon domaine car l'enregistrement TXT ne se fait pas. J'ai essayé de ruser en copiant le TXT obtenu dans ma zone mais si je retente de créer le certificat bien sûr l'appli crée un nouveau TXT 😏.

[Wed Jun  3 07:14:51 CEST 2020] Adding txt value: d45nY5xxxxxxxxxxxxxxxxxxxxxxxxx for domain:  _acme-challenge.mondomaine.ovh
[Wed Jun  3 07:14:51 CEST 2020] Using OVH endpoint: ovh-eu
[Wed Jun  3 07:14:51 CEST 2020] Checking authentication
[Wed Jun  3 07:14:52 CEST 2020] Consumer key is ok.
[Wed Jun  3 07:14:53 CEST 2020] invalid domain
[Wed Jun  3 07:14:53 CEST 2020] Error add txt for domain:_acme-challenge.mondomaine.ovh
[Wed Jun  3 07:14:53 CEST 2020] Please check log file for more details: /usr/local/share/acme.sh/acme.sh.log
 

A suivre, je reprendrai plus tard.

Modifié le 3 juin 2020 par Jeff777

[oracle7]

Bonjour à tous,

Après réflexion, j'aurais deux questions pour "initiés avertis" :

1. Lors du déploiement du certificat, j'avais relevé dans le message d'exécution de la commande, une anomalie du type "http services were NOT restarted". Ne sachant pas comment la traiter, je l'avais provisoirement ignorée même si je n'ai heureusement pas constaté ensuite de dysfonctionnements qui lui seraient liés.
   Maintenant pour tout de même s'affranchir de cette anomalie, je me demande si on ne devrait pas ajouter à la commande de déploiement du certificat la commande suivante :
   --reloadcmd "/usr/syno/etc/rc.sysv/nginx.sh reload"
   qui a pour objet de relancer le serveur WEB du NAS.
   D'une part, peut-on donc effectivement ajouter cette instruction ? et d'autre part, si OUI, sera-t-elle suffisante pour lever l'anomalie ?
    
2. Ma deuxième question concerne l'automatisation de l'application du nouveau certificat à tous les services.
   En effet, @bruno78 et moi même avons constaté que après sa création et/ou renouvellement, le nouveau certificat n'est pas ré-appliqué aux services à l'image de ce qui existait pour le certificat précédemment actif et marqué par défaut. Du coup, il faut refaire à la main toutes les affections. Pas top même si ce n'est pas la mer à boire en soit !
   Par ailleurs l'observation des arcanes du NAS au niveau des certificats, et notamment dans le répertoire "/usr/syno/etc/certificate/_archive", nous révèle la présence de deux fichiers très intéressants :
   1. "DEFAULT" : qui contient le nom du répertoire où sont stockés les fichiers ".pem" et ".key" du certificat marqué par défaut, ce qui permet d'identifier (en principe) clairement le dernier certificat créé.
   2. "INFO" : qui lui contient le détails de toutes les affectations pour chaque certificat inscrit.

Ce fichier "INFO" ressemble par exemple à cela :

Nota : Pour une bonne compréhension, le premier niveau de balise, correspond au nom du dossier de chaque certificat. Les niveaux suivants parlent d'eux mêmes.

{
   "A7eoae" : {
      "desc" : "ACME_Wilcard_LE_*.ndd.tld_new",
      "services" : []
   },
   "pAaeQI" : {
      "desc" : "ACME_Wilcard_LE_*.ndd.tld_old",
      "services" : [
         {
            "display_name" : "webdav.ndd.tld",
            "isPkg" : false,
            "owner" : "root",
            "service" : "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx",
            "subscriber" : "ReverseProxy"
         },
         {
            "display_name" : "nas.ndd.tld",
            "isPkg" : false,
            "owner" : "root",
            "service" : "FQDN",
            "subscriber" : "system"
         },
         {
            "display_name" : "Synology Drive Server",
            "display_name_i18n" : "SYNO.SDS.Drive.Application:app:pkg_name",
            "isPkg" : true,
            "owner" : "SynologyDrive",
            "service" : "SynologyDrive",
            "subscriber" : "SynologyDrive"
         },
         {
            "display_name" : "Log Receiving",
            "display_name_i18n" : "helptoc:logcenter_server",
            "isPkg" : true,
            "owner" : "root",
            "service" : "pkg-LogCenter",
            "subscriber" : "LogCenter"
         },
         {
            "display_name" : "DSM Desktop Service",
            "display_name_i18n" : "common:web_desktop",
            "isPkg" : false,
            "owner" : "root",
            "service" : "default",
            "subscriber" : "system"
         },
         {
            "display_name" : "FTPS",
            "isPkg" : false,
            "owner" : "root",
            "service" : "ftpd",
            "subscriber" : "smbftpd"
         }
      ]
   }
}

C'est ici que ma réflexion "tordue" intervient et en espérant ne pas être trop confus : ne pourrait-on pas via un Shell script manipuler ce fichier "INFO" pour y intervertir :

• les noms des dossiers respectifs des certificats notés ici dans la balise "desc" avec les suffixes "old" et "new",
• ainsi qu'intervertir aussi les balises "desc" correspondantes ?

Voilà par exemple ce à quoi on devrait arriver pour le nouveau fichier "INFO" après permutations :

{
   "pAaeQI" : {
      "desc" : "ACME_Wilcard_LE_*.ndd.tld_old",
      "services" : []
   },
   "A7eoae" : {
      "desc" : "ACME_Wilcard_LE_*.ndd.tld_new",
      "services" : [
         {
            "display_name" : "webdav.ndd.tld",
            "isPkg" : false,
            "owner" : "root",
            "service" : "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx",
            "subscriber" : "ReverseProxy"
         },

etc ...

Enfin, ce Shell script serait à exécuter en complément de la commande de renouvellement du certificat (après celle-ci), objet de la tâche périodique crée dans DSM.

Mes compétences en Shell script étant limitées pour réaliser le dit Shell script et si l'idée est potentiellement réalisable, j'en appelle à une bonne âme pour prendre de son précieux temps afin d'en écrire le code qui va bien.

Au final, on disposerait ainsi d'une automatisation complète du processus de création/renouvellement d'un certificat LE.

Merci d'avance aux amateurs de code pour leur aide.

Cordialement

oracle7😉

 

Modifié le 3 juin 2020 par oracle7

[_Megalegomane_]

Le 03/06/2020 à 07:22, Jeff777 a dit :

Bonjour à tous,

Effectivement avec dns_ovh la création du certificat bloque au moment de l'authentification de mon domaine car l'enregistrement TXT ne se fait pas. J'ai essayé de ruser en copiant le TXT obtenu dans ma zone mais si je retente de créer le certificat bien sûr l'appli crée un nouveau TXT 😏.

[Wed Jun  3 07:14:51 CEST 2020] Adding txt value: d45nY5xxxxxxxxxxxxxxxxxxxxxxxxx for domain:  _acme-challenge.mondomaine.ovh
[Wed Jun  3 07:14:51 CEST 2020] Using OVH endpoint: ovh-eu
[Wed Jun  3 07:14:51 CEST 2020] Checking authentication
[Wed Jun  3 07:14:52 CEST 2020] Consumer key is ok.
[Wed Jun  3 07:14:53 CEST 2020] invalid domain
[Wed Jun  3 07:14:53 CEST 2020] Error add txt for domain:_acme-challenge.mondomaine.ovh
[Wed Jun  3 07:14:53 CEST 2020] Please check log file for more details: /usr/local/share/acme.sh/acme.sh.log
 

A suivre, je reprendrai plus tard.

Bonjour,

Est-ce qu tu as pu avancer sur ton soucis ? 
J'ai commencé le tuto hier (un grand merci d'ailleurs 😉) et je rencontre exactement la même erreur...
 

En relançant la commande avec le paramètre --debug, j'ai cette sortie :

[Thu Jun 11 16:19:25 CEST 2020] First detect the root zone
[Thu Jun 11 16:19:25 CEST 2020] domain/zone/mondomaine.in
[Thu Jun 11 16:19:25 CEST 2020] GET
[Thu Jun 11 16:19:25 CEST 2020] url='https://eu.api.ovh.com/1.0/auth/time'
[Thu Jun 11 16:19:25 CEST 2020] timeout=30
[Thu Jun 11 16:19:25 CEST 2020] _CURL='curl -L --silent --dump-header /usr/local/share/acme.sh/http.header  -g  --connect-timeout 30'
[Thu Jun 11 16:19:25 CEST 2020] ret='0'
[Thu Jun 11 16:19:25 CEST 2020] _ovh_p='[hidden](please add '--output-insecure' to see this value)'
[Thu Jun 11 16:19:25 CEST 2020] GET
[Thu Jun 11 16:19:25 CEST 2020] url='https://eu.api.ovh.com/1.0/domain/zone/mondomaine.in'
[Thu Jun 11 16:19:25 CEST 2020] timeout=
[Thu Jun 11 16:19:25 CEST 2020] _CURL='curl -L --silent --dump-header /usr/local/share/acme.sh/http.header  -g '
[Thu Jun 11 16:19:25 CEST 2020] ret='0'
[Thu Jun 11 16:19:25 CEST 2020] domain/zone/in
[Thu Jun 11 16:19:25 CEST 2020] GET
[Thu Jun 11 16:19:25 CEST 2020] url='https://eu.api.ovh.com/1.0/auth/time'
[Thu Jun 11 16:19:25 CEST 2020] timeout=30
[Thu Jun 11 16:19:25 CEST 2020] _CURL='curl -L --silent --dump-header /usr/local/share/acme.sh/http.header  -g  --connect-timeout 30'
[Thu Jun 11 16:19:25 CEST 2020] ret='0'
[Thu Jun 11 16:19:25 CEST 2020] _ovh_p='[hidden](please add '--output-insecure' to see this value)'
[Thu Jun 11 16:19:25 CEST 2020] GET
[Thu Jun 11 16:19:25 CEST 2020] url='https://eu.api.ovh.com/1.0/domain/zone/in'
[Thu Jun 11 16:19:25 CEST 2020] timeout=
[Thu Jun 11 16:19:25 CEST 2020] _CURL='curl -L --silent --dump-header /usr/local/share/acme.sh/http.header  -g '
[Thu Jun 11 16:19:25 CEST 2020] ret='0'
[Thu Jun 11 16:19:25 CEST 2020] invalid domain
[Thu Jun 11 16:19:25 CEST 2020] Error add txt for domain:_acme-challenge.mondomaine.in
[Thu Jun 11 16:19:26 CEST 2020] _on_issue_err
[Thu Jun 11 16:19:26 CEST 2020] Please add '--debug' or '--log' to check more details.
[Thu Jun 11 16:19:26 CEST 2020] See: https://github.com/acmesh-official/acme.sh/wiki/How-to-debug-acme.sh

Cette ligne me pose question : [Thu Jun 11 16:19:25 CEST 2020] url='https://eu.api.ovh.com/1.0/domain/zone/in'
J'ai l'impression qu'il cherche aussi à attaquer le domaine "in"... C'est peut-être le fonctionnement normal mais j'avoue être un peu largué pour le coup 😅

[bruno78]

Bonjour,

@oracle7 pour info je suis en train de travailler sur l'aspect automatisation du deployment (modification du fichier INFO après renouvellement du certificat du repertoire _archive). C'est en cours de tests .... mais faut être prudent pour être sûr de ne pas tout mélanger et véroler. On aurait ainsi une automatisation complète.

@_Megalegomane_: es-tu bien connecté en "vrai" root pour réaliser toutes les commandes (et non pas en sudo -i) ?

Modifié le 11 juin 2020 par bruno78

[_Megalegomane_]

J'ai suivi le tuto de @unPixel afin de me connecter directement en root avec certificat et passprahse depuis putty.
J'ai également fait un uninstall de acme.sh pour recommencer le tuto de zéro mais je tombe toujours sur cette erreur 😤

J'ai beau chercher, je ne vois pas où j'ai pu faire une coquille...

[Jeff777]

Bonjour,

Tu cherches simplement à créer un certificat wildcard ou bien tu veux un renouvellement automatique. Ce que fait le présent tuto d' @oracle7

Si c'est juste le widcard à renouveler manuellement tous les trois mois. Par exemple :

Le 31/05/2020 à 22:55, Jeff777 a dit :

Que pensez-vous de ceci :https://vdr.one/how-to-create-a-lets-encrypt-wildcard-certificate-on-a-synology-nas/

Edit : J'ai suivi le tuto et ça à l'air de fonctionner. J'ai mon certificat jusqu'au 29/8/20 😎👍

Je verrai demain s'il n'y a pas d'entourloupe.

Si c'est de l'automatique que tu cherches et que tu n'es pas chez OVH  DNS  compris, c'est plus compliqué. Avec un peu de chance tu peux trouver une API qui fera l'affaire en remplaçant dans le tuto. 

Pour ce qui est de la réponse à ta commande je ne suis pas assez calé pour te dépanner 😒

[_Megalegomane_]

Je cherche à avoir création + renouvellement et je suis bien chez OVH.

Même si je suis toujours bloqué, merci à tous pour votre réactivité de réponse 🙂

Modifié le 11 juin 2020 par _Megalegomane_

[bruno78]

@_Megalegomane_

lors de ta demande de certificat, es-tu sur d'avoir bien initialisé correctement toutes les variables d'environnement ?

[oracle7]

@_Megalegomane_

Bonjour,

A l'examen de ton fichier debug, on constate que ton domaine n'est pas reconnu comme valide. Donc, en première approche il faudrait que tu vérifies cela d'une part chez OVH et d'autre part partout où l'on insère le libellé de ce domaine (création des clés chez OVH, dans les commandes ACME, etc ...). Il faut être attentif à la syntaxe ...

Après, vérifies aussi ton compte de connexion SSH avec le "vrai" root. @GrOoT64 (voir page 2 du post) a eu ce soucis qui lui bloquait la création.

Je sais aussi que OVH n'aime pas trop certains caractères spéciaux dans les mots de passe. Cela peut-être aussi une piste.

As-tu bien Copier/Coller les clés "applications key, secret et consumer" dans les variables d'environnement. Il arrive que, en croyant bien faire ( @bruno78 en a fait les frais le premier), l'on prenne en même temps un caractère parasite avec, ce qui au final donne une chaîne qui est différente d'où l'erreur renvoyée par OVH. C'est un peu pour cela que je préconise de les sauver dans un fichier "pur" ".txt" pour bien voir ce que l'on copie.

@bruno78

MERCI à toi de bien vouloir t'atteler à cette tâche d'automatisation de A à Z. J'ai hâte de lire ton retour sur le sujet. Je mettrais à jour le Tuto en conséquence.

Cordialement

oracle7😉

[_Megalegomane_]

Merci @oracle7, je suis le boulet du jour 🙄 !

Malgré avoir refait le tuto, j'avais fait 2x la même erreur sur la création de la clé API OVH... Une fois corrigé j'ai pu terminer le tuto.

Je refais un résumé pour ceux qui auraient le même soucis :

si à la commande (début partie 4 du tuto) : ./acme.sh --issue --keylength 4096 -d "$CERT_DOMAIN" -d "$CERT_WDOMAIN" --dns "$CERT_DNS"
vous avez l'erreur suivante : 
[Wed Jun  3 07:14:52 CEST 2020] Consumer key is ok.
[Wed Jun  3 07:14:53 CEST 2020] invalid domain
[Wed Jun  3 07:14:53 CEST 2020] Error add txt for domain:_acme-challenge.mondomaine.ovh

vous avez certainement (comme moi) créé la clé API OVH avec une coquille dans le nom de domaine.

il vous faudra lister les clés en allant sur cette URL : https://api.ovh.com/console/#/me/api/application%23GET
puis supprimer l'ancienne clé en allant via cette URL : https://api.ovh.com/console/#/me/api/application/{applicationId}#DELETE
choisir le bon id dans la liste (ou le taper à la main si la liste n'apparait pas) et cliquer Execute

A partir de là, refaire à partir de la partie 3.1 "Création des clés" du tuto.

Merci à tous et désolé de vous avoir fait chercher juste pour ça

Modifié le 12 juin 2020 par _Megalegomane_

[oracle7]

@_Megalegomane_

Bonjour,

Donc, tout est bien qui fini bien, content pour toi que tu ais réussit cette création de certificat et merci pour ton retour.

A ce propos :

Il y a 12 heures, _Megalegomane_ a dit :

choisir le bon id dans la liste

Je dois être mal réveillé et les yeux encore très embrumés mais quand je me connecte et que je vais sur le lien que tu as donné, je ne vois pas la "liste d'Id" dont tu parles. Où se trouve-t-elle précisément ?

Cela m’intéresse, ne serait-ce que pour faire le ménage dans les applications que j'ai créées lors de mes tests et qui n'ont plus lieu d'être.

Cordialement

oracle7😉

[_Megalegomane_]

@oracle7

Je viens de comprendre qu'il faut d'abord faire un execute sur cette API : https://api.ovh.com/console/#/me/api/application#GET

et ensuite aller sur https://api.ovh.com/console/#/me/api/application/%7BapplicationId%7D#DELETE

Visiblement la liste déroulante n'apparait pas à tous les coups donc il faudra peut-être saisir les ID à la main.

Du coup j'ai corrigé mon post histoire de ne pas induire d'autres personnes en erreur.

Modifié le 12 juin 2020 par _Megalegomane_

[oracle7]

@_Megalegomane_

Effectivement, il faut faire auparavant un "execute" sur  "application/#GET" pour obtenir la liste des "Id".

Cela dit, je n'ai pas vu la liste déroulante mais en copiant à la main l'Id, le "application/#DELETE" fonctionne très bien. Cela me suffit.

Donc MERCI à toi pour cette astuce bien utile au demeurant. +1 👍

Cordialement

oracle7😉