Aller au contenu

Messages recommandés

Posté(e)

@Pinpon_112

Bonjour,

si j'ai bien compris, en changeant juste la date de validité du cookie grâce à Cookie Quick Manager, je n'aurai pas besoin de changer la valeur du DID. Je trouve ça plus simple 😄 .

Merci beaucoup pour ton conseil !

Bonne fin de journée !

Milkyway

Posté(e)

@milkyway

Tu changes la valeur de la date et ensuite tu changes la valeur dans le script comme expliquez au point 5.1.

Après tu seras tranquille jusqu’à cette date.

Seb


Envoyé de mon iPhone en utilisant Tapatalk

Posté(e) (modifié)
Il y a 18 heures, Pinpon_112 a dit :

@kerod :

Oracle et Bruno propose de l’aide. Dans mon cas, j’ai aussi eu des problèmes et j’ai du recommencer l’installation 3-4 fois au départ et 3 mois plus tard , encore une fois.

Ensuite, j’ai encore eu de l’aide car toujours des problèmes. Maintenant, c’est enfin réglé grâce à leur aide.

Donc si leur solution ne te plaît pas et que tu ne veux pas te remettre en question, arrête de te plaindre et passe ton chemin surtout si tu as trouvé une autre solution

@Pinpon_112

je trouve facile to intervention...aucun contexte et tu te montres...

je vais en donner car c’est de là que vient la déception et non la plainte...

j’ai installé la solution (à 5-6 reprises) dès que je l’ai trouvé et je l’ai remise en question parce qu’il y avait des petites erreurs de codage (elles ont été corrigées à l’époque). Étant dans le codage, j’ai lu le script pour voir ce qu’il faisait et surtout pour le comprendre.

Pour ne pas faire simple, j’ai opté pour la solution à la moins utilisée...Annulé et remplace.

au premier renouvellement, j’ai eu une erreur, j’ai demandé de l’aide et j’en ai eu (j’ai modifié les valeurs de l’api car elles avaient sauté et personne ne m’a dit pourquoi à ce jour...). J’ai relancé le script et il a fonctionné en me donnant une erreur incohérente que j’ai remonté après ma lecture du code...À date, cette erreur est toujours là...j’ai demandé de m’aiguiller sur la logique du code pour que je fasse la modification moi-même, mais au bout de 3 mois sans considération ou réponse (si c’est moins fort), j’abandonne.

tu sais ce n’est pas parce que tu ne fais pas comme les autres qu’il faut dénigrer ce qu’ils font en remettant leur solution en défaut, sans l’avoir éprouvée et j’en suis là.

personne visiblement n’utilise l’annule et remplace, on me dit revoir ta solution, ça marche pour les autres dont moi, mais sans esprit critique pour se dire : je vais vérifier le fonctionnement de l’alternative qui est proposée...

donc si le principe ici est d’être un mouton de faire comme tout le monde et quand il ne veut pas on lui montre du doigt (ses erreurs qu’on ne connaît pas...) ok je me casse...

mon premier message il y a quelque jour était là pour dire qu’il avait toujours la même erreur que j’avais remonté...et on m’a sorti bancale sans en connaître la teneur de l’installation. Même dans l’éducation on ne sort pas ce terme...

mais bravo et merci pour ton intervention 

@Pinpon_112

Modifié par kerod
  • 2 semaines après...
Posté(e)

Bonjour @milkyway, @Pinpon_112 et @oracle7

Je viens de constater à l'instant un problème de certificat avec le message suivant :

[Sat Jan  9 23:46:13 CET 2021] Unable to authenticate to localhost:5000 using http.
[Sat Jan  9 23:46:13 CET 2021] Check your username and password.

J'avais déjà eu ce message lors de mon dernier renouvellement il y a 3 mois et après de nombreuses tentatives et aides j'avais réparé cela en changeant le DID.

Y aurait il une méthode rapide pour changer le DID, je dois avouer que cela fait maintenant 3 mois que je n'ai pas mis mon nez dans les sujets de certificat et je ne me souviens plus du process. Faut il refaire tout le tuto ou simplement changer la valeur du DID dans un fichier ?

PS : je ne savais pas que nous pouvions changer la date de validité du DID, je vais en mettre une dans sacrément longtemps ... Y a t il une contre indication à cela ?

Merci d'avance pour votre aide,

Posté(e) (modifié)

@oracle7 @TuringFan

Bonjour,

Tu ne dois pas tout refaire, il faut juste changer la valeur du DID tel qu’expliqué au point 5.1.

Tu ne peux changer la valeur du DID que via Firefox. Ce n’est pas possible avec Chrome.


Envoyé de mon iPhone en utilisant Tapatalk

Modifié par Pinpon_112
Posté(e)

@oracle7 et @Pinpon_112,

Pardon je n'avais pas vu l'edit.
C'était bien un problème de DID maintenant réglé de façon perenne je pense grâce au changement de date d'expiration à dans 10 ans ...

Petite question pour bien comprendre.

 

  • Le DID est un cookie généré chez le client (mon navigateur).
  • L'intervention via Cookie Quick Manager se fait donc sur le périmètre du client mais en aucun cas sur le NAS.
  • La modification sur le NAS est faite via l'accès en root.


Ce que je ne comprends pas c'est que la génération du certificat semble utiliser un paramètre complètement exogène au NAS : le DID qui est un cookie et donc dépend uniquement du client (notamment pour sa date de validiter).

Bref on dirait que le processus de renouvellement dépend du client ? Je suis un peu perdu la dessus.

Posté(e) (modifié)

@TuringFan

Bonjour,

Excuses moi, mais je crois que tu prends les choses à l'envers.

De ce que j'ai compris (mais je peux me tromper), lorsque tu établis la connexion avec le NAS c'est la 2FA en place sur le NAS qui vérifie l'authentification en exploitant le code à 6 chiffres que tu lui fourni la première fois. Est-il sauvegardé par DSM, je ne saurais te dire, je ne le crois pas, j'imagine que ce code agit un peu à l'instar d'une clé publique.

En parallèle, ton navigateur lui enregistre ce même code d'authentification (cette clé publique pour reprendre mon parallèle et sûrement d'autres informations caractérisant la connexion) dans un cookie afin que lors de ta prochaine connexion, le code soit réutilisé et transmis directement à la requête 2FA pour valider la connexion sans avoir besoin de te le redemander explicitement.

Effectivement, tout cela peut porter quelque peu à confusion et je te comprend aisément, car c'est toi en tant qu'utilisateur qui va chercher (sous root tout de même, donc pas n'importe qui !) ce code par le biais de la valeur du cookie DID pour le fournir au processus acme.sh via la variable d'environnement SYNO_DID afin que acme.sh puisse se connecter au NAS et assurer le rouvellement du certificat LE. Manifestement, acme.sh ne sais pas le retrouver directement dans les arcanes de DSM (si quand bien même DSM l'avait sauvegardé) et utilise le contenu de cette variable pour établir le processus de connexion au NAS.

Je pense aussi qu'il n'y a pas besoin d'être devin pour imaginer que la valeur du cookie est suffisamment alambiquée pour ne pas être utilisable telle quelle, même si elle semble facilement accessible dans les paramètres internes du navigateur. Pour preuve, lorsque le cookie expire (donc change), la connexion ne peut se faire et on se trouve face à bel échec de renouvellement, tel que tu l'as connu récemment. Mais ce n'est que mon avis ...

Cordialement

oracle7😉

Modifié par oracle7
  • 2 semaines après...
Posté(e) (modifié)

Bonjour,

J'ai une erreur au moment du déploiement du certificat...

J'obtiens le message d'erreur suivant:

[Tue Jan 26 10:54:17 CET 2021] Unable to authenticate to 192.168.XX.XX:5XXX using https.
[Tue Jan 26 10:54:17 CET 2021] Check your username and password.
[Tue Jan 26 10:54:17 CET 2021] Error deploy for domain: mondomaine.fr
[Tue Jan 26 10:54:17 CET 2021] Deploy error.


Pourtant mon nom d'utilisateur et mon mot de passe sont bons...

Cela a à voir avec la double authentification? Pourtant, j'ai bien copié la valeur du DID comme indiqué sur le tuto...

Si quelqu'un peut m'aider...

 

EDIT: Malgré plusieurs tentatives, impossible de déployer le certificat via la console SSH...
J'ai donc quitté celle-ci...


Si une âme charitable veut bien m'aider...

Modifié par Stixen92
Posté(e)

@Stixen92

Bonjour,

Il y a deux sources possibles à ce blocage :

  1. Ton identifiant mais surtout ton mot de passe contient sûrement des caractères "exotiques" spéciaux qui ne sont pas acceptables. DSM comme tout système UNIX n'aime pas ce type de caractères. Il faut n'utiliser que ces caractères standards majuscules, minuscules et chiffres avec idéalement une longueur de minimum 12 caractères. De toutes façon 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, ce qui rend bien plus difficile et surtout beaucoup plus long le décryptage pour un malveillant. Maintenant ce que j'en dit ... A toi de voir ...
     
  2. Vérifier la valeur du DID et si celui-ci n'est pas "expiré" (voir TUTO). Attention lors du C/C du DID veiller à ne pas prendre dans la chaine des caractères "parasites" (blancs, fin de ligne, etc ...). Passer par un éditeur de texte est une bonne chose.
     

Il vaut mieux utiliser aussi une connexion HTTP plutôt que HTTPS. Certains ont eut des soucis avec HTTPS, sans que l'on explique pourquoi. De toutes façon lors du déploiement on est en principe en local, alors HTTPS ne se justifie pas à mon humble avis ...

Cordialement

oracle7😉

 

Posté(e) (modifié)

@oracle7

Salut,

J'ai récupérer, à la main, via l'interface graphique de WinSCP, les fichiers de mon certificats et je les ai installés manuellement dans le menu "certificats" de DSM.

Mais bon, je suis déçu de ne pas avoir réussi intégralement la manipulation.

Surtout que je souhaite bénéficier du renouvellement automatique...

Donc je continue:

1) Justement, dans le fichier "votre-domaine.tld.conf" les infos du DID n'étaient pas présentes malgré que j'ai utilisé à plusieurs reprises la commande "export SYNO_DID=xxxxxxxxxxxxxxxValeur_du_DIDxxxxxxxxxxxxxxxxx"

Bizarre, non?

D'ailleurs, aucune des manipulations ne semble modifier ce fichier...
 

 

Du coup, vu que j'ai quitté la console SSH et WinSCP, à partir de quelle étape dois-je reprendre?
 

Modifié par Stixen92
Posté(e)

@Stixen92

Bonjour,

  1. C'est normal si le déploiement n'a pas eut lieu, que les variables ne soient pas sauvées dans le fichier ndd.tld.conf
  2. Regardes dans /root si le dossier .acme.sh est présent, c'est que tu n'avais pas bien ou pas du tout exporter la variable ACME_HOME au début du processus.
  3. Pour reprendre le déploiement automatique, il te faut ré exporter toutes les variables (avec leurs bonnes valeurs) depuis le début du processus et reprendre ensuite au § 5 du TUTO.
    Nota : Ne pas regénérer les clés OVH, utilises les valeurs que tu as sauvegardées précédemment.
  4. Assures toi d'avoir un "bon" MdP et que le cookies DID n'est pas expiré (modifier sa date de péremption si besoin comme expliqué dans le TUTO).

Normalement quand on suit le TUTO à la lettre, il n'y a aucun soucis. D'autres l'ont fait et y sont arrivés,  alors ...

Cordialement

oracle7😉

Posté(e) (modifié)

Bonjour

Pour récupérer les clé chez OVH ca coince , et je ne sais pas pourquoi , j'ai mis mon identifiant ovh ou mon adresse mail  et je suis  certain du MDP,

  J'ai mis les champs comme dans le tuto ..avec mon domaine et Synology_acme_sh . J'ai cette réponse

502 Bad Gateway

The server returned an invalid or incomplete response.

ou la réponse est si je met mon adresse mail : iError: Invalid account/password

Que faire et ou je me suis trompé ?

Modifié par Pascalou59
Posté(e)

Bonjour @Einsteinium

J'ai essayé toutes les combinaisons

adressse-mail@fr  ou identifiant  XX123456-ovh ou sous la forme  XX123456

Rien ne va

 

Posté(e) (modifié)

@Einsteinium

he bien nom justement tous mes mots de passe sont sans caractère exotique seulement , maj , minuscule ,chiffre et avec @ ou % et sans espace

Par contre cette étape je l' ai bien reussi , mais je dois la refaire , je ne comprend pas ce que je dois faire , i me faut de nouvelle clé , quand je veux la recréer

21012710130625080617231237.jpg

Creating identifiers

Creation of your application keys

https://docs.ovh.com/gb/en/customer/first-steps-with-ovh-api/

Modifié par Pascalou59
Posté(e)

@Pascalou59

Bonjour,

A mon humble avis, supprimes aussi les caractères "@" et "%". Il est préférable d'ajouter des caractères "standards" si tu veux durcir ton mot de passe, c'est bien plus efficace cryptographiquement parlant. Maintenant c'est toi qui vois...

Cordialement

oracle7😉

Posté(e) (modifié)

Bonjour @oracle7

J'ai changé le mot de passe par lettre et chiffre only .....toujours pareil , je vais faire un ticket chez ovh

C'est bizarre j'ai pu faire 1 api mais celle la ne me convient pas

 

Modifié par Pascalou59
Posté(e)

@Pascalou59

Bonjour,

Pour supprimer des clés API :

 Cordialement

oracle7😉

Posté(e) (modifié)

merci @oracle7

Je vais commencer par la c'est déja ça  et recommencer a 0, je peux supprimer complètement via wincp tous les dossiers qui ont été crée dans mon Nas  sans risque  ,et supprimer aussi les fichiers  et les  règles dans le planificateur de tache  ?

 

edit : je suis sur la page DELETE /cdn/dedicated/{serviceName}/ssl Remove SSL of the CDN

pour l ID je ne vois pas a quoi cela correspond  ...mon ID pour se connecter ?

 

Modifié par Pascalou59

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.

Invité
Répondre à ce sujet…

×   Collé en tant que texte enrichi.   Coller en tant que texte brut à la place

  Seulement 75 émoticônes maximum sont autorisées.

×   Votre lien a été automatiquement intégré.   Afficher plutôt comme un lien

×   Votre contenu précédent a été rétabli.   Vider l’éditeur

×   Vous ne pouvez pas directement coller des images. Envoyez-les depuis votre ordinateur ou insérez-les depuis une URL.

×
×
  • Créer...

Information importante

Nous avons placé des cookies sur votre appareil pour aider à améliorer ce site. Vous pouvez choisir d’ajuster vos paramètres de cookie, sinon nous supposerons que vous êtes d’accord pour continuer.