kerod Posté(e) le 28 septembre 2020 Posté(e) le 28 septembre 2020 (modifié) @oracle7 Non je ne penses pas tu vois, je pense qu'il y a un chemin en dur dans le fichier qui est souvent mis à jour et que le test à blanc ne permet pas de tester jusqu'au bout ou en tous cas le script ne remontait pas le problème. La différence entre la première génération qui a été correctement effectuée par le script en manuel et maintenant c'est les différentes mises à jour du script. Modifié le 28 septembre 2020 par kerod 0 Citer
oracle7 Posté(e) le 28 septembre 2020 Auteur Posté(e) le 28 septembre 2020 @kerod Bonjour, il y a 4 minutes, kerod a dit : je pense qu'il y a un chemin en dur dans le fichier qui est souvent mis à jour et que le test à blanc ne permet pas de tester jusqu'au bout ou en tous cas le script ne remontait pas le problème. Ah bon ! Et quels éléments précis te permettent d'alimenter cette assertion ? Je serais curieux de les connaître. Pour ma part, il semble que le message que tu as reçu est on ne peut plus clair : Citation [Mon Sep 28 00:00:17 CEST 2020] The consumer key is invalid: SF8ErD1ESplr3w7sigucTHyY8vJ1fg02 Il est donc parfaitement clair que la clé CK que tu as saisie dans la variable d'environnement OVH_CK n'est pas la bonne. Et en conséquence, elle n'est pas vue valide lorsque le script "acme.sh" (exécuté en interne du script Python de renouvellement) lance les contrôles de sécurité chez OVH avant d'insérer dans la zone DNS de ton domaine les enregistrements "TXT" de challenge qui seront ensuite relus par les serveurs de Let'sEncrypt pour valider le renouvellement du certificat. Ce n'est pas plus compliqué que cela. Compares cette valeur de clé CK avec la sauvegarde de celle-ci que tu as dû sûrement faire selon les recommandations du TUTO pour t'en convaincre. Cordialement oracle7😉 0 Citer
kerod Posté(e) le 28 septembre 2020 Posté(e) le 28 septembre 2020 Pourquoi elle ne fonctionnerait pas alors que je ne l'ai pas changé et que la première fois que j'ai utilisé le script cela a fonctionné ? Le certificat est généré mais on a toujours l'erreur suivante à la fin du processus - Nouveau certificat par DEFAULT : Yan5LF --- Le certificat n'a pas ete renouvele. --- => Consulter le log : /volume1/certs/Acme_renew/acmelog --- Fin de la procedure 0 Citer
oracle7 Posté(e) le 28 septembre 2020 Auteur Posté(e) le 28 septembre 2020 @kerod Bonjour, OK mais que dit précisément le log acmelog ? La raison du non renouvellement y figure certainement ... Cordialement oracle7😉 0 Citer
kerod Posté(e) le 28 septembre 2020 Posté(e) le 28 septembre 2020 (modifié) @oracle7 J'ai l'impression de ne pas parler français. [Mon Sep 28 20:08:57 CEST 2020] Success [Mon Sep 28 20:08:57 CEST 2020] Return code: 0 [Mon Sep 28 20:08:57 CEST 2020] _error_level='2' [Mon Sep 28 20:08:57 CEST 2020] _set_level='2' [Mon Sep 28 20:08:57 CEST 2020] The NOTIFY_HOOK is empty, just return. [Mon Sep 28 20:08:57 CEST 2020] ===End cron=== -- Nouveau certificat par DEFAULT : Yan5LF --- Le certificat n'a pas ete renouvele. --- => Consulter le log : /volume1/certs/Acme_renew/acmelog --- Fin de la procedure Modifié le 28 septembre 2020 par kerod 0 Citer
oracle7 Posté(e) le 28 septembre 2020 Auteur Posté(e) le 28 septembre 2020 @kerod Bonjour, Citation -- Nouveau certificat par DEFAULT : Yan5LF --- Le certificat n'a pas ete renouvele. --- => Consulter le log : /volume1/certs/Acme_renew/acmelog --- Fin de la procedure Ce message est normal dans la mesure où la commande de renouvellement exécutée par le script acme.sh en interne du script Python, n'a pas aboutie. Les raisons en sont multiples. Dans ce cas, tu as dû avoir d'autres messages d'erreurs, il ne peut en être autrement. Envoies moi ton fichier acmelog complet pour analyse car là ce n'est qu'un extrait pas forcément révélateur du problème. Que dit aussi le fichier "acme_renew_python.log.1" ?, Envoies le moi STP. De plus, précédemment tu as parlé (message à l'appui) d'un problème de "consumer key". Est-il toujours d'actualité ou pas car tu n'en parles plus maintenant ? Cordialement oracle7😉 0 Citer
bruno78 Posté(e) le 29 septembre 2020 Posté(e) le 29 septembre 2020 (modifié) @oracle7, @kerod, bonjour, chemins en "dur" : dans le script Python, et depuis le début, sont en "dur" les 2 variables SYNOCERTS = "/usr/syno/etc/certificate" & LOCALCERT = "/usr/local/etc/certificate". Aucune raison de les changer. Ceci dit si vous avez fait une installation "exotique" de acme.sh, il faudra mettre à jour dans le fichier Python. Mais ce cas ne devrait pas arriver (ou alors pour de bonnes raisons qu'il faudra m'expliquer) troisième chemin : ACMECERT. On va chercher sa valeur dans le fichier géré par acme.sh (variable CERT_HOME dans le fichier) : /usr/local/share/acme.sh/account.conf. Typiquement, ACMECERT vaut /volume1/Certs). Si tu lances un test à blanc, tu dois voir en début de log les lignes suivantes: -- SYNOCERT : /usr/syno/etc/certificate -- LOCALCERT : /usr/local/etc/certificate -- ACMECERTS : /volume1/Certs sauf erreur de ma part, il n'y a pas eu d'évolution sur ces chemins dans les différentes versions du script (dans les toutes premières versions, ACMECERTS était codé en dur me semble t'il, mais à cette même valeur. Lancement de la commande acme.sh ... pour renouveler le certificat : avant de lancer la commande de renouvellement, on exporte systématiquement les 4 variables d'environnement suivantes : os.environ["SYNO_Create"] = "1", os.environ["SYNO_Username"] = SAVED_SYNO_Username, os.environ["SYNO_Password"] = SAVED_SYNO_Password, os.environ["SYNO_DID"] = SAVED_SYNO_DID Ces variables sont récupérées dans le fichier de configuration du domaine, soit ACMECERTS/ndd.tld/ndd.tld.conf, càd en clair : /volume1/Certs/ndd.tld/ndd.tld.conf le corolaire qui en découle : à aucun moment la clé CK n'est traité par le script Python. => seul acme.sh traite cette clé (comme bon lui semble) Dans le log du script Python, effectivement on indique "nouveau certificat par défaut: xxxx" même si il n'a pas été renouvelé, et dans ce cas on ajoute comme tu l'as vu la précision "le certificat n'a pas été renouvelé". Je vais modifier la formulation pour être plus clair. Mais ça veut dire clairement que le certificat par défaut est toujours le même après qu'avant, que acme.sh ne l'a pas renouvelé pour quelque raison que ce soit. l’échec que tu constate est dû à acme.sh, pour une raison qu'il reste à déterminer. Et pour cela un log complet acmelog serait très utile. Enfin expérience personnelle avec acme.sh et la clé CK : il m'est déjà arrivé que l'authentification soit refusée pour de multiples raisons : a) clé mal recopiée (ça arrive, mais si cela a fonctionné une première fois, elle doit être bonne), b) durée de validité expirée auprès d'ovh. Dans ce cas dans le acmelog il y a un lien demandant de se re-authentifier. Il suffit de le suivre et c'est bon. c) enfin, et cela m'est arrivé aussi, sans rien changer ça ne marche pas au premier essai mais ça fonctionne au second sans n'avoir rien touché !!! frustrant mais c'est comme ça (pb chez ovh ? surcharge ? temps de réponse ? ....) Voilà ce que je peux te dire avec les éléments des posts précédents. En cas de nouvel echec, merci de nous envoyer (en MP de préférence et anonymisés si tu le souhaites) les logs complets acmelog et acme_renew_python.log.1 Cdt Bruno78 Modifié le 29 septembre 2020 par bruno78 typo 0 Citer
kerod Posté(e) le 29 septembre 2020 Posté(e) le 29 septembre 2020 (modifié) @bruno78 j’ai tout blanchi et envoyé à @oracle7 hier soir. pas si simple que ça avec tout les token et lien envoyant vers des données de certificat. pour finir voici le début du log. -- acme_renew release : Version 1.44 Released -- 21-aout-2020 -- version Python system : Python 2.7.12 -- SYNOCERT : /usr/syno/etc/certificate -- LOCALCERT : /usr/local/etc/certificate -- ACMECERTS : /volume1/certs -- ndd.tld : -- certtype : RSA -- scriptdir : /volume1/certs/Acme_renew -- log [-l] : True -- clean [-c] : False -- force [-f] : False -- test [-t] : False Modifié le 29 septembre 2020 par kerod 0 Citer
bruno78 Posté(e) le 29 septembre 2020 Posté(e) le 29 septembre 2020 (modifié) @kerod@oracle7, Parfait. On attend donc l'analyse du fichier log par @oracle7 Je reste à l'écoute .... PS : @kerod : si je peux me permettre, stp, lorsque tu anonymises, plutôt que de laisser un blanc à l'emplacement des valeurs masquées, mets plutôt quelque chose du genre "ndd.tld", ou "xxxx.yyy", ... . Cela permet de savoir qu'il y avait bien un paramètre et qu'il a été masqué, plutôt que de croire que le paramètre est manquant. Dans l'exemple de ton début de log, la ligne "--ndd.tld : " => ma première réaction a été de dire "tiens il manque un paramètre, curieux !" Puis je me suis dit "non c'est ok, il a simplement été masqué". Merci Modifié le 29 septembre 2020 par bruno78 0 Citer
kerod Posté(e) le 29 septembre 2020 Posté(e) le 29 septembre 2020 @bruno78 Le remplacement a été simple. Rechercher / Remplacer. Si c'est comme ça, c'est que c'est la log qui l'a sortie ainsi. 0 Citer
Pinpon_112 Posté(e) le 30 septembre 2020 Posté(e) le 30 septembre 2020 Voilà, je voudrais savoir ceci : Si je change de NAS (depuis 418J vers 920+), dois-je refaire une procédure de création complète ou est-il possible de migrer les certificats et scripts automatique ? Merci pour votre aide. 0 Citer
oracle7 Posté(e) le 30 septembre 2020 Auteur Posté(e) le 30 septembre 2020 @Pinpon_112 Bonjour, Il suffira juste de : Avant toutes choses, sauvegarder sur un PC/Mac : Les fichiers du certificat contenus dans "/volume1/Certs/tonDomaine.tld/" soit le répertoire "tonDomaine.tld" au complet. Les fichiers "account.conf", "acme.sh.env" et "http.header" contenus dans le répertoire "/usr/local/share/acme.sh/". Le script python "acme_renew.py" contenu dans le répertoire "volume1/Scripts". Après le changement de NAS : Réinstaller le Shell script "acme.sh" ( voir § 2 du TUTO) qui recréera notamment le répertoire "/volume1/Certs/". Restorer les fichiers du certificats donc le dossier complet "tonDomaine.tld" dans "volume1/Certs". Restorer les fichiers "account.conf", "acme.sh.env" et "http.header" dans le répertoire "/usr/local/share/acme.sh/". Restorer le fichier "acme_renew.py" dans le répertoire "volume1/Scripts". Recréer dans DSM la tâche programmée de renouvellement ( voir § 6 du TUTO). Recréer le certificat dans DSM en important les fichiers "tonDomaine.tld.key", "tonDomaine.tld.cer" et "ca.cer" issus du répertoire "/volume1/Certs/tonDomaine.tld/". (Bien penser à donner la même description qu'auparavant à ce certificat et le déclarer par défaut). Configurer le certificat pour l'appliquer à tous les services. Dans une session SSH sous root, faire un test en exécutant la commande "python|python3 /volume1/Scripts/acme_renew.py -t -l tonDomaine.tld" Analyser les fichiers log "acmelog" et "acme_renew_python.log.1" situés dans "/volume1/Certs/Acme_renew/" pour vérifier que tout est clair (ie pas d'erreurs). Voilà en espérant que je n'ai rien oublié. Cordialement oracle7😉 0 Citer
Pinpon_112 Posté(e) le 30 septembre 2020 Posté(e) le 30 septembre 2020 @oracle7 Merci pour ton aide. Vais essayer de ne pas me planter 😉 0 Citer
oracle7 Posté(e) le 30 septembre 2020 Auteur Posté(e) le 30 septembre 2020 @Pinpon_112 Bonjour, Surtout prends ton temps et soit très attentif à ce que tu fait et il n'y aura aucun problème ... même si à 99% du temps les problèmes viennent de l'interface chaise/clavier 😜 Cordialement oracle7😉 0 Citer
hieronimus Posté(e) le 2 octobre 2020 Posté(e) le 2 octobre 2020 hello merci pour ce tuto, j'ai bien suivi le tuto est j'ai pu créer mon certificat mais j'ai une erreur avec le script de renouvellement : -- Le nom de domaine (ndd.tld) est errone ou mal configure avec acme.sh. -- Arret du script de renouvellement du certificat comment je peut debogger le script pour voir ce qui ne lui plait pas ? le fichier account.conf ne contenait pas de clé OVH_CK ou SAVED_OVH_CK je l'ai rajouté à la main et cela ne change rien . j'ai sauvegarder toutes mes manipulation effectué dans PUTTY tu me dira ce que tu veux . et ce que je dois cacher comme informations 🙂 . Merci 0 Citer
oracle7 Posté(e) le 2 octobre 2020 Auteur Posté(e) le 2 octobre 2020 (modifié) @hieronimus Bonjour, il y a 31 minutes, hieronimus a dit : Le nom de domaine (ndd.tld) est errone ou mal configure avec acme.sh. Le script vérifie que le nom de domaine figurant dans la commande de renouvellement est conforme à celui qui a été enregistré dans le fichier ndd.tld.conf. Donc si tu as ce message, c'est que tu l'as certainement mal saisi dans la commande de renouvellement (python /volume1/Scripts/acme_renew.py -l votre-domaine.tld) . Vérifies cela. OU Si tu as exécuté le script python en mode manuel (avec l'option -f) dans une session SSH avec PuTTY pour forcer le renouvellement, c'est que tu as aussi mal saisi la commande. Puisque tu dis avoir sauvegardé tes manipulations sous PuTTY, examines les attentivement à ce niveau. Je ne peux te dire mieux sans les voir. Si tu veux, envoies moi en MP pour analyse, tes fichiers logs acmelog et acme_renew.log.1 mais avant, caches, en fait remplaces ton domaine par "ndd.tld" et masques tes éventuels identifiant/MdP ainsi que les valeurs des clés OVH. Pour ton info il n'existe pas de variable SAVED_OVH_CK. Seulement OVH_CK. Cordialement oracle7😉 Modifié le 2 octobre 2020 par oracle7 0 Citer
hieronimus Posté(e) le 3 octobre 2020 Posté(e) le 3 octobre 2020 @oracle7 je viens de voir dans le script une vérification de Le_Domain et Le_Alt. moi dans mon fichier ndd.tld.conf j'ai Le_Domain='ndd.tld' Le_Alt='*.ndd.tld,*.abap.ndd.tld,*.java.ndd.tld,*.wso2.ndd.tld' et je lance la commande python /volume1/Scripts/acme_renew.py -l ndd.tld et le fichier acme_renew.log.1 ne contient rien sauf : 10/03/2020 10:45:23 AM INFO:>> Lancement du script acme_renew.py 10/03/2020 10:45:23 AM INFO:>> Si option -h ou -v, alors pas d'autre log je ne sais pas si c'est les sous domaines qu'il n'aiment pas. 0 Citer
bruno78 Posté(e) le 3 octobre 2020 Posté(e) le 3 octobre 2020 Bonjour @hieronimus, c'est bizarre ! et que contient /volume1/Certs/Acme_renew/acmelog stp ? il faudrait avoir à la fois ta console (putty ou autre), acme_renew_python.log.1 et acmelog; as-tu passé cette étape qui vient juste après le lancement , la vérification du ndd, et recapitule les arguments ? -- acme_renew release : Version 1.44 Released -- 21-aout-2020 -- version Python system : Python 3.5.1 -- SYNOCERT : /usr/syno/etc/certificate -- LOCALCERT : /usr/local/etc/certificate -- ACMECERTS : /volume1/Certs -- ndd.tld : xxxxxxx.ovh -- certtype : RSA -- scriptdir : /volume1/Certs/Acme_renew -- log [-l] : True -- clean [-c] : False -- force [-f] : False -- test [-t] : False Il faut que je vérifie ma routine de vérification du ndd.tld, c'est peut-être elle qui n'apprécie pas tous les sous domaines. Je n'avais pas envisagé ce cas de figure. Je n'avais envisagé uniquement le cas de figure : Le_Domain='ndd.tld' Le_Alt='*.ndd.tld' Je regarde ce qu'il en est ... Cdt Bruno78 0 Citer
bruno78 Posté(e) le 3 octobre 2020 Posté(e) le 3 octobre 2020 @hieronimus, @oracle7 effectivement ma procédure "checkndd" ne prenait pas ce cas de figure en compte. J'ai fait une correction. Je vous la livre à tous les 2 en MP uniquement le temps qu'elle soit validée. Cdt Bruno78 0 Citer
oracle7 Posté(e) le 3 octobre 2020 Auteur Posté(e) le 3 octobre 2020 (modifié) @hieronimus, @bruno78 Pour mémoire, dans ton message initial tu ne parlais que de "ndd.tld" erroné. Donc sans plus d'informations, mon analyse et ma réponse se sont limitées à l'examen du "ndd.tld". Bien : maintenant, indirectement tu viens de mettre le doigt sur un point qui nous avait échappé car non envisagé. C'est très bien et je t'en remercie car on va pouvoir corriger et prendre en compte ce cas de figure. J'en conclue aussi, qu'il nous faut modifier le message d'erreur pour être plus précis suite au contrôle qui est effectué pour prendre en compte aussi dans le message un défaut sur "Le_Alt". Accessoirement je m'étonne à propos du contenu de "Le_Alt". A mon humble avis il n'est pas nécessaire de préciser les wilcards suivants : "*.abap.ndd.tld,*.java.ndd.tld,*.wso2.ndd.tld" dans le champ "Autres noms de l'objet" (SAN). Je me permet de te rappeler que les noms de domaines répondent à une structure hiérarchique dont le sommet est le "tld". En conséquence, ton ajout est inutile car ces domaines de 4ème et 3ème niveau ("*.abap.ndd.tld,*.java.ndd.tld,*.wso2.ndd.tld") sont couverts par "*.ndd.tld". Indirectement, c'est peut-être aussi pour cela que implicitement cet aspect (ton ajout) n'a pas été envisagé car 'est une règle évidente. Cordialement oracle7😉 Modifié le 3 octobre 2020 par oracle7 0 Citer
hieronimus Posté(e) le 3 octobre 2020 Posté(e) le 3 octobre 2020 @oracle7, @bruno78 Oui je parlais que de ndd.tld car c'etait le message que j'avais 🙂 en regardant le scrip (je connais pas python mais étant développeur abap j'ai des reflexes 🙂 ) je test le script et vous tiens informé. Le script s'exécute en mode test sans problème . merci pour la réactivité 🙂 0 Citer
oracle7 Posté(e) le 3 octobre 2020 Auteur Posté(e) le 3 octobre 2020 @hieronimus Bonjour, Lors de tes tests, attention de ne pas dépasser la limitation de Let'sEncrypt fixée à 5 essais par semaine ! Après tu serais bloqué pour une semaine à compter de la dernière tentative. Cordialement oracle7😉 0 Citer
Jeff777 Posté(e) le 3 octobre 2020 Posté(e) le 3 octobre 2020 @oracle7 Tu ne préconises pas l'emploi du --staging? ça évite de griller ses cartouches pour des erreurs d'inattention. ça nécessite de remettre les fichiers dans l'état initial pour le test suivant mais tu seras dire quels sont ceux qui risquent d'être impactés par le script. 0 Citer
oracle7 Posté(e) le 3 octobre 2020 Auteur Posté(e) le 3 octobre 2020 @Jeff777 Bonjour, Effectivement tu as raison c'est une solution palliative, mais je préfère ne pas trop en parlé car comme tu le dis toi même et à juste titre : "ça nécessite de remettre les fichiers dans l'état initial pour le test suivant". Du coup selon le niveau de l'utilisateur (qui est difficile à appréhender tu en conviendras aussi aisément), ce sont des manipulations loin d'être anodines et qui peuvent être sources de beaucoup d'erreurs. Voilà c'est tout ... Cordialement oracle7😉 0 Citer
TuringFan Posté(e) le 3 octobre 2020 Posté(e) le 3 octobre 2020 (modifié) Le 13/09/2020 à 22:43, oracle7 a dit : @TuringFan Bonjour, Si j'étais toi (en supposant que tes 3 clés OVH sont bien sauvegardées) : AVANT toutes choses ! Vérifier qu'il n'y a pas d'usage de caractères "exotiques" dans les identifiants et MdP sinon à corriger impérativement. Pas la peine de réinstaller acme.sh. Faire éventuellement un update et sauf si vraiment tu as un doute, alors désinstalles (cf google) et réinstalles acme.sh selon le TUTO. Nettoyer avec le script et l'option "-c" (acme.sh doit être opérationnel). Supprimer dans DSM le certificat et toutes les anciennes instances de celui-ci après avoir sauvegarder les fichiers "*.pem" correspondants pour le cas où. Supprimer aussi les répertoires "ndd.tld" et "Acme_renew" dans "/volume1/Certs". On conserve les répertoires "/volume1/Certs" et "/volume1/Scripts". Reprendre le processus au début sauf la partie chez OVH (§ 3.1 uniquement) MAIS ne pas omettre l'exportation des variables d'environnement (à tous les niveaux du processus !). Si certaines actions semblent avoir déjà été faites dans les tentatives précédentes, bien s'assurer qu'elles sont conformes aux attendus. Voilà j'espère ne rien avoir oublié. Cela peut paraître radical mais après, cela devrait le faire normalement si tu es très attentif à tes actions. Prends ton temps et assures-toi de chaque action avant de passer à la suivante. Si besoin lis et relis le TUTO... Je ne peux te dire mieux. Cordialement oracle7😉 @oracle7 et @bruno78 Pardon pour mon retour tardif, rentrée très chargée. Je viens de suivre pas à pas cette méthode et j'ai un problème au niveau de déploiement du certificat. /usr/local/share/acme.sh$ ./acme.sh --deploy -d "$CERT_DOMAIN" --deploy-hook synology_dsm ./acme.sh: line 237: /volume1/Certs/Acme_renew/acmelog: No such file or directory ./acme.sh: line 237: /volume1/Certs/Acme_renew/acmelog: No such file or directory ./acme.sh: line 237: /volume1/Certs/Acme_renew/acmelog: No such file or directory ./acme.sh: line 237: /volume1/Certs/Acme_renew/acmelog: No such file or directory ./acme.sh: line 237: /volume1/Certs/Acme_renew/acmelog: No such file or directory ./acme.sh: line 237: /volume1/Certs/Acme_renew/acmelog: No such file or directory ./acme.sh: line 237: /volume1/Certs/Acme_renew/acmelog: No such file or directory ./acme.sh: line 237: /volume1/Certs/Acme_renew/acmelog: No such file or directory ./acme.sh: line 237: /volume1/Certs/Acme_renew/acmelog: No such file or directory [Sat Oct 3 17:23:25 CEST 2020] Logging into localhost:5001 ./acme.sh: line 237: /volume1/Certs/Acme_renew/acmelog: No such file or directory ./acme.sh: line 237: /volume1/Certs/Acme_renew/acmelog: No such file or directory ./acme.sh: line 237: /volume1/Certs/Acme_renew/acmelog: No such file or directory ./acme.sh: line 237: /volume1/Certs/Acme_renew/acmelog: No such file or directory ./acme.sh: line 237: /volume1/Certs/Acme_renew/acmelog: No such file or directory [Sat Oct 3 17:23:25 CEST 2020] Please refer to https://curl.haxx.se/libcurl/c/libcurl-errors.html for error code: 60 ./acme.sh: line 237: /volume1/Certs/Acme_renew/acmelog: No such file or directory ./acme.sh: line 237: /volume1/Certs/Acme_renew/acmelog: No such file or directory ./acme.sh: line 237: /volume1/Certs/Acme_renew/acmelog: No such file or directory [Sat Oct 3 17:23:25 CEST 2020] Unable to authenticate to localhost:5001 using https. ./acme.sh: line 237: /volume1/Certs/Acme_renew/acmelog: No such file or directory [Sat Oct 3 17:23:25 CEST 2020] Check your username and password. C'est un problème que j'avais déjà rencontré lors de la première exécution (réussie) de ce Tuto (sauf le sujet des acmelog) mais je ne me souviens plus comment je l'avais passé. Voici ce qu'indique l'erreur 60 : CURLE_PEER_FAILED_VERIFICATION (60) The remote server's SSL certificate or SSH md5 fingerprint was deemed not OK. This error code has been unified with CURLE_SSL_CACERT since 7.62.0. Its previous value was 51. Je comprends que c'est un problème de clef SSH pourtant je me suis bien connecté en root via WinSCp pour exécuter les commandes du tuto ... Au passage, concernant le le mdp admin je l'ai changé mais je pensais justement que les simple quote " ' " permettaient justement "d’échapper" les caractères spéciaux ? Cordialement, Modifié le 3 octobre 2020 par TuringFan 0 Citer
Messages recommandés
Rejoindre la conversation
Vous pouvez publier maintenant et vous inscrire plus tard. Si vous avez un compte, connectez-vous maintenant pour publier avec votre compte.