oracle7

@lowfab Bonjour, Oui, tu crées dans la zone DNS un enregistrement "wilcard" de type CNAME : "*.zoneip.fr" qui pointe vers "zoneip.fr" Attention, il te faudra alors modifier (voire recréer) ton certificat pour prendre en compte cela ! Cordialement oracle7😉

@Jeff777 OUI (j'avais oublié cela !), donc j'en conclue que le résultat du test "zonemaster.net" est normal quelque part ? Je donc clore le sujet. Pour le lien, effectivement c'est du "hard" ... 😛 En tous cas MERCI à toi de ton aide. Cordialement oracle7😉

@jpfangin Bonjour, Parce qu'il semblerai que la résolution DNS pose parfois des problèmes de fiabilité. Mais rassures-toi tu peux mettre ton domaine à la place de l'@IP dans le champ remote. Je fonctionne comme cela et je n'ai jamais de problèmes de connexion. Sous WIN as-tu bien installé le client OpenVPN et surtout recopié au bon endroit le fichier de configuration ".ovpn" ? (voir onglet Configuration/Avancés dans l'interface GUI) Vérifie aussi si ton fichier de configuration ".ovpn" sur WIN, comporte bien deux fois des lignes : "----------BEGIN CERTIFICATE--------------- xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx ----------END CERTIFICATE-----------". Normalement en exportant la configuration VPN depuis ton NAS, le certificat est inclus dans le fichier de configuration ".ovpn". C'est précisé dans le Tuto pour les version récentes du paquet OpenVPN. Cordialement oracle7😉

@Jeff777 Merci de t'intéresser à mon cas. Je n'ai et n'ai jamais vu aucun enregistrement DS dans ma zone DNS chez OVH et je n'avais rien remarqué de tel auparavant. J'ai plutôt l'impression, à la vue des messages d'erreurs/warning, que OVH lors de la création du domaine, ne transmets pas partout l'info concernant le domaine et en particulier à la racine DNS nic.fr. D'où ces messages. Mais ce n'est qu'une impression ... Tu as sûrement raison car je n'ai rien modifié de mon coté. Le problème reste tout de même de comment interpréter ces résultats ? et quoi en faire ? Cordialement oracle7😉

Bonjour, Je vois que ma question ne déchaîne pas les foules ... 🤔 Cordialement oracle7😉

Bonjour, Heureux ceux qui reçoivent un eMail d'avertissement, pour ma part je n'en ai jamais reçu 😟 A moins que j'ai raté un quelconque paramétrage ... Cordialement oracle7😉

Bonjour, De mon coté, le port 80 est fermé et le port 443 ouvert à tous. Constat factuel d'il y a quelques jours : les certificats LE Synology.me et autres LE créés à partir de DSM, se sont renouvelés d'eux même sans aucune autre intervention de ma part. Cordialement oracle7😉

@bruno78 Bonjour, Intuitivement, j'aurais essayé de relancer tout simplement le processus SMB ... Cordialement oracle7😉

@yogib33r Je ne sais pas comment tu cherches, il y a pourtant plusieurs possibilités, mais bon ... Regardes ici par exemple. Lis bien au moins une fois l'ensemble du Tuto avant toutes choses. Ne te lances surtout pas "bille en tête" sans en avoir bien compris ce qui ce passe quand tu génère un certificat. il te faut juste être attentif et bien noter tout ce que tu fais. enfin ce n'est qu'un conseil... Cordialement oracle7😉

@PPJP Bonjour, Tout simplement parce que le dossier où acme met les fichiers du certificat ne porte pas le même nom selon que c’est une clé RSA ou EDSA. OK, il me semblait que le dossier (avec son chemin) où sont générés les fichiers du certificat, était défini avant la première commande de création du certificat, au moyen de l'export de la variable d'environnement 'CERT_HOME' et qu'il était automatiquement nommé avec l'intitulé du domaine concerné par le certificat. Mais effectivement en regardant de plus près le code d'acme.sh, dans le cas d'une clé ECDSA, le suffixe "_ecc" est rajouté au nom définit initialement. Maintenant je comprends mieux ... OK, pas de soucis pour revoir à la baisse les ambitions : on s'en tiendra alors à OVH tout cours pour ne pas introduire une quelconque confusion au près des utilisateurs. Et pas de paramètre supplémentaire liée à la clé de chiffrement. L'utilisateur fera son choix dès le départ. S'il veux en changer ensuite, pas la peine de compliquer le processus du Tuto pour cela, je maintiens qu'il n'aura qu'à relancer le processus avec son nouveau paramétrage. Le seul paramètre sera donc celui que tu as introduit : nombre de jours pour le cycle de renouvellement. On reste dans la simplicité ... Je ne comprends pas non plus pourquoi il y aurait cette nécessité, ces clés d'API une fois générées, sont copiées dans des variables d'environnement qui sont utilisées ensuite par acme.sh pour la création du certificat. OK certes, mais elles ressemblent étonnamment aux clés API que l'on insère manuellement dans des enregistrements TXT lorsqu'on déroule le processus acme.sh dans sa version "simple"/"basique". Voilà le pourquoi de mon interprétation de cette sauvegarde dans le fichier 'account.conf' et de leur utilité présumée. D'autant plus qu'elles portent le même nom au préfixe 'SAVED_' près et que le code d'acme.sh semble les utiliser, mais je peux me tromper... Cordialement oracle7😉

@Andrea J'utilise quand nécessaire une connexion VPN avec un fournisseur tiers vers l'extérieur depuis mon PC sur le LAN. Et quand je suis à l'extérieur, j'utilise soit une connexion OpenVPN soit une connexion VPN SSL avec le serveur VPN installé sur mon routeur, pour accéder à tout mon LAN en toute sécurité. Tout cela est on ne peut plus simple à mettre en œuvre et parfaitement sécurisé. Je ne me prends pas la tête avec des configurations que je qualifierai d'exotiques et souvent bancales ... Cordialement oracle7😉

@bruno78 Arrêtes moi si je dis encore une bêtise, mais n'existerait-il pas deux types de packages ? Ceux qui sont actifs en permanence parce qu'ils écoutent par ex un ou des ports comme Webdav et auquel cas il faille les redémarrer, et ceux qui ne sont actifs que lorsqu'on s'en sert, par ex AudioStation et auquel cas ils n'auraient pas besoin d'être redémarrés systématiquement. J'essaie comme toi de comprendre le mécanisme, d'où ces suppositions ... Cordialement oracle7😉

@PPJP Bonjour, OK mais c'est très étonnant cela, es-tu certain qu'il n'y a pas autre chose qui fait planté le script ? En toute logique, j'ai du mal à comprendre en quoi un paramétrage de longueur de clé de chiffrement peut impacter ainsi le fonctionnement d'un script. J'ai bon, Oui/Non ? Pourquoi, envisager des conversions de clés (RSA vers EDSA, EDSA vers RSA) ? Cela ne me parait pas utile à moins que tu n'ai une bonne raison en magasin. Pour mémoire le choix de la clé de chiffrement est fixée initialement lors de la constitution de la commande de création du certificat. L'utilisateur devrait à mon sens, recréer un certificat s'il souhaite changer la longueur de la clé de chiffrement lorsque la date d'expiration du certificat est atteinte. Par ailleurs, je aperçois qu'à l'usage, tel que le script est actuellement, il faille allez modifier manuellement le script pour l'adapter au contexte propre de l'utilisateur. Dans mon idée initiale, l'objectif était de faire le plus simple possible pour que le processus soit réalisable par le plus grand nombre. Aussi, je pense qu'il serait bien que le script ne soit pas modifiable pour éviter ainsi tous problèmes avec des utilisateurs non avertis. En conséquence, il serait nécessaire donc pour cela, qu'il accepte des paramètres supplémentaires qui seraient eux, définis lors de la constitution de la commande à insérer dans le planificateur de tâches et uniquement à ce moment là, et qui permettraient de prendre en compte notamment : le domaine de l'utilisateur : "ndd.tld" Le type de clé de de chiffrement (i.e. la valeur du paramètre "-- keylenght") : 2048 (défaut), 4096, ec-256, ec-394) le nombre de jour pour le renouvellement : mais cela tu l'as déjà pris en compte. Bien évidemment, avec un contrôle de la présence ou non de ces paramètres qui rejette l'exécution du script si ces derniers sont incorrects et/ou absents, selon. Désolé de "rallonger la sauce", mais cela me paraît important d'ajouter ces éléments. Enfin, si tu le veux bien 😏 C'est normal car tu n'as pas déroulé le processus de création de la même façon. Avec le Tuto, ces clés sont "exportées" une première fois pour la création du certificat. ACME.sh les inscrit alors temporairement chez OVH pour l'authentification du domaine puis les supprime de chez OVH (voir le log de création que j'ai fourni dans le Tuto). Donc ensuite, pour le renouvellement, ACME.sh a besoin de les retrouver quelque part puisque il n'y a plus d'enregistrement correspondant chez OVH (dans la zone DNS du domaine), d'où leur sauvegarde dans le fichier "account.conf". Cette façon de procéder, me paraît très sécurisante, pas de clés personnelles chez un tiers ! Comme demandé, je te joins donc le fichier "account.conf" : account.conf expurgé des informations personnelles. Une dernière question : peut-on purement et simplement remplacer dans le gestionnaire de tâches, l'actuelle commande de renouvellement (celle du Tuto) qui est active dans le gestionnaire de tâches, par celle que tu proposes avec l'usage du script ? N'y-a-t-il pas une manipulation autre à effectuer vis à vis du "cron" pour prendre en compte ce changement ? J'avoue ne pas trop maîtriser ce point. Encore MERCI à toi de bien vouloir nous aider pour finaliser de processus d'automatisation complet. @bruno78 @PPJP m'arrêtera si je dis une bêtise ..., mais n'est-ce pas tout simplement, parce que justement ces services ne sont pas des packages qu'ils n'ont pas besoin d'être redémarrés ? Cordialement oracle7😉

@Andrea Bonjour, Je connaissais cet article, mais pour ton info ce paramétrage est déjà en place chez moi mais cela ne marche pas. Comme toi, connexion externe vers le LAN impossible si une connexion VPN vers l'extérieur est active par ailleurs. J'ai donc choisi ... Car toutes les autres solutions proposées ici ou là, si bonnes soient-elles, sont à mon sens beaucoup trop compliquées à mettre en œuvre. Mais ce n'est que mon avis. Cordialement oracle7😉

@Andrea Bonjour, Je voudrais pas passer pour un rabat joie mais je crains qu'il ne te faille te faire une raison. Ce que tu souhaites faire "en même temps" c'est à dire, si j'ai bien compris : A) accéder de l'extérieur vers ton LAN et tous ses périphériques ET B) Activer une connexion VPN depuis ton NAS vers l'extérieur pour DL en BT, n'est pas possible. @Juan luis te l'a déjà expliqué précédemment et il a tout a fait raison, à partir du moment où ta connexion VPN vers l'extérieur est établie, tu as implicitement rendu ton LAN et donc ton NAS, étanche à toute connexion extérieure vers ton LAN. Sauf à te connecter via l'@IP de ton VPN (en Chine, ou Russie par ex). Mais tu ouvres en grand les portes de ton LAN à ces serveurs tiers. Question sécurité on fait mieux ... Désolé mais il te faut donc choisir : ou tu DL en BT, ou tu accèdes à ton NAS pour tout autre usage mais pas les deux en même temps ! Une dernière solution positive, tu investis dans un routeur avec fonction double WAN (Synology fait cela très bien) et tu prends un second FAI différent de l'actuel Orange et là tu auras deux connexion indépendantes et dédiées chacune à chacun de tes souhaits. OK, cela a un coût non négligeable, mais à toi de voir si le jeu de tes désidératas en vaut la chandelle, c'est toi qui vois ... Cordialement oracle7😉

@PPJP J'ai examiné ton script et ma foi c'est un excellent travail que tu as fais là. Je t'en remercie vivement car mon niveau de connaissances en script Shell ne m'aurait pas permis de coder aussi bien que tu l'as fait. Pour aller un peu plus loin dans l'automatisation, je te propose une évolution, si tu le veux bien, afin d'ajouter ceci à ton script : Dans le cas d'OVH, il serait bien de pouvoir éviter à d'avoir à Copier/Coller les clés OVH_AK et OVH_AS dans le script. En effet, c'est ce C/C qui souvent pose problème car il arrive que certains utilisateurs recopient aussi de façon aveugle, des caractères parasites qui viennent modifier la chaîne et génère des messages d'erreurs. Ce serait donc bien de pouvoir récupérer ces clés automatiquement. Ton avis STP ? Pour ton info si besoin en est, ces clés sont sauvegardées dans le fichier "account.conf" situé dans le répertoire "/usr/local/share/acme.sh". Elles sont respectivement inscrites dans ce fichier, lors de la création du certificat par ACME, à l'aide de deux variables d'environnement "SAVED_OVH_AK" et "SAVED_OVH_AS" . Il suffirait (si je puis dire) de les relire pour alimenter l'export des clés que tu fais ensuite en début de script. Autre argument, ces clés peuvent changer si l'on recrée pour X raison un autre certificat LE en lançant tout le processus, notamment après un changement d'@MAIL (pour mémoire, cette dernière est utilisée dans le processus de validation interne des clés par OVH). Je pense que cela doit être aussi faisable pour d'autres fournisseurs MAIS là en se limitant aux principaux (maxi 3 à 5 par ex), pas tous bien évidemment - à discuter des quels seraient retenus dans la mesure où on dispose aussi des infos correspondantes pour le faire. Là, il faudrait recceuillir du retour d'autres utilisateurs sur ce point. Sinon, on s'en tient à OVH uniquement, puisque le TUTO est basé sur l'utilisation de leurs API. C'est juste qu'il serait dommage à mon sens de ne pas pouvoir étendre la portée du TUTO. Par ailleurs, je modifierai le TUTO pour recommander d'utiliser le répertoire "Volume1/Scripts" pour y stocker le présent Shell script. Cordialement oracle😉

@yogib33r Ok c'est déjà plus clair. Avec un minimum d'attention, ce n'est pas insurmontable 😏 Le TUTO dont tu parles précédemment permet de modifier/remplacer un certificat LE déjà existant sur un domaine en "xxxxxx.synology.me". Avec souvent "xxxxx" = nom du NAS mais qui peut être aussi tout autre chose. Si tu veux utiliser ton propre domaine fraichement créé chez OVH, il te faut soit : générer le certificat LE par ailleurs (voir TUTOs sur le forum) et ensuite l'importer (fichiers ".key", ".cer") dans ton NAS. le créer par ajout, puis sélectionner "Procurez-vous un certificat après de LE", là tu entres ton domaine "ndd.tld" pris chez OVH, ton @MAIL et soit "*.ndd.tld (si tu utilises un certificat wilcard) soit la liste de tous tes domaines de second rang (par ex : mail.ndd.fr;photos.ndd.tld;camera.ndd.tld; etc ...) séparé par des ";" et en veillant à ce que la longueur chaîne de caractères globale ne soit pas > 255 car. Cordialement oracle7😉

@yogib33r Bonjour, Tu pourrais préciser STP, car là je ne te comprends pas 🤔 Cordialement oracle7😉

@Jeff777 Bah je ne crois pas. Je m'explique : Ce que je comprends, c'est que LE utilise le défit http-01 qui est configuré de base sur ACME, pour faire ses recherches DNS et ses requêtes HTTP (comme toute requête http/https standard le fait sur le net pour trouver un hôte distant). Si LE utilisait le défit DNS-01, alors l'article le citerait explicitement, ce qui n'est manifestement pas le cas. Après, je crains (ne le prends pas mal) que tu ne mélanges les choses en les rapprochant de ta configuration spécifique. Voilà ce que je comprends : c'est ton NAS1 qui reçoit en premier la requête en IPv4 de LE (et à ce moment là LE ne sait pas et ne peux savoir que tu as un NAS2 en esclave relié en IPv6) donc LE traite avec le NAS1 en IPv4 et pour moi, ce serait pour cela que cela fonctionne chez toi pour le renouvellement. Je vois cela comme çà mais je peux me tromper, non ? Cordialement oracle7😉

@Popop33 Ton problème semble venir de ton DDNS, peut-être mal configuré. As-tu bien rentré ton @IP externe (celle de la box) pour ton DDNS (Panneau de configuration / Acces externe / DDNS) ? Est-ce bien toujours la même ? (à vérifier, vas voir dans l'interface d'admin de la LB, celle qui a cours) Le port 443 est-il bien ouvert dans ton pare-feu du NAS ? Le port 80 quant à lui doit être ouvert uniquement pendant la période de renouvellement du certificat, en dehors il doit être fermé sur le paré-feu du NAS (la règle désactivée suffit). Cordialement oracle7😉

@Popop33 Bonjour, Il est de bon ton pour les nouveaux membres de passer par la rubrique "Présentation" afin d'y faire la leur. Certains y sont sensibles ici et de cette façon, il sera plus facile d'adapter les réponses en fonction du niveau de connaissances et de la configuration utilisée. Rassures-toi il n'est pas trop tard pour bien faire ... Commence aussi, si ce n'est pas encore fait par lire et appliquer le TUTO de @Fenrir sur la sécurisation des accès au NAS ici. Cela devrait déjà répondre à une partie de ta demande précédente. Après, reviens poser tes questions ... Cordialement oracle7😉

@Jeff777 N'oublies pas que ACME utilise de base par défaut le défit HTTP-01. Passer par le défit DNS-01 est une action volontaire réalisée par l'ajout de la directive correspondante dans la commande acme.sh. Du coup, j'en déduit que le problème évoqué dans l'article est bien uniquement dans le cas http-01. C'est juste mon interprétation ... Non ? Cela dit je peux me tromper aussi 😪 Cordialement oracle7😉

@Jeff777 Bah refait une lecture du lien que tu as donné plus haut ... C'est ce que j'en ai compris et en ai déduit via ma réponse précédente. J'ai pas bon ? Tu me mets le doute là ... Cordialement oracle7😉

@Jeff777 Bonjour, Merci pour le rappel de ce lien. D'où tout l’intérêt de passer par un défit "DNS-01" pour éviter ce genre de désagrément avec le défi "HTTP-01" et un IPv6 mal ou pas configuré. Cordialement oracle7😉

@apossium Bonjour, Effectivement, bien vu, je me suis planté dans mon calcul : 12Go x 1024 = 12282 Mo > (12282 x 3)/32 = 1152 Mo > 1152 Mo x 1024 = 1 179 648 Ko > répartis sur 3 disques = 393 216 Ko En fait dans mon erreur, j'ai encore divisé par 3 ce résultat (une fois de trop !) pour obtenir la valeur de 131072 Ko que j'ai utilisée dans la commande badblock. En toute rigueur selon l'article US j'aurais dû utiliser 393216 dans la commande. Finalement était-ce bien ou pas je ne saurais dire, en tout cas le temps de contrôle a été quand même bien réduit ! N'est-ce pas cela qui importe ? L'aurait-il été plus encore avec 393216 ? Il faudrait tester pour le savoir ... Cordialement oracle7😉