Aller au contenu

oracle7

Membres
 Afficher le profil  Afficher son activité

  • Compteur de contenus

    5559

  • Inscription

  • Dernière visite

  • Jours gagnés

    80

 Type de contenu 

Tout ce qui a été posté par oracle7

  1. oracle7
    @TuringFan Bonjour, Oui pour le port 80 sauf si tu utilises un application qui en a besoin du style site Web. Pour le port 443 ne perds pas ton temps à l'ouvrir ou à le fermer, laisses le ouvert tout simplement. Quel que part quand tout marche bien, je crois que moins on intervient sur le NAS mieux il s'en portera ... OUI, mais ce serait dommage de se priver de cette possibilité ... On en revient encore à mon argument précédent ... Bah en fait si, après chaque renouvellement, tu récupères les fichiers générés du certificat dans /volume1/Certs/ndd.tld - ndd.tld.key, ndd.tld.cer et l'intermédiaire ca.cer (pas les fichiers ".pem" issus d'un export depuis DSM !) et sans oublier de supprimer l'éventuel "saut de ligne" présent en début du fichier "ca.cer" avec un éditeur de texte et tu les importes dans le RT. C'est la seule contrainte, si on pouvait l'automatiser ce serait "the cherry on the cake" !😜 Il suffit simplement d'importer le fichier Python au bon endroit et de modifier la tâche périodique dans DSM comme indiqué dans le TUTO au §6, ensuite d'attendre le renouvellement. Si vraiment tu le souhaites, dans une session SSH tu peux effectuer un test avec l'option "-t" (voir tuto) mais il te dira sûrement que la date de renouvellement n'est pas atteinte. Donc rien à recommencer du début, c'est cool non ? Cordialement oracle7😏
  2. oracle7
    @kerod En quoi il gêne ? on est pas à l'abri d'avoir besoin de réinstaller acme.sh du coup cette suppression n'a pas été envisagée. Donc inutile d'en parler dans le TUTO. Cordialement oracle7😏
  3. oracle7
    @kerod Je ne suis pas convaincu car l'idée est aussi de ne pas "effrayé" les utilisateurs "lambda" avec les manipulations sous SSH avec tous les autres risques pour leur installation que cela recouvre en cas de fausse manip de leur part. Il n'y a qu'à observer certains posts ici pour s'en rendre compte. Il faut donc penser aussi à eux ... Cordialement oracle7😏
  4. oracle7
    @kerod OUI et quel intérêt d'avoir ce fichier lors d'un test ? l'affichage à l'écran de la trace n'est pas suffisante ? Cordialement oracle7😏
  5. oracle7
    @kerod Non, la description des options du script faite via le -h est à mon sens suffisante, il n'y a pas besoin d'en dire plus notamment pour des "initiés" auxquels ce mode manuel est plus particulièrement destiné. Les utilisateurs "lambda" eux, n'en n'ont pas l'utilité à partir du moments où ils suivent méthodiquement le TUTO avec l'utilisation standard du script Python. Cordialement
  6. oracle7
    @kerod Je ne suis pas spécialiste de Python mais de ce que je vois moi dans le script : ligne41 : le chemin vers le dossier Acme_renew est défini ligne 351 : le répertoire correspondant est effectivement créé avec un "os.makedirs" Ton post a été édité APRES que j'y ai accédé pour le consulter et il n' y avait pas encore les fautes en question, d'où ma remarque. Cordialement oracle7😏
  7. oracle7
    @kerod Tu as dû lire le tuto en "diagonale" car au § 10 en mode "manuel" dans une session SSH sous"root" tu peux lancer le script Python avec le paramètre "-t". Cordialement oracle7😏
  8. oracle7
    @kerod Bonjour, Tu peux préciser ta pensée STP ? "... utilisé par les scripts" les quels ? Si c'est mieux pour toi, nous on a préféré séparer les genres ... C'est plus propre informatiquement parlant. Méfies toi quand même en modifiant par toi même ce fichier, si tu est sûr de toi ... car il est géré par acme.sh et au final celui-ci pourrait ne plus y retrouver ses petits ! Donc ne viens par t'étonner des potentiels dysfonctionnement. C'est étonnant car lors des tests, je supprimais systématiquement ce fichier acmelog et il était récréé à chaque exécution soit en version que j’appellerai "light" soit en version très complète en cas de problème. Je n'ai jamais eut ton problème. Mais peut-être que cela vient de ton renommage de répertoires ??? si tu modifies les choses qui te sont proposées, il faut être cohérent jusqu'au bout et vérifier que cela n'aura pas d'impact ... A chaque création d'un certificat les fichiers relatifs à ce certificat sont archivés en interne par DSM dans un répertoire avec un nom "aléatoire" (pour toi cela a été "Yan5LF"). Belle assertion mais tu ne crois pas que ce serait mieux de les citer précisément et nous dire sur quoi elles portent. On ne peux pas les deviner et les corriger si elles sont effectivement avérées. Cordialement oracle7😏
  9. oracle7
    @giovanio Bonjour, Regarde ici cela devrait répondre à ton besoin. Cordialement oracle7😏
  10. oracle7
    @Pinpon_112 Bah oui, désolé pour toi mais force est de constater ( le message est clair) que tu as atteint la limite de duplication de certificat pour un même domaine "ndd.tld" fixée par LE à 5 cartouches par semaine. Regardes le lien fourni dans ton message d'erreur. Maintenant tu n'as pas d'autre choix que d'attendre une semaine ( donc pas avant Samedi 1er Août 2020 vers 16h00 minimum) pour pouvoir relancer la génération de ton certificat Je sais, cette limitation est une vraie plaie et il faut être parcimonieux dans la création de certificats. Maintenant tu peux quand même le faire mais pour un autre domaine et pas l'actuel. Cordialement oracle7😏
  11. oracle7
    @TuringFan Bonjour, Je crains que tu ne mélanges les notions. Rien de grave, je t'explique : Il faut laisser les ports 80 et 443 ouverts en permanence le temps d'un renouvellement d'un certificat LE créé à partir de l'interface DSM de ton NAS pour n'importe quel domaine "ndd.tld". Ceci est aussi valable pour les certificats sur les domaines "xxxxx.synology.me" parce que ces méthodes (implémentées par Synology dans les NAS) utilisent le protocole "HTTP-01" qui nécessite l'ouverture de ces ports pour les opérations de validation du certificat. Maintenant, le port 443 doit aussi être ouvert en permanence si tu utilises un reverse proxy sur ton NAS. Mais c'est une autre raison de son ouverture. Avec la méthode 'acme.sh" couplée aux API d'OVH on utilise la méthode de validation dite par DNS basée sur le protocole « DNS-01 ». Ce protocole présente l’avantage de ne pas avoir besoin d’ouvrir de ports lors de la création du certificat LE mais surtout lors de son renouvellement et là c’est le « plus » indéniable du point de vue sécurité qu’apporte cette méthode. J'explique cela dans le TUTO. Voilà le pourquoi du comment ... Cordialement oracle7😏
  12. oracle7
    @Einsteinium Bonjour, Ton assertion est trop synthétique pour ma petite tête. Désolé mais si toi tu te comprends, moi je ne comprends pas ce que tu veux dire. Peux-tu STP être plus explicite et détailler ... Pareil que ci-dessus, sachant que l'export de l’Id du user et de son password n'ont que la durée de vie de la session SSH. Je vois pas où est alors le problème ? Par ailleurs, pourquoi selon toi il faudrait remettre en cause les indications fournies sur Github (que j'ai cité en référence au passage dans mon TUTO) ici « Synology DSM deployhook » ? Qu'est que tu appelles un "config avec droit restreint" ???? Encore une fois soit plus explicite dans tes remarques, je veux bien les prendre en compte mais encore faut-il que je les comprenne. Cordialement oracle7😏
  13. oracle7
    @Pinpon_112 Bonjour, Je t'en ai donné le chemin précédemment, donc tu passes par ta session SSH dans un terminal et tu tapes ceci : "rm -fi /usr/local/share/acme.sh/account.conf" puis un "cd /usr/local/share/acme.sh" et enfin un "ls -al" pour vérifier qu'il n'est plus là. Attention en supprimant ce fichier il te faut réinstaller "acme.sh" !!!! C'est impératif. As-tu vidé le cache du navigateur et relancer une connexion au NAS ? après, cela devrait le faire ? Copies le script Python provisoirement dans un de tes dossiers partagés sur le NAS (par ex dans "/volume1/music") depuis le finder du Mac. Ensuite dans une fenêtre Terminal avec une session SSH sous "root", tu le transferts dans "volume1/Scripts" avec une commande "cp" : "cp -p /volume1/music/acme_renew.py /volume1/Scripts" "cd /volume1/Scripts" "ls -al" pour vérifier qu'il est bien là. C'est pas plus compliqué que cela ... Cordialement oracle7😏
  14. oracle7
    Bonjour, Pour tous ceux d'entre vous qui sont intervenus dans mon post "[TUTO]Création d'un certificat "wilcard" Let'sEncrypt avec la méthode "acme.sh" " : @alan.dub @Jeff777 @.Shad. @CyberFr @GrOoT64 @PPJP @_Megalegomane_ @TuringFan @zerda @oudin @vincentbls @Einsteinium @kerod @Jz84 @jo.p @Pinpon_112 et pour tous les autres membres qui liront ce post, j'ai le plaisir de vous informer que la procédure de renouvellement du certificat "wilcard" Let'sEncrypt est maintenant totalement opérationnelle et efficiente. Grâce aux talents de développement de @bruno78 qui a fourni un remarquable travail et que je remercie encore vivement ici, cette procédure est entièrement automatisée. Oubliés les ports à ouvrir pour le renouvellement ainsi que les problèmes de certificat non réaffecté aux services, plus besoin de getter la date du renouvellement, TOUS les services et packages (avec leurs dépendances) sont maintenant bien relancés après un renouvellement. Je vous invite donc à consulter le TUTO pour prendre connaissance des modifications apportées à la procédure. Bonne lecture ... Cordialement oracle7😏
  15. oracle7
    @Pinpon_112 Bonjour, Je pense que c'est parce acme.sh a détecté que ton compte existait déjà au travers du fichier "/usr/local/share/acme.sh/account.conf". apriori il n'y-a pas de problème tu peux continuer. Pour ton information de viens de mettre en ligne une nouvelle version du TUTO. C'est tout frais !!! Je t'invites donc à la lire attentivement pour voir les changements apportés à la procédure. Cordialement. oracle7😏
  16. oracle7
    @Pinpon_112 Effectivement, c'est pas gagné ! ????? C'est comme si tu n'avais pas de certificat. Il y a vraiment un truc pas clair. Donc pour faire propre, je crois qu'il faut vraiment que tu reprennes toute la procédure de création du certificat comme convenu. Mais avant pour éviter toutes interférences, je te suggère de faire un peu de ménage en supprimant carrément dans DSM les certificats existants que tu aurais créés précédemment (sauf ceux en xxxx.synology.me si tu en as) + suivi d'un un arrêt propre et redémarrage du NAS. Reviens ensuite pour me dire ce qu'il en est. (à la fin n'oublies pas de configurer ton nouveau certificat pour les services). Cordialement oracle7😏
  17. oracle7
    @Pinpon_112 Bonjour, On va regarder si ton certificat est bien pris en compte : Sous Firefox après avoir vider le cache (effacer les données dans options vie privée) tu te connectes à ton NAS, tu cliques sur le cadenas à gauche de la barre d'URL et sur la ligne "connexion sécurisée" tu cliques sur le popup pour afficher les détails de la connexion et enfin tu cliques sur "plus d'informations". Est-ce bien ton certificat ? Quelle est alors la date d'expiration affichée ? Correspond-t-elle à celle affichée dans DSM pour ton certificat ? Cordidalement oracle7😏
  18. oracle7
    @Pinpon_112 Bonjour, Cela me semble plus sage. OUI, mais il te faudra repartir du §3.2 (export ce ces clés) Pour les C/C passes temporairement par un fichier TXT intermédiaire où tu colleras, pour t'assurer de ce que tu as copié. Tu as donné toi même la réponse : Cordialement oracle7😏
  19. oracle7
    @Pinpon_112 Bonjour, Au moins maintenant tu sais où sont tes fichiers de certificat ! Cela dit, ce n'est absolument pas normal ! Tu as pourtant bien spécifié le répertoire de génération à prendre en compte "/volume1/Certs" mais tout ce passe comme si le script acme.sh n'en faisait qu'à sa tête et les envoie quand même dans le répertoire standard par défaut. Le problème est que ce répertoire "/root/acme.sh" n'est pas stable dans le temps et qu'à la moindre màj de DSM, il sera réinitialisé et tes fichiers de certificat seront irrémédiablement perdus. Aussi je t'invite expressément à les recopier dès maintenant dans le répertoire où ils devraient être càd "volume1/Certs/ndd.tld". Maintenant en première approche, la seule explication qui vienne à l'esprit, serait une erreur de syntaxe dans la commande d'installation du script acme.sh. Même si en apparence cela semble correct, : tu as peut-être involontairement saisi un caractère invisible au niveau de la définition de la variable CERT_HOME ou au niveau "--cert-home "$CERT_HOME"". Cela arrive fréquemment lors de copier/coller, où l'on prend aussi ce type de caractères (un NL ou RC typiquement) ce qui rend la chaîne différente, du coup l'interprétation non correcte et l'utilisation de la valeur par défaut correspondante "/root/acme.sh/" dans ce cas précis. Du coup, il serait peut-être plus sage de reprendre tout en faisant attention à ces fameux copier/coller afin de repartir sur des bases saines sinon je crains que tu n'ai par la suite d'autres déboires lors du prochain renouvellement si tu restes dans cet état. Enfin c'est toi qui voit .... Cordialement oracle7😏
  20. oracle7
    @Pinpon_112 Bonjour, OK jusque là c'est parfait pour l'installation du Shell script acme.sh. Mais que disent les 4 dernières lignes de messages qui ont été affichées sur le terminal après l''exécution de la commande "./acme.sh --issue --keylength 4096 ........" ? J'espère que tu as conservé ce log écran. Cordialement oracle7😏
  21. oracle7
    @Pinpon_112 Bonjour, C'est pas possible qu'il n'y ait que ce dossier ! Si tu as bien suivi mon Tuto, c'est obligé, tu dois avoir dans le répertoire "/volume1/Certs", à l'issue de la création du certificat (§4) un dossier qui porte le nom de ton domaine "ndd.tld". C'est là que sont les fichiers ndd.tld.key, ndd.tld.cer et l'intermédiaire ca.cer. Pour preuve, regardes aussi les 4 dernières lignes du log qui a été affiché à l'écran lors des opérations de création du certificat. Ou alors c'est que tu as renseigné un autre chemin lorsque tu as défini la variable d'environnement CERT_HOME et dans ce cas, le dossier "ndd.tld" sera à cet endroit. Je ne peux mieux te dire. Cordialement oracle7😏
  22. oracle7
    @Pinpon_112 En fait cela me revient maintenant, l'import des fichiers ".pem" dans le routeur ne marche pas. Il ne faut pas exporter les fichiers depuis le NAS. Tu copies sur ton PC/Mac, les fichiers qui ont générés dans "Volume1\Certs\ndd.tld" lors de la création du certificat (i.e. si tu as utilisé ma méthode via acme.sh. Sur le RT tu importes directement cette copie ( ndd.tld.key, ndd.tld.cer et l'intermédiaire ca.cer). Ne pas oublier de supprimer l'éventuel "saut de ligne" présent en début du fichier "ca.cer" avec un éditeur de texte. Désolé pour le "flottement" ... Cordialement oracle7😏
  23. oracle7
    @pascalg57 Bonjour, Je te confirme les propos de @.Shad. , VLAN et switchs administrables : c'est impératif ! C'est typiquement l'installation que j'ai faite. Tu trouveras le détail du comment faire ici. Mais lis bien tous les échanges de ce post. J'avais même fait un schéma pour clarifier les choses. Cordialement oracle7😏
  24. oracle7
    @Pinpon_112 Tant mieux si tu n'as pas ce retour charriot en début de fichier. Désolé mais là je sèche. Tu dois avoir un autre problème de configuration quelque part, et là il faudrait être devant ton PC pour pouvoir analyser correctement. Cordialement oracle7😏
  25. oracle7
    @Pinpon_112 Je ne sais que te répondre précisément sur ce point. Peut-être par ailleurs, un problème de configuration de ton routeur, je ne sais ? Tu n'aurais pas par hazard, inversé les fichiers pour les certificats chain et intermédiaire ? Personnellement j'aurais fait l'inverse. Mais bon ... Essayes pour voir ce que cela donne. Il faut aussi supprimer le retour à la ligne en première ligne du fichier "chain.pem". Cordialement oracle7😏
×
×
  • 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.