Aller au contenu

quenbo

Membres
  • Compteur de contenus

    61
  • Inscription

  • Dernière visite

Tout ce qui a été posté par quenbo

  1. Décidément je ne suis pas très précis aujourd'hui! J'ai mis à jour ma signature 5 minutes avant votre message : je ne suis plus en DSM 5 mais en DSM 6.2 depuis longtemps.😬 Et j'ai fait une erreur dans le chemin aussi 😬. Voici le bon : Je corrige au dessus. Désolé
  2. Bonjour @oracle7, merci pour la réponse; En continuant mes recherches, je me suis rappelé une mésaventure plus ou moins identique, arrivée il y a plus d'un an : Le problème à l'époque était, malgré un cheminement différent, que le DSM n'avait pas mis à jour les certificats dans /usr/syno/etc/certificate/system/default J'ai été revoir le cas ici via WinSCP et, bingo (?), c'est le même problème : tous les certificats ont été mis à jour par le DSM sauf le "default" /usr/syno/etc/certificate/AppPortal tous mis à jour à la date du nouveau certificat /usr/syno/etc/certificate/system/default pas mis à jour J'ai simplement remplacé via WinSCP en mode root les vieux certificats dans "default" par les nouveaux et c'est OK après un reboot. J'ai quand même un bug sous-jacent sur mon Syno je pense... Merci pour le coup de main !
  3. Bonjour à tous, mon certificat 90-day "SSL for Free" expirant le 31/07, j'ai été invité à le renouveler. Depuis ma dernière génération de certificat en mai 2020, la fusion SSL for Free et Zero SSL semble avoir avancé et j'ai quelque peu tâtonné avant de trouver mes marques... Mais j'ai rapidement réussi à générer un nouveau certificat de 90 jours, pour le même nom de domaine qu'avant. Je suis donc allé dans le DSM pour faire le renouvellement, et m'y suis pris de la manière suivante: > DSM > Panneau de configuration > Sécurité > Certificats > Mon certificat périmant le 31/07 est bien affiché. > Ajouter > Remplacer un certificat existant > Importer le certificat (les 3 nouveaux fichiers) > sélectionner les 3 fichiers > OK Le certificat est bien mis à jour dans le DSM avec une expiration au 27/10/2020... Jusqu'ici tout va bien. Cependant, en utilisant la fonction "Check Installation" de ZeroSSL, je reçois une erreur indiquant que le certificat n'est PAS mis à jour. En affichant les propriétés du certificat de mon site dans Firefox, je constate en effet que malgré les dires du DSM, le certificat est toujours valide jusque fin juillet. Et un reboot du NAS n'y change rien... J'ai donc un certificat affiché valide jusque octobre dans DSM, et affiché valide jusque juillet dans Firefox! Je n'y comprends rien et j'aimerais savoir si ma méthode de mise à jour, pourtant tirée de mes notes, est correcte ? Pouvez vous m'aider? Merci, et bien cordialement Quenbo
  4. Je réponds avec retard mais moi aussi, un reboot ou deux avaient finalement résolu le problème
  5. BINGO ! J'étais persuadé que le Syno déconnait ! J'ai finalement remplacé en SSH les "vieux" certificats qui se trouvaient dans /usr/syno/etc/certificate/system/default et que je soupçonnais d'être mal utilisés, par ceux que je venais d'importer et qui se trouvaient dans /usr/syno/etc/certificate/_archive/ Un reboot du NAS et ça refonctionne enfin !!! Alleluia ! 😀
  6. Bonjour Zeus, merci pour la réponse. Je tiens quand même à préciser, suite à votre commentaire "... Tu as été jusqu'à ajouter des ports dans des entrées DNS..." que j'ai en effet utilisé les redirections proposées par OVH. Celles-ci me permettent facilement d'accéder au services de mon NAS en tapant, par ex. audio.ndd.fr plutôt que ndd.fr:46569 comme adresse, et c'est plus facile à retenir que les ports. Mais ces redirections se rajoutent automatiquement dans la zone DNS également, ce qui en effet surcharge un peu. Enfin bref... Puisque en effet ma zone DNS était un peu chargée, j'ai remis de l'ordre, sur vos conseils, et j'ai pu faire 2 choses : 1. réussir à créer un nouveau certificat Let's Encrypt à partir du Synology, ce qui ne fonctionnait pas avant, et qui m'a permis de récupérer le fameux "renew.json" manquant /usr/syno/etc/certificate/_archive/ymzCAP/renew.json Cependant, j'ai toujours une erreur dans Firefox, qui n'est plus "SSL_ERROR_BAD_CERT_DOMAIN" (Le certificat n’est valide que pour les noms suivants : mailconfig.ovh.net, www.mailconfig.ovh.net) mais est devenue "SEC_ERROR_UNKNOWN_ISSUER"(Le certificat n’est pas sûr car le certificat de l’autorité l’ayant délivré est inconnu.) 2. J'ai alors tenté d'utiliser à la place le certificat Wildcard (de SSL for Free), qui lui aussi fonctionne de la même façon avec "SEC_ERROR_UNKNOWN_ISSUER" dans certains cas Ce qui m'étonne, c'est que c'est le même message que pour les certificats autosignés ! ? Ce qui m'étonne encore plus, c'est que j'ai ce message pour une connexion vers le DSM ou PhotoStation mais que les autres connexions https vers AudioStation, NoteStation, ... fonctionnent sans problèmes ! => Donc les connexions à nas.ndd.fr:5001 (DSM) ou nas.ndd.fr:443 (photostation) sont KO, mais les autres connexions à nas.ndd.fr:8801 (AudioStation) ou nas.ndd.fr:9351 (NoteStation) fonctionnent ! Seul le port diffère ! ? ? ! J'en viens à me demander si le NAS ne se mélange pas dans ses certificats et présenterait soit le vieux certificat auto-signé (installé par défaut) pour la connexion DSM ou un certificat "vide" comme sur le printscreen. De plus, quand je clique sur afficher le certificat, je n'ai rien qui s'ouvre.
  7. @ZeusBon, avant de me lancer "profondément" dans ton tuto (et surtout dans le tuto serveur DNS de Ferir), j'ai d'abord tenté la création d'un certificat wildcard via sslforfree, à importer manuellement dans DSM... J'ai bien obtenu les certificats avec *.ndd.tld et ndd.tld, que j'ai importée correctement mais j'ai toujours une erreur dans Firefox... 😤 ndd.tld utilise un certificat de sécurité invalide. Le certificat n’est valide que pour les noms suivants : mailconfig.ovh.net, www.mailconfig.ovh.net Code d’erreur : SSL_ERROR_BAD_CERT_DOMAIN Apparemment, même si les adresses créée dans le certificat sont affichées correctement (*.ndd.tld et ndd.tld) dans sslforfree et dsm, il y a encore quelquechose qui foire, en lien avec le service mail ovh... Avez vous une idée? Merci !
  8. Ah ok... Ca me tente de plus en plus et je parcours ton topic mais je ne pige pas bien tes prérequis : - pour l' entrée CNAME avec "*.ndd.tld" chez son provider (je suis chez OVH aussi), tu crois que tu pourrais mettre un printscreen ? 😏 - pour la configuration du serveur DNS sur NAS (ou ailleurs), je comprends pas non plus ? Dans mon routeur j'utilise les DNS de cloudflare? Bref c'est un peu hors sujet mais bon. Merci +++
  9. Merci @Zeuspour la réponse. J'ai vu le topic pour un certificat wildcard via acme... mais je crois comprendre que le renouvellement automatique ne fonctionne pas encore à 100% chez toi ? J''attends maintenant la réponse de Synology chez lesquels j'ai déposé un ticket... On verra si, avant l'expiration du certificat, Synology ou d'autres forumeurs me répondent et savent m'aider ? Sinon je me retrousserai les manches une nouvelle fois...
  10. Merci pour ta réponse, malheureusement la démarche simple d'ajout de certificat via DSM ne fonctionne pas non plus. J'ai une erreur et dans le DSM et dans le log "Failed to create Let'sEncrypt certificate"...
  11. Salut à tous, vu le peu de réponse qu'inspirait mon premier post, je l'ai corrigé et précisé suite à différents essais de résolution... Je n'arrive pas ni a renouveller mon certificat Let's Encrypt, ni a en créer un nouveau, et le champ de couverture du certificat s'est restreint (le port du DSM n'est plus couvert)... Et il me reste 12 jours... Merci pour votre aide.
  12. Bonjour à tous, ayant reçu récemment, avec étonnement, un mail de Let's Encrypt m'invitant à renouveller mon certificat (installé depuis > 1 an) avant la fin du mois, j'ai d'abord tenté la commande suivante, qui n'a pas fonctionné...(mon port 80 est ouvert) /usr/syno/sbin/syno-letsencrypt renew-all -vv J'ai du forcer un hard reset de mon NAS il y a quelques temps et le certificat n'a pas bien vécu le passage semblerait-il... Bref, après quelques recherches, j'ai ouvert le log dans /var/log/messages et ai constaté le problème suivant : 2019-02-02T10:48:44+01:00 Diskstation syno-letsencrypt: syno-letsencrypt.cpp:312 can not find renew.json. [No such file or directory][/usr/syno/etc/certificate/_archive/ymzCAP/renew.json] En effet, le répertoire /usr/syno/etc/certificate/_archive/ymzCAP/ existe bien mais ne contient en effet que 4 fichiers *.pem : cert.pem, chain.pem, fullchain.pem, privkey.pem. Il n'y a pas de trace du fichier renew.json. Une petite lecture sur le net m'a suggéré de deleter l'ensemble de ce dossier _archive afin de resetter l'installation correcte des certificats (et de renew.json), puis de tenter renouveler mon certificat, mais ce delete a entrainé une erreur de volume sur un des disques du Syno ??? (qui a vérifié longuement sa cohérence de parité). Après redémarrage, un certificat autosigné "Synology.com" s'est réinstallé par défaut... J'ai réimporté mes clés de certficat let's encrypt, mais ce certificat maintenant ne couvre plus mon port 25001 (utilisé pour DSM) mais bien celui d'autres applications comme NoteStation... J'ai donc un message de connexion non sécurisée lors de la connexion au DSM, mais pas à NoteStation... Et ceci n'a pas corrigé non plus mon problème de renouvellement du certificat, car la commande " /usr/syno/sbin/syno-letsencrypt renew-all -vv " me renvoie toujours la même erreur de "renew.json not find" root@Diskstation:~# /usr/syno/sbin/syno-letsencrypt renew-all -vv DEBUG: Issuer name of certificate. [Let's Encrypt]->[/usr/syno/etc/certificate/_archive/l3npXZ/cert.pem] J'ai alors voulu demander un tout nouveau certificat Let's Encrypt àpd du DSM mais j'ai l'erreur suivante "failed to create Let's Encrypt certificate : (je suis chez OVH) 2019-02-02T12:17:51+01:00 Diskstation synoscgi_SYNO.Core.Certificate.LetsEncrypt_1_create[12501]: certificate.cpp:973 syno-letsencrypt failed. 102 [Invalid response from http://MONSITE.FR/.well-known/acme-challenge/B_-FMOcsiyIqDbCRt-qjXJwwXOZs8cFGRRFQfHcBR1s: "<html xml:lang=\"fr-FR\" lang=\"fr-FR\">\n<head>\n<title qtlid=\"28806\">Félicitations ! Votre domaine a bien été créé chez OVH !</"] 2019-02-02T12:17:51+01:00 Diskstation synoscgi_SYNO.Core.Certificate.LetsEncrypt_1_create[12501]: certificate.cpp:1392 Failed to create Let'sEncrypt certificate. [102][Invalid response from http://MONSITE.FR/.well-known/acme-challenge/B_-FMOcsiyIqDbCRt-qjXJwwXOZs8cFGRRFQfHcBR1s: "<html xml:lang=\"fr-FR\" lang=\"fr-FR\">\n<head>\n<title qtlid=\"28806\">Félicitations ! Votre domaine a bien été créé chez OVH !</"] Bref je ne sais plus trop quoi faire et viens vers vous pour voir si quelqu'un a une idée de solution et/ou peut vérifier l'existence de ce fameux "renew.json" chez lui et, si ce fichier est standard, me l'envoyer ? Pour des raisons de sécurité vous comprendrez bien je n'accepterai ce fichier que de forumeurs "reconnus"... D'ores et déjà merci pour votre aide, Quenbo
  13. Bonjour à tous, depuis la RAZ de mon Syno, un problème "bizarre" est survenu dans Download Station, qui m’empêche de lancer les torrents. Si je dépose via glisser-déposer un torrent dans la fenêtre de DLStation, la fenêtre de choix du répertoire cible s'ouvre comme d'habitude, mais lors de la validation, j'ai un message "Echec de l'opération" qui empêche le torrent de s'ajouter. J'ai essayé avec plusieurs torrents de plusieurs sites et ça le fait à chaque coup. J'ai vérifié si le user connecté dans DownloadStation avait les droits et c'est le cas. J'ai stoppé/redémarré le paquet. J'ai désinstallé/réinstallé le paquet, avec puis sans conservation des paramètres. J'ai vérifié via WinSCP que, avant de réinstaller, tout était bien viré de var/package et de volume1/@download. Tout ça sans succès... Par contre, j'ai découvert par chance l'option "dossier surveillé" (où Download Station va directement lancer tous les torrents déposés dans le répertoire)... Et là ça marche, pour les mêmes torrents ! Mais c'est moins pratique car on ne sait pas sélectionner le répertoire cible ni sélectionner certains fichiers du torrent ! Avez vous une idée sur la cause de ce comportement bizarre? Merci pour vos réponses !
  14. Bonjour à tous, j'aimerais savoir s'il est possible de forcer l'installation d'un paquet même si le Syno le refuse et le considère incompatible : "Ce paquet n'est pas pris en charge sur la plate-forme Diskstation ou est incompatible avec la version actuelle de DSM" En effet, depuis la mise à jour DSM 6.1, le paquet Plex n'était plus supporté sur mon DS213+, mais comme il était resté installé sur mon système depuis le DSM 6.0, je pouvais toujours le lancer par une commande : /var/packages/Plex\ Media\ Server/scripts/start-stop-status start Et le paquet fonctionnait alors parfaitement même s'il apparaissait désactivé dans le centre de paquets 🙂 Malheureusement, j'ai dû resetter mon DSM et, bien évidemment, le paquet a été supprimé de /var/packages/Plex. Donc ça ne marche plus. Je voudrais donc savoir si il est possible de soit : - éditer un des fichiers du fichier spk (après ouverture dans 7-zip) pour leurrer le DSM sur la version installée et le faire installer malgré tout - installer manuellement les fichiers présents dans le paquet spk en var/packages/ (mais je connais peu Linux et ai peur que ça ne marche pas sans un tuto un peu clair pour moi) (via putty ou Winscp?) Merci pour votre aide ! Quenbo
  15. Ah ok merci pour les infos (notamment le transmission-edit) Finalement mon post est intéressant, on apprend des trucs !
  16. @agnotos : c'est clair que se taper 800 torrents à la main, c'est un peu chaud... Perso j'en garde entre 20 et 50 actifs et je nettoie régulièrement, surtout que je garde pas tous les films dans /video/ une fois visionnés... Ca me permet un upload de 8 à 10 Go par jour et c'est bien assez. Et mes 4 To commencent à être étroits... (j'ai des films en 4K de 40 à 60 Go donc ça n'aide pas). Donc dans mon cas ça reste jouable à la main. Je n'ai pas les compétences pour attaquer la DB en postgres et je joue avec putty/winSCP mais avec prudence et modération. J'avais tenté des lignes de commande pour modifier tous mes torrents en /volume1/@download/XXX/XXX.torrent mais mes torrents se sont tous mis en "invalides"... Bizarre car les adresses des torrents étaient modifiées correctement mais il semblerait que le fait d'ouvrir et de refermer le fichier torrent avait modifié des caractères "cabalistiques" dans le corps du fichier torrent... (des caractères qui apparaissent dans un cadre noir quand j'ouvre le fichier dans Notepad++) Pour info voici les lignes de commande : J'ai essayé ceci, torrent par torrent : sed -i -e 's@adresse1@adresse2@g' /volume1/@download/541/541.torrent Puis ceci, avec scan des sous-répertoire : find . -name "*.txt" | xargs sed -i .old -e "s/adresse1/adresse2/g" Ca m'avait l'air bon mais bon comme je l'ai dit ça a fait foirer mes torrents...
  17. Merci pour ta réponse. Entretemps j'ai fini par voir que l'adresse du tracker était bonne mais qu'il était down. Comme l'adresse vient de changer de nouveau, j'ai finalement utilisé l'astuce de Salamafet dans un autre post qui était de rajouter la bonne adresse du tracker directement dans DLStation, puis de supprimer l'ancien tracker foireux ---- Posté(e) 3 novembre 2014 (modifié) --- Vue que l'url du tracker et la même pour tout les torrents, il suffit d'ajouter un tracker pour chaque torrent en collant l'url à chaque fois. Exemple: http://tracker.t411.me:8880/la_clef_du_compte/announce EDIT: Par contre il faut ce taper tout les torrents un par un :/
  18. Bonjour à tous, suite à un changement de tracker, je me suis "amusé" à remplacer tous les fichiers xxx.torrent originaux présents dans /volume1/@download/XXX/xxx.torrent par les nouveaux torrent avec la bonne adresse, que j'ai retéléchargé un à un du site web et rangé un à un dans les bons dossiers /volume1/@download/XXX/ par la commande mv (après avoir coupé DL Station) En vérifiant donc les fichiers .torrents directement dans /volume1/@download/XXX/, la bonne adresse du tracker était marquée et tout semblait rouler, DL Station redémarrait nickel. Je trouvais juste mon upload un peu bas ces derniers temps. Par hasard, en cliquant sur "télécharger le torrent d'origine" dans DL Station, j'ai découvert à ma grande surprise que ce torrent téléchargé contenait tjs l'ancienne adresse, alors que le fichier torrent dans le répertoire correspondant /volume1/@download/XXX/XXX.torrent contient lui la nouvelle adresse !!! Encore plus fort, en supprimant le "nouveau" fichier .torrent de /volume1/@download/XXX/XXX.torrent et en relancant DL Station, je m'attendais à ce que le torrent se mette en erreur... Et bien non, il redémarre correctement dans DLStation et le "vieux" fichier .torrent est recréé dans /volume1/@download/XXX/XXX.torrent J'en déduis donc que le Synology garde une copie cachée du torrent original, qu'il utilise constamment, et finalement se contrefiche du torrent localisé dans /volume1/@download/XXX/XXX.torrent. Quelqu'un sait-il où trouver ces torrents cachés et/ou a-t-il une autre solution ? Merci ! PS : je n'utilise pas Transmission et ne comprends d'ailleurs pas trop la différence entre les 2, ou la complémentarité de Transmission par rapport à DL Station
  19. En fait j'avais depuis un temps certain un certificat auto-signé mais cela donnait des avertissements à la famille qui accède à Photostation, mais étant donné leur niveau informatique je ne voulais pas leur donner de mauvaise habitude sur les exceptions de sécurité. Bref je suis passé depuis lors en DSM 6 (mais je n'ai pas eu le temps de chipoter dedans) et je vais un peu checker me renseigner sur letsencrypt. En 2 mots, qu'a fait StartSSL en jouant aux cons et quelles sont les conséquences sur la sécurité ? Est-ce définitif à votre avis? Et c'est quoi DANE ??? Merci !!!
  20. En effet j'ai lu quelque part que OVH se conformait à la loi française et donc pouvait donner accès au compte en cas de "procédure judiciaire". Ce ne sera pas mon cas, en tout cas j'espère. Maintenant il n'y a pas (encore) eu d'Edward Snowden français pour nous apprendre des choses...
  21. En effet le cout du MX plan est dérisoire. Par contre que pensez de la "confidentialité"/"sécurité" par rapport à un serveur mail perso? Je déteste l'idée de sentir ma vie privée violée et d'être une cible marketing screenée et cataloguée en permanence par les algos des GAFA et leurs amis publicitaires (et gouvernementaux)... OVH n'est déjà pas aux USA je pense, mais quid?
  22. Merci pour l'info . En effet je viens de réinstaller la version 50 et ça fonctionne, mais le temps de décocher la MAJ auto de Firefox (qq secondes) il était déjà repassé en v51 et j'ai du recommencer, mais bref ça refonctionne. Pensez vous que cette décision de sécurité de Mozilla est justifiée et y-a-il moyen de de forcer Firefox a accepter les certificats StartSSL (au moins pour mon site) en, par ex, forçant l'importation des certificats ??? Sinon quel est le meilleur moyen de gérer mon problème actuel de double certificats StartSSL et de probable futur besoin de nouveau certificat pour de nouveau sous-domaines ? et via le 192.168 ? Je crois que DSM 6 permet de gérer plusieurs certificats mais pas DSM 5.2 (dois je migrer vers le DSM 6?) Merci à tous ceux qui éclaireront un peu le monde obscur des certificats :-)
  23. Salut à tous, en me basant sur différents tutos, j'ai certifié mon domaine xxxx.be via StartSSL la semaine passée, et tout allait bien jusqu'à hier. Plus d'alertes "connexion non sécurisée", un beau cadenas vert certifié StartCom et tout le toutim. (juste une alerte en locale 192.168 que j'ai mis en exception permanente) Cependant, depuis hier soir, j'ai sur Firefox un refus de connexion : "Une erreur est survenue pendant une connexion à xxxx.be:port. Le certificat du pair a été révoqué. Code d’erreur : SEC_ERROR_REVOKED_CERTIFICATE" Par contre via Edge je me connecte sans soucis et sans erreur J'ai donc parcouru la toile et tenté divers solutions : vérifier l'heure de mon PC, vider le cache, décocher "interroger le répondeur OCSP" (Options > Avancé > Certificat), désinstaller avec Revo Uninstaller Firefox, etc... Sans succès... Puis, je suis tombé sur un post qui abordait les certificats StartSSL et le fait qu'il ne fallait pas se tromper car sinon il fallait payer pour révoquer les certificats erronés. Ca m'a fait penser que j'avais du recommencer la semaine passée mon certificat StartSSL qui initialement ne comprenait pas mon sous domaine nas.xxxx.be et générait une erreur. Bref j'avais recommencé en incluant le sous-domaine nas.xxxxx.be, ça avait fonctionné et j'avais vaguement tenté de révoquer le premier certificat, mais comme ils attendaient un paiement et qu'en plus ça fonctionnait avec le 2ème certif je n'ai pas été plus loin et il est resté vaguement "revoked en attente de paiement" (jusqu'à ce que je le remette en "issued" hier soir), sans effet... Pour couronner le tout, en rédigeant ce post, et en constatant que les certificats ont des numéros d'ordre, je me demande si je n'ai pas été grandiose et que je n'ai pas révoqué le deuxième certificat (le bon) la semaine passée. Comme vous le verrez dans le printscreen, je l'ai réactivé mais finalement je me suis bien emmêlé les pinceaux et je voulais savoir si le type d'erreur que j'ai dans Firefox pouvait être lié à ça, et voir aussi si il y avait une possibilité de remettre de l'ordre dans tout ça... Parce que par exemple je n'ai pas certifié non plus le sous-domaine mail.xxxx.be (ce qui m'a embêté) et je parie qu'il me faudra de temps en temps ajouter un sous-domaine supplémentaire au fur et à mesure de mes avancées... Qu'en pensez vous et avez vous une solution? Merci ! PS : Y a-t-il un moyen d'éviter les erreurs de certificats en local 192.168?
  24. Merci pour ta réponse. Le port 25 ne peut pas être débloqué (sauf via un abonnement "pro" 4X plus cher), et au niveau FAI en Belgique y a pas bcp de choix et le mien reste pour moi le meilleur. J'étudie le MX plan d'OVH qui finalement me simplifierait bien la vie... Par contre là j'ai un gros soucis bien plus urgent avec mon certificat StartSSL qui a été révoqué, je vais ouvrir un nouveau post.
  25. Oui, les ports 25, 587, et 993 sont redirigés... Mais un scan des ports me donne le port 25 "not responding"... Lié à mon FAI je suppose... ? EDIT : après vérif mon FAI "voo.be" bloque bien le port 25 en résidentiel... Comme je vois il me reste la solution d'utiliser un artifice "externe" genre mailhop ou proxy mail, ce qui signifie encore passer par un tiers.... Je me demande si je ne vais pas passer par le MX plan d'OVH. C'est déjà ça que goggole ne saura pas sur moi (enfin j'espère). Sinon, avez vous d'autres propositions sur une solution mail la plus privée possible ?
×
×
  • 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.