Stixen92

Bonjour, Plus personne ne semble être actif sur ce post...C'est bien dommage... De mon côté, je suis toujours coincé. - Si j'utilise la version 2.8.9 d'acme-sh, j'obtiens systématiquement le message d'erreur: Add txt record error. Error add txt for domain:_acme-challenge.ndd.tld _on_issue_err Alors que tout est bien configuré côté OVH, niveau API (application key, application secret, consumer key, etc). -Si j'utilise la dernière version d'acme-sh (3.0.6), le certificat SSL est bien renouvelé mais les dates inscrites (création et renouvellement) dans le fichier "ndd.tld.conf" sont au mauvais format (comme expliqué précédemment) et bloquent le prochain renouvellement. Obligé de rentrer manuellement les dates, au bon format, dans le fichier "ndd.tld.conf" et donc je perds le renouvellement automatique. Sans parler du fait que le déploiement du certificat ne fonctionne pas, malgré que la valeur "SYNO_DID", pour la double authentification soit correcte... Quelqu'un peut m'aider? @oracle7 @bruno78

Bonjour, Après quelques bidouillages, mon problème a évolué mais pas en bien... Je rencontre une grosse galère avec le script de renouvellement (acme_renew.py)... Je vais vous expliquer tout par étape. 1) Au début,, j'avais une banale erreur de problème d'ajout de l'enregistrement TXT dans mon DNS. Cela fait 2 ans que j'utilise le script de renouvellement "acme_renew.py". Ce genre d'erreur arrivait de temps en temps mais jamais aussi longtemps... Cette fois-ci cela a persisté... Message d'erreur: [Tue Sep 5 11:55:50 CEST 2023] Add txt record error. [Tue Sep 5 11:55:50 CEST 2023] Error add txt for domain:_acme-challenge.ndd.tld [Tue Sep 5 11:55:50 CEST 2023] _on_issue_err 2) Après moults recherches sur le net, j'ai tenté la commande (foireuse) ci-dessous que j'ai trouvé sur le forum officiel Let's Encrypt... La commande foireuse en question: ./acme.sh --issue --home . -d 'ndd.tld' --dns dns_cf --debug 2 3) Mauvaise idée que j'ai eue car ensuite, le script de renouvellement ne voulait plus fonctionner... Message d'erreur: -- Le nom de domaine (ndd.tld) est erroné ou mal configure avec acme.sh. -- Arret du script de renouvellement du certificat 4) J'ai modifié le fichier "ndd.tld.conf" au niveau de "Le_Alt" et "Le_Webroot" (valeurs manquantes ou erronées suite à l'exécution de la commande trouvée sur le forum Let's Encrypt). 5) Suite à cela, le script de renouvellement s'est enfin remis à fonctionner mais les dates (création et renouvellement) inscrites dans le fichier "ndd.tld.conf" sont dans un format invalide. Exemple: Il me donne ce format de date: Le_CertCreateTimeStr='2023-09-06T02:39:44Z' Le_NextRenewTimeStr='2023-11-04T02:39:44Z' Alors que normalement, je devrais avoir ce format de date: Le_CertCreateTimeStr='Wed Sep 6 02:39:44 UTC 2023' Le_NextRenewTimeStr='Sat Nov 4 02:39:44 UTC 2023' 5) À cause de ce problème de date dans le fichier "ndd.tld.conf", j'ai systématiquement ce message d'erreur quand j'exécute le script de renouvellement "acme_renew.py". Voici le message d'erreur en question: /volume1/Certs$ python3 /volume1/Scripts/acme_renew.py -f ndd.tld Traceback (most recent call last): File "/volume1/Scripts/acme_renew.py", line 626, in <module> element = datetime.strptime(createTS[2],"%a %b %d %H:%M:%S %Z %Y") File "/var/packages/py3k/target/usr/local/lib/python3.8/_strptime.py", line 568, in _strptime_datetime tt, fraction, gmtoff_fraction = _strptime(data_string, format) File "/var/packages/py3k/target/usr/local/lib/python3.8/_strptime.py", line 349, in _strptime raise ValueError("time data %r does not match format %r" % ValueError: time data '2023-09-06T02:39:44Z' does not match format '%a %b %d %H:%M:%S %Z %Y' En changeant la date au bon format ou en mettant un ancien fichier "ndd.tld.conf", le script de renouvellement "acme_renew.py" accepte enfin de s'exécuter. Mais après exécution, rebelote, le fichier "ndd.tld.conf" contient de nouveau une date de création et une date de renouvellement au mauvais format... J'ai même supprimé acme.sh et l'ai réinstallé. Mais le problème de date incorrecte persiste! De plus, autre problème, le déploiement du certificat refuse de se faire alors que pendant 2 ans, avec les mêmes login et mot de passe (avec authentification 2 facteurs), le déploiement se faisait sans problème... Bref, double galère.. Mes questions: 1) Comment faire pour que le fichier "ndd.tld.conf", modifié à chaque renouvellement, affiche de nouveau la date de création et de renouvellement au bon format? Tant que les dates ne seront pas au bon format dans le fichier "ndd.tld.conf", impossible de renouveler mon certificat... 2) Comment faire pour le déploiement du certificat se fasse de nouveau correctement au niveau de DSM? Merci d'avance pour votre aide!

Bonjour @oracle7 et à tous les autres, Gros problème pour moi ce matin. Impossible de renouveler mon certificat SSL via le script présenté dans ce tuto, que ce soit via le planificateur de tâches de DSM ou via l'invite de commandes de WinSCP... Alors qu'habituellement, le renouvellement se passe bien (cela a déjà bloqué 1 ou 2 fois dans le passé mais ponctuellement). Voici ce que me dit le log: [Tue Sep 5 11:55:50 CEST 2023] Add txt record error. [Tue Sep 5 11:55:50 CEST 2023] Error add txt for domain:_acme-challenge.ndd.fr [Tue Sep 5 11:55:50 CEST 2023] _on_issue_err [Tue Sep 5 11:55:50 CEST 2023] Please check log file for more details: /volume1/Certs/Acme_renew/acmesh.log.1 La lecture du fichier "acmesh.log.1" ne m'apporte aucune information supplémentaire par rapport au fichier log principal... Serait-ce un souci de configuration côté OVH? Autre? Merci d'avance pour votre aide.

Salut @.Shad. Voici la tâche en question sous DSM: python3 /volume1/Scripts/acme_renew.py -f nomdedomaine.fr Elle a déjà fonctionné dans le passé... Bizarre que maintenant ça ne fonctionne pas à tous les coups... Salut @oracle7 Merci. Je viens de rajouter la variable d'environnement "DEFAULT_ACME_SERVER='https://acme-v02.api.letsencrypt.org/directory'" au fichier "account.conf" J'ai testé ensuite le renouvellement forcé depuis le planificateur de tâches DSM et cela a marché. Mais dans ton tuto, tu n'avais pas noté qu'il fallait ajouter cette variable d'environnement au fichier "account.conf". D'ailleurs, à l'époque, le renouvellement marchait pour moi, via le planificateur de tâches DSM, sans cette variable. Une explication sur ce qui a bien pu se passer?

Bonjour @.Shad. Qu'entends-tu par "token"? Aujourd'hui, mon problème est toujours d'actualité... Si je tente de renouveler mon certificat via le planificateur de tâches DSM (que ce soit en mode programmé ou mode forcé), j'ai systématiquement le droit à un message d'erreur: Add txt record error. Error add txt for domain:_acme-challenge.XXXXX.NDD Par contre, si je fais le renouvellement, manuellement, depuis l'invite de commande de WINSCP, ça passe... Une explication? Comment corriger le problème qui empêche le renouvellement depuis la planificateur de tâches de DSM (mode automatique et manuel/forcé)? Merci.

Salut @oracle7 Le script fonctionnait plutôt bien de mon côté pendant 1 an. Mais depuis aujourd'hui, j'obtiens systématiquement ce message d'erreur et je me retrouve dans l'impossibilité d'obtenir un nouveau certificat... Message d'erreur: [Tue Jul 5 09:56:37 CEST 2022] Add txt record error. [Tue Jul 5 09:56:37 CEST 2022] Error add txt for domain:_acme-challenge.XXXXX.NDD Apparemment, ça coince au niveau l'ajout et vérification du TXT record sur OVH... Une solution ou piste pour corriger mon problème? Merci. EDIT: Quand je fais le renouvellement manuellement sur WinSCP (exécution du script Python en mode "forced"), j'arrive à obtenir un nouveau certificat... Où est-ce que cela coince du coup?

Bonjour, Je me connecte à mon NAS via le VPN (OpenVPN) après avoir suivi le tuto de @Fenrir Jusque là, tout va bien. 1) Par contre, j'obtiens toujours le message "This configuration may cache passwords in memory -- use the auth-nocache option to prevent this" malgré que j’ai inséré la ligne "auth-nocache" dans le fichier de configuration (côté client). Une solution pour régler ce problème? J'utilise "OpenVPN for Android" comme application client. 2) Concernant la compression LZO, j'ai lu qu'il valait mieux la désactiver vu qu'elle contenait une faille de sécurité... Hormis désactiver la compression dans le paquet VPN Server, dois-je insérer les lignes suivantes dans le fichier de configuration côté client? Pour les versions 2.3.X : comp-lzo no push "comp-lzo no" Pour les versions 2.4.X compress stub-v2 push "compress stub-v2 3) Quelle différence entre reneg-sec 3600 et reneg-sec 0? Car j'obtiens ce message dans mon appli OPenVPN: "These options found in the config file do not map to config settings: reneg-sec 0 " Merci.

Bonjour, Personne pour m'aider et/ou répondre à mes questions?

Bonjour @maxou56 Lorsque je lance une analyse personnalisée (sur un seul dossier de mon NAS), je reste bloqué sur "Initialisation du processus d'analyse" À ce moment là, le CPU est utilisé à 50-77% et la RAM à 75-87% J’ai le souvenir d'avoir fait, il y a quelques années, avec ce même NAS, une analysez qui s'était bien passée. Mais là, je reste bloqué sur "Initialisation du processus d'analyse" Si le paquet "Antivirus Essential" n'était pas compatible avec le DS216J, pour cause de RAM insuffisante, normalement je n'aurais pas pu l’installer, non? Déjà que j'avais rencontré un problème pour mettre à jour la base de signature des virus (comme plusieurs autres utilisateurs): Maintenant si l'antivirus fourni pas Synology ne fonctionne plus du tout... Je ne comprends pas... Si jamais un utilisateur d'un NAS Synology avec 512 Mo de RAM passe par là, pourrait-il me dire s'il rencontre le même problème ou pas?

Bonjour, L'analyse antivirus refuse de fonctionner chez moi, que ce soit l'analyse personnalisée ou l'analyse complète... L'antivirus reste bloqué sur le message "Initialisation du processus d'analyse"... Le problème persiste malgré une désinstallation puis réinstallation du paquet... Je possède un DS216J. Quelqu'un sait d'où pourrait venir le problème?

Salut, Pareil pour moi, mise à jour automatique impossible, même en appuyant sur le bouton "Mettre à jouir maintenant". Obligé d'installer les fichiers manuellement en passant par la console SSH sur WinSCP (l'interface graphique a aidé).

Bonjour, 1) Petite mise-à-jour: Le problème de liens continue de se produire mais uniquement avec Firefox maintenant (sur PC). Avec les autres navigateurs (Chrome, Opéra, etc), cela fonctionne enfin mais après quelques longues secondes de chargement... Sur Firefox, malgré que j'ai nettoyé le cache, historique, etc, le lien partagé se transforme toujours en 192.168.XX.XX (IP locale du NAS), bizarre, non? D'où ce problème peut venir? 2) Est-il risqué, pour la sécurité de mon NAS, d'utiliser le service QuickConnect uniquement avec le service de partage de fichiers (avec le service de relais de QuickConnect activé)? Si le serveur relais de Synology est piraté ou comporte une faille, y a t-il un risque pour mon NAS?

Bonjour, Je me permets de remonter ce topic car, à ce jour, mon problème n'est toujours pas résolu... En effet, le partage de liens avec QuickConnect ne marche qu'à moitié chez moi: 1) Si j'ouvre un lien de type "http://gofile.me/XYZ/123" depuis mon PC, connecté à ma Livebox, le lien se transforme en "http://192.168.0.20/XYZ/123" ==> Ce n'est pas bon... * (192.168.0.20 est l'adresse IP locale de mon NAS) 2) Si j'ouvre un lien de type "http://gofile.me/XYZ/123" depuis mon PC, connecté à ma Livebox, en passant par un VPN (non Synology), le lien se transforme en "http://192.168.0.20/XYZ/123" ==> Ce n'est pas bon.. 3) Si j'ouvre un lien de type "http://gofile.me/XYZ/123" depuis mon smartphone, connecté à ma Livebox, le lien se transforme en "http://192.168.0.20/XYZ/123" ==> Ce n'est pas bon.. 4) Si j'ouvre un lien de type "http://gofile.me/XYZ/123" depuis mon smartphone, connecté à ma Livebox, en passant par un VPN (non Synology), le lien se transforme en "http://192.168.0.20/XYZ/123" ==> Ce n'est pas bon.. 5) Si j'ouvre un lien de type "http://gofile.me/XYZ/123" depuis mon smartphone, via ma connexion 4G, le lien se transforme en "https://go-file-xxxx.fr3.quickconnect.to/sharing/XXXXX" ==> C'est bon! Alors je sais qu'il y a un souci de loopback sur les Livebox Play (Livebox 3) mais cela n’explique pas pourquoi, même avec un VPN, le lien GoFile se transforme en lien avec l'adresse IP locale de mon NAS... C'est illogique! Je n'utilise pas de proxy et mon NAS est accessible depuis l'extérieur grâce à un nom de domaine chez OVH (uniquement via le VPN intégré à DSM). Mon nom de domaine est renseigné dans la rubrique "Accès Externe / Avancé" de DSM Le service relais de QuickConnect est activé dans la rubrique "QuickConnect / Avancés". Si quelqu'un pouvait m'aiguiller afin que je puisse corriger ce problème... Merci d'avance.

Salut @bruno78 - Donc je crée un nouveau jeu de clés sur l'API OVH pour le second nom de domaine? - Je ne touche pas à l'ancien jeu de clés (limité uniquement au premier nom de domaine)? - Le fait de recommencer le tutoriel, depuis le début, pour le second nom de domaine n'effacera pas les fichiers de configuration liés au premier nom de domaine? Merci pour ton travail sur le script. 😉 J'attends ton retour.

@oracle7 Bonjour, J'ai réussi, en suivant ce tutoriel, à créer un certificat et à le renouveler pour mon nom de domaine (*.ndd1.com) Pour cela, j'ai limité les clés API OVH à mon nom de domaine (*.ndd1.com) Maintenant, je souhaite pouvoir créer et renouveler un certificat pour un autre nom de domaine (*.ndd2.com) Du coup, j'ai quelques questions: 1) Dois-je refaire tout le tutoriel pour ce nouveau nom de domaine (*.ndd2.com)? Comment faire sans supprimer la configuration pour le premier nom de domaine (*.ndd1.com)? En effet, je souhaite pouvoir créer et renouveler des certificats pour les 2 noms de domaine (*.ndd1.com) et (*.ndd2.com) 2) Au niveau des clés API OVH, comment dois-je m'y prendre en sachant que la première fois, j'ai limité les clés API OVH à mon premier nom de domaine (*.ndd1.com)? Merci d'avance.

@MilesTEG1 C'est bien dommage. Par contre, j'ai un bug étrange... Enfin, si c'est bien un bug. Malgré que j'interdise à cet utilisateur de modifier les permissions pour un dossier donné, il arrive à le faire quand même. Testé à l'instant... Ce n'est pas normal... EDIT: Ce bug s'applique aux sous-dossiers du dossier partagé...

Salut, C'est fait mais le problème subsiste toujours: L'utilisateur voit toujours le dossier "home" sur File Station (mais il n'y a pas accès) et il peut aussi voir tous les utilisateurs du NAS dans la fenêtre "Propriétés/Permissions"

Salut @oracle7 Oui, il faut que je teste ça mais je ne sais pas si cela va servir à quelque chose de le faire maintenant vu que j'ai atteint le quota de 5 certificats le Jeudi 28 Janvier. Logiquement, je pourrai de nouveau renouveler mon certificat à partir du Jeudi 4 Février, c'est bien cela? Si je fais une nouvelle tentative de renouvellement aujourd'hui, la date de réinitialisation de mon quota sera toujours le Jeudi 4 Février ou alors le Samedi 6 Février?

Salut @.Shad. Merci. Par contre, il y a quelque chose qui me gêne. Via File Station, l'utilisateur, même limité, peut voir le nom de tous les utilisateurs de mon NAS dans la fenêtre "Propriétés/Permissions" Y a t-il un moyen de cacher cela?

@oracle7 Oui, mais j'ai repris les parties où apparaissent des messages d'erreur. Je n'utilise pas le mode standalone. J'ai suivi ton tuto à la lettre... Ce que je ne comprends pas c'est pourquoi il y a échec du renouvellement du certificat en exécutant le script Python sur le planificateur de tâches de DSM alors que tout fonctionne correctement si j’exécute ce même script Python depuis la console SSH sur WinSCP... Cela n'a aucun sens! Du coup, vu que cela ne fonctionne pas depuis sur le planificateur de tâches, je ne peux pas profiter du renouvellement automatique... Oui, je l'ai malheureusement atteinte... La limite de 5 comprend les tentatives infructueuses?

@oracle7 [Thu Jan 28 08:34:00 CET 2021] _CURL='curl --silent --dump-header /usr/local/share/acme.sh//http.header -L -g ' [Thu Jan 28 08:36:07 CET 2021] Please refer to https://curl.haxx.se/libcurl/c/libcurl-errors.html for error code: 35 [Thu Jan 28 08:36:07 CET 2021] _ret='35' [Thu Jan 28 08:36:08 CET 2021] code [Thu Jan 28 08:36:08 CET 2021] d='mondomaine.fr' [Thu Jan 28 08:36:08 CET 2021] Getting webroot for domain='mondomaine.fr' [Thu Jan 28 08:36:08 CET 2021] _w='dns_ovh' [Thu Jan 28 08:36:08 CET 2021] _currentRoot='dns_ovh' [Thu Jan 28 08:36:08 CET 2021] get to authz error. [Thu Jan 28 08:36:08 CET 2021] pid [Thu Jan 28 08:36:08 CET 2021] No need to restore nginx, skip. [Thu Jan 28 08:36:08 CET 2021] _clearupdns [Thu Jan 28 08:36:08 CET 2021] dns_entries [Thu Jan 28 08:36:08 CET 2021] skip dns. [Thu Jan 28 08:36:08 CET 2021] _on_issue_err [Thu Jan 28 08:36:08 CET 2021] Please check log file for more details: /volume1/Certs/Acme_renew/acmelog [Thu Jan 28 08:36:08 CET 2021] socat doesn't exist. socat: [Thu Jan 28 08:36:08 CET 2021] Return code: 1 [Thu Jan 28 08:36:08 CET 2021] Error renew mondomaine.fr. [Thu Jan 28 08:36:08 CET 2021] _error_level='1' [Thu Jan 28 08:36:08 CET 2021] _set_level='2' [Thu Jan 28 08:36:08 CET 2021] The NOTIFY_HOOK is empty, just return. [Thu Jan 28 08:36:08 CET 2021] ===End cron=== J'ai suivi tes conseils d'il y a 2 jours et aucun caractère spécial ou exotique dans mon nom d'utilisateur et mon mot de passe. La preuve, cela marche correctement si je passe par la console SSH sous WinSCP. Il n'y a que dans le planificateur de tâches de DSM que cela coince...

@oracle7 @bruno78 - Oui, "Python3" et "Python Module", sont bien installés sur mon NAS. - Oui, mon NAS est bel et bien compatible pour accueillir Python3. Donc je ne comprends pas pourquoi le renouvellement refuse de se faire via le Planificateur de tâches, en mode manuel (commande "python3 /volume1/Scripts/acme_renew.py -f -l nomdedomaine.fr")... C'est l'user "root" qui est paramétré dans la tâche, comme indiqué dans le tuto.

Bonjour @bruno78 @oracle7 Je rajouterai à mon message d'hier soir le problème suivant, très étrange: 1) Si j'utilise la commande "python acme_renew.py -f -l nomdedomaine.fr" depuis la console WinSCP, le renouvellement et le déploiement du certificat se fait sans problème. 2) Si j'utilise la commande "python3 /volume1/Scripts/acme_renew.py -f -l nomdedomaine.fr", manuellement depuis le "Planificateur de tâches de DSM", le renouvellement du certificat refuse de se faire... J'ai obtenu ces messages d'erreur: [Thu Jan 28 08:36:08 CET 2021] _currentRoot='dns_ovh' [Thu Jan 28 08:36:08 CET 2021] get to authz error. [Thu Jan 28 08:36:08 CET 2021] _on_issue_err [Thu Jan 28 08:36:08 CET 2021] Return code: 1 [Thu Jan 28 08:36:08 CET 2021] Error renew nomdedomaine.fr [Thu Jan 28 08:36:08 CET 2021] _error_level='1' [Thu Jan 28 08:36:08 CET 2021] _set_level='2' [Thu Jan 28 08:36:08 CET 2021] The NOTIFY_HOOK is empty, just return. [Thu Jan 28 08:36:08 CET 2021] ===End cron=== Surprenant alors que les paramètres dans les fichiers nomdedomaine.cong et account.conf sont identiques... Je n'ai rien touché... J'ai fait, en premier, l’exécution du renouvellement en manuel via le Planificateur de tâches de DSM puis je l'ai fait en manuel via la console SSH de WinSCP... Je n'ai pas atteint les 5 renouvellements par semaine autorisés. Du coup, le renouvellement automatique ne marchera pas. D'où vient le problème? Sur la console SSH, j'ai parfois un message lors du renouvellement du certificat ou lors du déploiement de celui-ci: "L'hôte n'a pas communiqué depuis plus de 15 secondes, en attente..." J'attends et ça passe toujours. Cela pourrait venir de là? D'ailleurs? Merci.

J'ai bien lu ce que tu m'as écrit mais je pensais que tu avais oublié le partie "SAVED". Je l'ai écrit sous la forme "SAVED_OVH_CK" car dans le fichier account.conf les autres variables apparaissent sous la forme "SAVED_OVH_XX" En effet, j'ai "SAVED_OVH_AK" et "SAVED_OVH_AS" dans mon fichier account.conf Donc je suis perdu...Pourquoi pour "OVH_CK" cela serait différent? Oulah, je suis perdu là. Pourquoi les variables "OVH_AK" et "OVH_AS" apparaissent bien dans mon fichier account.conf sous les formes respectives: "SAVED_OVH_AK" et "SAVED_OVH_AS" mais pas la variable "OVH_CK" qui n'apparaît pas du tout? Pourtant j'ai suivi ton tuto à la lettre et ai entré ces 3 variables ("OVH_AK", "OVH_AS" et "OVH_CK") à la suite suite lors de la session SSH...

@oracle7 Donc malgré ces messages d'erreur suite à l'exécution du script Python , tout s'est bien passé (création du certificat + déploiement)? Ah oui? Pourtant la valeur du DID n'a pas changé après que j'ai modifié la date d'expiration. J'ai rajouté, via l'éditeur de texte, la ligne SAVED_OVH_CK='XXXX' dans le fichier account.conf Mais c'est quand même étrange. J'ai réessayé, quelques minutes avant, de rajouter cette valeur via la console SSH en utilisant la commande export OVH_CK="XXXX" mais cela n'a rien donné au niveau du fichier... Bizarre... D'ailleurs, la valeur OVH_END_POINT=ovh-eu n'apparait pas non plus dans le fichier account.conf, je dois aussi la rajouter? Pourtant, tout a fonctionné sans problème pour la création du certificat, à 2 reprises, cet après-midi...