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.