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

oracle7 · le 3 octobre 2020

Bonjour,

il y a 37 minutes, TuringFan a dit :

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 ?

Oui "dans le principe" pour les caractères spéciaux "que j'appellerai "standard" du style " / * : ? " < > | " mais pas pour les autres caractères dits "exotiques".

Donc finalement sans trop m'avancer j'en conclue que tu as laissé un ou plusieurs caractères de ce genre dans ton mot de passe d'où l'erreur rencontrée :

il y a 37 minutes, TuringFan a dit :

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

Je crains qu'il ne te faille encore modifier ton mot de passe.

Par ailleurs, il me semblait pourtant t'avoir expliquer comment constituer un mot de passe ... (lettres minuscules, majuscules, chiffres, pas d'accents) le tout avec une longueur minimum de 12 caractères.

Pour mémoire ce que dit aussi à ce propos @fenrir dans son TUTO sur la sécurisation des accès au NAS :

Citation

Un bon mot de passe c'est un mot de passe facile à retenir ou à retrouver de tête (donc pas sur un post-it) et relativement long. On lit souvent qu'il faut utiliser des caractères spéciaux car ça rend les mots de passe plus complexe. C'est vrai si ces 3 conditions sont réunies :

les utilisateurs arrivent à s'en souvenir sans le noter

les utilisateurs arrivent à le taper (clavier mobile, braille, étranger, ...)

sa longueur est d'au moins 12 caractères

Je trouve pour ma part qu'il est plus facile d'utiliser un long mot de passe avec des lettres, des chiffres et des majuscules qu'un mot de passe avec des caractères spéciaux.

Pour ce qui est de la sécurité, imposer des caractères spéciaux à un mot de passe ne le complexifie que d'un "bit" en équivalent cryptographique. Ajouter 2 caractères "normaux" le complexifie de 11 bits.

Pour un humain, deviner une chaine de 10 caractères spéciaux est très complexe, pour une machine c'est plus facile qu'une chaine de 10 caractères "normaux".

C'est on ne peux plus clair il me semble, non ?

Pour ce qui est des lignes d'erreurs liées à acmelog, saches qu'il n'y a aucun lien avec la commande de déploiement du certificat car le fichier acmelog n'est créé qu'avec le script python de renouvellement.

Pour l'erreur 60 je pense, mais je peux me tromper, que c'est un effet de bord de l'erreur précédente.

Cordialement

oracle7😉

Modifié le 3 octobre 2020 par oracle7

TuringFan · le 3 octobre 2020

@oracle7,

Merci pour ton retour rapide.

il y a 52 minutes, oracle7 a dit :

j'en conclue que tu as laissé un ou plusieurs caractères de ce genre

non, j'ai suivi à la lettre tes instructions : aucun caractère autre qu'une lettre ou un chiffre

il y a 52 minutes, oracle7 a dit :

Par ailleurs, il me semblait pourtant t'avoir expliquer comment constituer un mot de passe ... (lettres minuscules, majuscules, chiffres, pas d'accents) le tout avec une longueur minimum de 12 caractères.

C'est exactement ce que j'ai fait

il y a 53 minutes, oracle7 a dit :

C'est on ne peux plus clair il me semble, non ?

Oui, j'ai respecté cette règle.

il y a 53 minutes, oracle7 a dit :

Pour ce qui est des lignes d'erreurs liées à acmelog, saches qu'il n'y a aucun lien avec la commande de déploiement du certificat car le fichier acmelog n'est créé qu'avec le script python de renouvellement.

Je viens de ré-essayer à l’instant via Win SCP en coupant la connexion puis en en ouvrant une nouvelle et en tapant les instructions suivantes :

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

Pas de message d’erreur dans la console

. "/usr/local/share/acme.sh/acme.sh.env"
source /root/.profile

Pas de message d’erreur dans la console

ACME_HOME="/usr/local/share/acme.sh"
CERT_HOME="/volume1/Certs"

Pas de message d'erreur dans la console

export OVH_END_POINT=ovh-eu
export OVH_AK="votre application key"
export OVH_AS="votre application secret"
export OVH_CK="votre consumer key"

Pas de message d'erreur dans la console

cd $ACME_HOME
export CERT_DOMAIN="votre-domaine.tld"
export CERT_WDOMAIN="*.votre-domaine.tld"
export CERT_DNS="dns_ovh"

Pas de message d'erreur dans la console

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

C'est la que j'obtiens des erreurs sur la console

/usr/local/share/acme.sh$ ./acme.sh --issue --keylength 4096 -d "$CERT_DOMAIN" -d "$CERT_WDOMAIN" --dns "$CERT_DNS"
./acme.sh: line 257: /volume1/Certs/Acme_renew/acmelog: No such file or directory
./acme.sh: line 257: /volume1/Certs/Acme_renew/acmelog: No such file or directory
./acme.sh: line 257: /volume1/Certs/Acme_renew/acmelog: No such file or directory
./acme.sh: line 257: /volume1/Certs/Acme_renew/acmelog: No such file or directory
./acme.sh: line 257: /volume1/Certs/Acme_renew/acmelog: No such file or directory
./acme.sh: line 257: /volume1/Certs/Acme_renew/acmelog: No such file or directory
./acme.sh: line 257: /volume1/Certs/Acme_renew/acmelog: No such file or directory
./acme.sh: line 257: /volume1/Certs/Acme_renew/acmelog: No such file or directory
./acme.sh: line 257: /volume1/Certs/Acme_renew/acmelog: No such file or directory
./acme.sh: line 257: /volume1/Certs/Acme_renew/acmelog: No such file or directory
./acme.sh: line 257: /volume1/Certs/Acme_renew/acmelog: No such file or directory
./acme.sh: line 257: /volume1/Certs/Acme_renew/acmelog: No such file or directory
./acme.sh: line 257: /volume1/Certs/Acme_renew/acmelog: No such file or directory
./acme.sh: line 257: /volume1/Certs/Acme_renew/acmelog: No such file or directory
./acme.sh: line 257: /volume1/Certs/Acme_renew/acmelog: No such file or directory
./acme.sh: line 257: /volume1/Certs/Acme_renew/acmelog: No such file or directory
./acme.sh: line 257: /volume1/Certs/Acme_renew/acmelog: No such file or directory
./acme.sh: line 257: /volume1/Certs/Acme_renew/acmelog: No such file or directory
./acme.sh: line 257: /volume1/Certs/Acme_renew/acmelog: No such file or directory
./acme.sh: line 257: /volume1/Certs/Acme_renew/acmelog: No such file or directory
./acme.sh: line 257: /volume1/Certs/Acme_renew/acmelog: No such file or directory
./acme.sh: line 257: /volume1/Certs/Acme_renew/acmelog: No such file or directory
./acme.sh: line 257: /volume1/Certs/Acme_renew/acmelog: No such file or directory
./acme.sh: line 257: /volume1/Certs/Acme_renew/acmelog: No such file or directory
./acme.sh: line 257: /volume1/Certs/Acme_renew/acmelog: No such file or directory
./acme.sh: line 257: /volume1/Certs/Acme_renew/acmelog: No such file or directory
./acme.sh: line 257: /volume1/Certs/Acme_renew/acmelog: No such file or directory
./acme.sh: line 257: /volume1/Certs/Acme_renew/acmelog: No such file or directory
[Sat Oct  3 18:52:17 CEST 2020] Domains not changed.
[Sat Oct  3 18:52:17 CEST 2020] Skip, Next renewal time is: Wed Dec  2 15:01:25 UTC 2020
[Sat Oct  3 18:52:17 CEST 2020] Add '--force' to force to renew.

Que dois-je faire ? Ignorer ?

Merci d'avance,

PS : j'ai évidemment remplacé les valeurs entre guilelment par mes valeurs (mon domaine, mes clefs OVH, etc.).

bruno78 · le 3 octobre 2020

@TuringFan, @oracle7,

je vais peut-être enfoncer des portes ouvertes, désolé, mais ne suivant ce pb que de loin ...

est-ce que le répertoire ./Acme_renew existe ?
est-ce que le fichier ./Acme_renew/acmelog existe ?
quelle est la valeur de la variable LOG_FILE dans le fichier /usr/local/share/acme.sh/account.conf

Merci

oracle7 · le 3 octobre 2020

@TuringFan

Bonjour,

En premier lieu je comprends que tu reprends le processus de création du certificat Oui/Non ?

Si oui alors vu la fin du message ci-dessus :

[Sat Oct  3 18:52:17 CEST 2020] Domains not changed.
[Sat Oct  3 18:52:17 CEST 2020] Skip, Next renewal time is: Wed Dec  2 15:01:25 UTC 2020
[Sat Oct  3 18:52:17 CEST 2020] Add '--force' to force to renew.

si tu reprends donc le processus de création pour le même domaine "ndd.tld", il serait alors judicieux de supprimer (déplacer ailleurs) le répertoire "/volume1/Certs/ndd.tld". Car là, comme il le trouve, il ne peux donc le créer et te propose même de 'ajouter l'option --force pour forcer la nouvelle création en remplaçant l'existant. Tu me suis ?

Donc en clair, si tu veux reprendre le processus de création pour le même domaine il te faut nettoyer préalablement toutes trace du précédent certificat pour ce domaine.

Par ailleurs, dans le même temps le fichier "/usr/local/share/acme.sh/account.conf" a conservé le chemin du fichier log que doit utiliser acme.sh pour écrire ses logs, au travers de la variable d'environnement "LOGFILE" qui a été renseignée avec la valeur "/volume1/Certs/Acme_renew/acmelog". Le message d'erreur vient du fait que tu as dû certainement supprimer le fichier 'acmelog' ou même le répertoire 'Acme_renew' et ducoup il ne les trouve plus. Je ne me souviens pas et n'ai pas d'archives, de la valeur initiale de la variable "LOGFILE" pour la restorer. Donc il te faut maintenant a minima recréer dans "/volume1/Certs/" le répertoire "Acme_renew" et créer à l'intérieur de celui-ci un fichier vide nommé "acmelog" pour ne plus avoir d'erreurs.

Je viens de voir que @bruno78 a percuter dans le même sens pendant que j'écrivais ces lignes.

Cordialement

oracle7😉

bruno78 · le 3 octobre 2020

@oracle7, @TuringFan,

valeur d'origine dans account.conf : LOG_FILE='/usr/local/share/acme.sh/acme.sh.log'

oracle7 · le 3 octobre 2020

@TuringFan

Bonjour,

Tu peux remercier @bruno78 pour cette information qui va te permettre de corriger la valeur dans le fichier "accoun.conf".

Ainsi, comme tu reprends le processus de création, tu ne seras pas "pollué" par un paramétrage qui n'arrive normalement que bien plus tard.

Cordialement

oracle7😉

TuringFan · le 3 octobre 2020

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

@oracle7 et @bruno78

Merci beaucoup pour votre aide.
Je pense avoir résolu le premier problème et généré le certificat en repartant d'un environnement propre.

Après

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

J'obtiens bien

[Sat Oct  3 23:14:18 CEST 2020] Your cert is in  /volume1/Certs/ndd.tld/ndd.tld.cer
[Sat Oct  3 23:14:18 CEST 2020] Your cert key is in  /volume1/Certs/ndd.tld/ndd.tld.key
[Sat Oct  3 23:14:18 CEST 2020] The intermediate CA cert is in  /volume1/Certs/ndd.tld/ca.cer
[Sat Oct  3 23:14:18 CEST 2020] And the full chain certs is there:  /volume1/Certs/ndd.tld/fullchain.cer

En revanche le certificat dans le DSM apparait toujours comme expiré

Après

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

Je ne parviens toujours pas à déployer.

[Sat Oct  3 23:16:42 CEST 2020] Logging into localhost:5001
[Sat Oct  3 23:16:42 CEST 2020] Please refer to https://curl.haxx.se/libcurl/c/libcurl-errors.html for error code: 60
[Sat Oct  3 23:16:42 CEST 2020] Unable to authenticate to localhost:5001 using https.
[Sat Oct  3 23:16:42 CEST 2020] Check your username and password.
[Sat Oct  3 23:16:42 CEST 2020] Error deploy for domain:ndd.tld
[Sat Oct  3 23:16:42 CEST 2020] Deploy error.

Je suis pourtant certain de mes logins / password et je suis bien logé en "root@monNAS :" depuis PuttY.

J'ai essayé depuis PuttY et WinSCP avec les couples https / 5001 et http / 5000 ainsi qu'avec l'historique de mes trois dernier mdp !

Je me souviens avoir eu ce problème lors d'une de mes toutes premières tentatives mais je ne me souviens plus comment j'avais passé le problème ...

Avez-vous une idée ?

Merci d'avance,

Modifié le 3 octobre 2020 par TuringFan

oracle7 · le 3 octobre 2020

@TuringFan

Bonsoir,

il y a 16 minutes, TuringFan a dit :

J'ai toujours


[Sat Oct  3 22:50:47 CEST 2020] Domains not changed.
[Sat Oct  3 22:50:47 CEST 2020] Skip, Next renewal time is: Wed Dec  2 20:44:55 UTC 2                020
[Sat Oct  3 22:50:47 CEST 2020] Add '--force' to force to renew.

Je crains que tu ais lu en diagonale ma réponse précédente :

Il y a 3 heures, oracle7 a dit :

si tu reprends donc le processus de création pour le même domaine "ndd.tld", il serait alors judicieux de supprimer (déplacer ailleurs) le répertoire "/volume1/Certs/ndd.tld". Car là, comme il le trouve, il ne peux donc le créer et te propose même de 'ajouter l'option --force pour forcer la nouvelle création en remplaçant l'existant. Tu me suis ?

Il te faut vider le répertoire "/volumes/Certs" de tout dossier "ndd.tld". Déplaces ce dossier "ndd.tld" ailleurs pour le sauvegarder au cas où.

Ensuite tu pourras relancer la commande :

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

Cordialement

oracle7😉

TuringFan · le 3 octobre 2020

[mention=79264]TuringFan[/mention]
Bonsoir,
Il te faut vider le répertoire "/volumes/Certs" de tout dossier "ndd.tld". Déplaces ce dossier "ndd.tld" ailleurs pour le sauvegarder au cas où.
Ensuite tu pourras relancer la commande :
./acme.sh --issue --keylength 4096 -d "$CERT_DOMAIN" -d "$CERT_WDOMAIN" --dns "$CERT_DNS"
Cordialement
oracle7

Merci,

J’avais pourtant copié puis supprimé ce répertoire pour ensuite le recréer « à la main » ainsi qu’un fichier vide acmelog avant de re-essayer d’exécuter les commandes ...

bruno78 · le 4 octobre 2020

@TuringFan bonjour,

de ce que je comprends, tu avais bien hier soir recréé ton certificat, tout neuf. Pour t'en convaincre, il faut aller vérifier les dates dans /volume1/Certs/ndd.tld/ndd.tld.conf.... Mais il ne restait "plus qu'à" le déployer. Normal qu'il apparaisse qu'expiré dans DSM, puisque tu ne vois que l'ancien, mais pas le nouveau qui n'a pas été déployé.

Le message est clair à l'échec du déployement : enable to authenticate / check user passowrd.

Puis-je suggérer que pour la durée du test, quelques minutes, tu définisses un mot de passe simple ? genre "leschemisesdelarchiduchesse", tu le mets dans un fichier texte, puis tu ne t'en sers que par copie/coller. D'où pas de risque d'erreur. Il faut tordre le coup à ce problème d'authentification. Et ne pas oublier ensuite de revenir à un mot de passe FORT.

Cdt

Bruno78

hieronimus · le 4 octobre 2020

@oracle7
@bruno78 je ne sais pas si vous l'avez vu mais mes tests confirment que le script envoyé par Mp fonctionne correctement pour de multiples sous domaines.

bruno78 · le 4 octobre 2020

@hieronimus merci,

c'est toujours bien d'avoir un retour, et encore mieux quand c'est positif. Ce correctif va donc être maintenu puisque validé.

Cdt

Bruno78

TuringFan · le 4 octobre 2020

Il y a 10 heures, bruno78 a dit :

@TuringFan bonjour,

de ce que je comprends, tu avais bien hier soir recréé ton certificat, tout neuf. Pour t'en convaincre, il faut aller vérifier les dates dans /volume1/Certs/ndd.tld/ndd.tld.conf.... Mais il ne restait "plus qu'à" le déployer. Normal qu'il apparaisse qu'expiré dans DSM, puisque tu ne vois que l'ancien, mais pas le nouveau qui n'a pas été déployé.

Le message est clair à l'échec du déployement : enable to authenticate / check user passowrd.

Puis-je suggérer que pour la durée du test, quelques minutes, tu définisses un mot de passe simple ? genre "leschemisesdelarchiduchesse", tu le mets dans un fichier texte, puis tu ne t'en sers que par copie/coller. D'où pas de risque d'erreur. Il faut tordre le coup à ce problème d'authentification. Et ne pas oublier ensuite de revenir à un mot de passe FORT.

Cdt

Bruno78

@bruno78,

Merci pour ton retour.

J'ai mis du temps mais j'ai essayé d'être exhaustif, voici les actons que j'ai fait :

- J'ai modifié mon login au profit de "god"
- J'ai modifié mon mdp au profit de : "azertyuiop123"
- J'ai créé le login et mdp sur un bloc note puis je n'ai fait que des copier-coller depuis cette source
- J'ai repassé le port SSH sur 22
- J'ai passé la sécurité du SSH en "moyenne" dans les paramètres avancés du terminal du SSH
- J'ai tapé les commande dans Win SCP puis PuttY (il y avait bien "@root" au début de la ligne)
- J'ai autorisé l'accès à tous les dossiers et toutes les applications au compte admin "god"
- J'ai paramétré mes variables avec les couples http / 5000 puis https / 5001

Et toujours le même problème : un message d'erreur qui me dit de vérifier mes username et mon password !

Je sèche complètement.

J'ai eu au choix des erreurs 2 ou 60 ou le message ci-dessous (mais pas à chaque fois) :

image.png.ba7e2ac6785e6d6e4bdd473c79b843ee.png

PS : Je suis certain d'avoir eu le même problème la première fois et après réflexion je l'avais stoppé en choisissant http / 5000 plutôt que le couple https / 5001 sur mes variables.

bruno78 · le 4 octobre 2020

@TuringFan,

.... là je sèche ..... mais on est bien d'accord, tu es en véritable accès root (pas en sudo -i) (voir tout début du Tuto d' @oracle7) ??

@oracle7 .... help 🙂

Cdt

Bruno78

oracle7 · le 4 octobre 2020

@TuringFan

Bonjour,

Dans le fichier "/volume1/Certs/ndd.tld/ndd.tld.conf" ton identifiant et ton MdP sont sauvegardés dans des variables SAVED_SYNO_Username et SAVED_SYNO_Password.

Est-ce que l'identifiant et le MdP contenu dans ces variables, sont bien ceux que tu as utilisé à savoir : "god" et "azertyuiop123" ?

On est bien d'accord que cet identifiant et le MdP sont ceux de ton administrateur du NAS ? car grâce à ces variables c'est comme si l'administrateur du NAS faisait lui même le déploiement.

Pour éviter le dernier message, modifie le Timeout de connexion et passes le à 120 sec en éditant les paramètres du site que tu utilises pour te connecter avec WinSCP :

image.png.0188b2961fb291b99afc89407619f8c7.png

il y a une heure, TuringFan a dit :

PS : Je suis certain d'avoir eu le même problème la première fois et après réflexion je l'avais stoppé en choisissant http / 5000 plutôt que le couple https / 5001 sur mes variables.

Il me semble aussi que tu as déjà eu le problème précédemment en choisissant le couple https / 5001. Je te rappelle que le processus de création se passe sur ton réseau local donc, à moins que tu ais des prédateurs sur ce dernier, cela ne sert à rien de faire du HTTPS en local (ni même du VPN) pour moi cela n'a pas de sens, je conçois aisément que l'on veuille verrouiller à l'extrême les choses pour les communications avec l'extérieur mais pas en local). En plus le déploiement se fait sur ton NAS soit le localhost et tu ne déploies pas sur un NAS distant que je saches.

Donc, je t'invite à n'utiliser que le couple http/5000 pour les variables.

Vérifies aussi, si tu utilises la double authentification, que le DID actuel (voir le TUTO pour le récupérer) est bien celui qui est sauvegardé dans la variable SYNO_DID ?

Indirectement c'est aussi cette éventuelle différence qui pourrait conduire au message demandant de vérifier ton identifiant et MdP.

Cordialement

oracle7😉

Pinpon_112 · le 5 octobre 2020

@oracle7 @bruno78

Bonjour,

Aujourd'hui est le jour du renouvellement selon le script... Problème, le renouvellement ne s'est pas fait mais je ne sais pourquoi... 😞

Alors, soit je mets le log complet (il est long) ici ou je l'envoie en MP, c'est comme vous voulez.

Merci pour votre aide.

bruno78 · le 5 octobre 2020

@Pinpon_112, @oracle7,

si possible mets nous un lien de téléchargement en MP,ce sera le plus simple. Et anonymise le log (mais on le traitera avec soins .... :-)

Bruno78

bruno78 · le 5 octobre 2020

@Pinpon_112, @oracle7,

je vois potentiellement ceci :

[Mon Oct 5 00:00:23 CEST 2020] Please open this link to do authentication: https://eu.api.ovh.com/auth/?
credentialTokenXXXXXXXXXXXXXXXXXXXXXXX
[Mon Oct 5 00:00:23 CEST 2020] Here is a guide for you: https://github.com/acmesh-official/acme.sh/wiki/How-to-use-OVHdomain-
api
[Mon Oct 5 00:00:23 CEST 2020] Please retry after the authentication is done.

Donc je conseille de suivre le lien pour (re-)faire l'authentification et retenter ....

Pinpon_112 · le 5 octobre 2020

@oracle7 @bruno78

il y a 7 minutes, bruno78 a dit :

[Mon Oct 5 00:00:23 CEST 2020] Please open this link to do authentication: https://eu.api.ovh.com/auth/?
credentialTokenXXXXXXXXXXXXXXXXXXXXXXX

Lorsque je clique sur le lien, j'ai un message d'erreur.

Que faire ?

bruno78 · le 5 octobre 2020

@Pinpon_112,

est-ce le premier renouvellement que tu tentes ? ou en as-tu déjà fait un qui a marché ? Tu as bien utilisé le Account ID : identifiant principal de connexion chez OVH (de la forme XXXXX-ovh) et non pas l'adresse mail de ton compte ? As-tu fait plusieurs tentatives de créations de clés au départ ?

Cdt

Bruno78

Pinpon_112 · le 5 octobre 2020

@bruno78

il y a 6 minutes, bruno78 a dit :

est-ce le premier renouvellement que tu tentes ?

oui

il y a 6 minutes, bruno78 a dit :

Tu as bien utilisé le Account ID : identifiant principal de connexion chez OVH (de la forme XXXXX-ovh) et non pas l'adresse mail de ton compte ?

Oui

il y a 6 minutes, bruno78 a dit :

As-tu fait plusieurs tentatives de créations de clés au départ ?

J'ai effectivement dû m'y reprendre à plusieurs fois avant d'avoir le bon certificat. J'ai toujours repris les identifiant de l'API qui ont été créé lors de la première tentative.

bruno78 · le 5 octobre 2020

@Pinpon_112, on va attendre qu' @oracle7 passe par là.

Je ne vois rien d'évident par rapports aux traces que je peux avoir par ailleurs.

.Shad. · le 5 octobre 2020

Est-ce que tu avais bien mis une validité infinie à la création de l'API ?
Il se pourrait que la validé ait expiré et que du coup l'authentification ne fonctionne pas car les credentials n'existent plus.
Il faut vérifier dans l'API d'OVH.

Pinpon_112 · le 5 octobre 2020

@.Shad.

il y a 30 minutes, .Shad. a dit :

Est-ce que tu avais bien mis une validité infinie à la création de l'API ?
Il se pourrait que la validé ait expiré et que du coup l'authentification ne fonctionne pas car les credentials n'existent plus.
Il faut vérifier dans l'API d'OVH.

Heuuu, je ne sais pas. Comment fait-on pour vérifier dans l'API ?

oracle7 · le 5 octobre 2020

@Pinpon_112

Bonjour,

Je viens de regarder le log que tu nous as transmis. A part quelques oublis de masquage de ton domaine (pas grave 😋), effectivement il y a eu un problème avec ton authentification sur l'API OVH. Rien d'alarmant cela arrive parfois, habituellement il suffit juste de cliquer sur le lien proposé comme tu l'as fait.

Maintenant, soit tu as mal saisi ton identifiant/MdP à OVH (attention lors des C/C à ne pas prendre de caractères parasites invisibles) soit comme le suggère @.Shad. il est aussi possible que ton autorisation ait expirée du fait de sa validité dépassée. Dans ce cas, si j'étais toi, j'essaierai de recréer un jeu de clés OVH (voir §3 du TUTO) et cette fois en t'assurant de bien sélectionner la valeur "Unlimited" dans le popup du champ "Validity".

PS : Pour ne pas oublier de valeurs lors du masquage, le plus simple est de copier le texte du log dans un éditeur de texte et d'utiliser la fonction chercher/remplacer.

Cordialement

oracle7😉

Modifié le 5 octobre 2020 par oracle7

Connexion

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

Messages recommandés

Meilleurs contributeurs dans ce sujet

Jours populaires

Meilleurs contributeurs dans ce sujet

Jours populaires

Messages populaires

oracle7

bruno78

KreaNum

Images postées

Rejoindre la conversation

Qui est en ligne 2 membres, 0 anonyme, 408 invités (Afficher la liste complète)

Contributeurs populaires

Annonces

Information importante