This site uses cookies! Learn More

Ce site utilise des cookies !

En continuant à utiliser ce site, vous vous engagez à nous permettre de stocker des cookies sur votre ordinateur.

 

Si nous utilisons des cookies et retenons des données anonymes, c’est pour nous aider à mieux gérer notre mesure d’audience, aider nos partenaires commerciaux à nous rémunérer et nos partenaires publicitaires à proposer des annonces qui vous correspondent.

 

Grâce à ces cookies, le forum est en mesure de savoir qui écrit un message et utile pour le système d'authentification.

 

En cliquant sur « J'accepte », vous acceptez l'utilisation par NAS-Forum de cookies publicitaires et de mesure d'audience fine.

Ivanovitch

Membres
  • Compteur de contenus

    19
  • Inscription

  • Dernière visite

  • Jours gagnés

    3

Ivanovitch a gagné pour la dernière fois le 24 juillet 2021

Ivanovitch a eu le contenu le plus aimé !

À propos de Ivanovitch

Mon Profil

  • Pays / Ville
    Paris
  • Mon NAS
    RS1221+

Visiteurs récents du profil

Le bloc de visiteurs récents est désactivé et il n’est pas visible pour les autres utilisateurs.

Ivanovitch's Achievements

Apprentice

Apprentice (3/14)

  • Dedicated Rare
  • Collaborator Rare
  • Reacting Well Rare
  • Conversation Starter Rare
  • First Post Rare

Recent Badges

8

Réputation sur la communauté

  1. - Modèle : Syno RS819 & Eaton 5P650IR (rackables 1U) - Facture : oui - Date d'acquisition : sep. 2020 - Pourquoi vous vous en séparez : rs1221+ à la place & onduleur 2U - Avec ou sans disque : sans - Prix souhaités : 700e le lot - Frais de livraison : 30e - Pays de livraison : France uniquement - Garantie : oui, une lettre de cession sera fournie le nas et l'onduleur n'ont servis que quelques mois et sont quasi neufs, il étaient en standby power off depuis l'achat du 1221+ en février 2021
  2. Non, cette string d'erreur est envoyée en cas d'échec d'authentification, quel qu'il soit (cf. le code :: L114).
  3. sinon, pour les histoires de pare-feu (à priori ce que axb rencontrait comme problème un peu au dessus) il faut au moins ouvrir le port 443 du pare-feu du synology (pas celui de la box !) pour les conteneurs dockers en bridge (c'est le cas dans ce tuto) ! Ils sont considérés comme externes d'un point de vue de dsm (7) et de son PF. en mode parano on ouvrirai uniquement pour l'ip du docker acme le 443 en destination tcp (mais elle peux changer si j'ai bien compris docker, donc pas génial) ou, moins parano toutes les IP du bridge0 docker ( 172.17.0.0/16 ). pour le deploy il faut aussi ouvrir le port http dsm (encore une fois, que du syno, pas nécessaire sur la box) Mais mieux encore, et a moins que vous ne fassiez pas confiance à votre propre lan, autorisez tout pour les plages d'ip locales de la rfc1918, c'est à dire en toutes premières règles du pf, autoriser tout pour les 10.0.0.0/8, 172.16.0.0/12 (qui intègre donc le 172.17.0.0/16) et 192.168.0.0/16. C'est ce qui est décrit dans tuto de Fenrir sur la sécurisation du nas partie config du PF edit: pour ceux qui utilisent le serveur dns du syno, il faut aussi ouvrir le port de celui ci (53)
  4. je sais pas si on parle de la même chose, mais pour les soucis ovh évoqués les pages d'avant, mon bugfix a été mergé dans le master acme (et donc le docker) il y a 4 jours donc normal ! quand tu dit "supprimé les autres certificats", tu veux dire que tu as suppr les certs générés par acme et gardé que ceux en convertis par openssl ? si oui c'est normal qu'il arrive pas a les déployer, il veux utiliser ceux qu'il a généré lui ! t'es bon pour redemander un nouveau cert et refaire le deploy (à priori pas besoin de passer par l'étape conversion + import manuel cette fois ! )
  5. pour le pare feu, tu aurais pas bloqué les USA par hasard ? Sinon, c'est que tu as oublié le pramètre --dns dns_ovh lors dans demande de certificat, dans ce cas le comportement par défaut d'acme est une vérification HTTP-01, la même que celle de DSM et qui nécessite donc l'ouverture des ports 80 et 443 (si c'est ça ils sont donc aussi ouverts sur ton routeur !!)... sinon saute l'étape 3A, j'ai pas trop compris pourquoi le tuto réclame ça. @Einsteinium te rappelles-tu ce qui t'avais amené à passer par un import manuel ? ca m'intéresse edit: j'ai relu le début du thread, c'est pour forcer tous les services internes du dsm a s'attacher du cert ? moi comme j'utilise un SAVED_SYNO_Certificate='' vide, ca remplace le cert par défaut, qui est seul et utilisé pour tout chez moi, pas besoin d'import donc Donc @axb, dans ton account.conf tu dois avoir ceci SAVED_SYNO_Scheme='http' SAVED_SYNO_Hostname='172.17.0.1' SAVED_SYNO_Port='ton port' SAVED_SYNO_Username='username' SAVED_SYNO_Password='username_password' SAVED_SYNO_Certificate='' http et non https (inutile de faire du https car tu reste sur la même machine) : à priori déjà OK d'apres ton log l'ip doit rester a 172.17.0.1 (et non pas l'ip locale de ton nas comme dans ton log) le port lui doit bien être le port HTTP de ton dsm (64.... d'après ton log) le SAVED_SYNO_DID pas la peine de le mettre, ca sert a rien si t'as pas la double auth (qui est de façon inutile si t'as bien restreint les droits de ton SAVED_SYNO_Username au strict minimum et bien activé fail2ban (protection de compte compte dans les options dsm). SAVED_SYNO_Certificate='' doit donc rester vide pour te dispenser du step 3A, ca remplacera le cert par défaut directement il faut aussi que tu edites le fichier /docker/Acme/domain.tld/domain.tld.conf et que tu supprimes (on remplace, au choix) les lignes SAVED_SYNO_xxx pour que acme prenne en compte tes modifs du account.conf enfin tu lance en ssh root ou par tache exec unique root : docker exec Acme --deploy -d domain.tld --deploy-hook synology_dsm si tout est OK tu dois voir [Fri Jul 23 20:22:38 UTC 2021] Logging into 172.17.0.1:tonport [Fri Jul 23 20:22:38 UTC 2021] Getting certificates in Synology DSM [Fri Jul 23 20:22:38 UTC 2021] Generate form POST request [Fri Jul 23 20:22:38 UTC 2021] Upload certificate to the Synology DSM [Fri Jul 23 20:22:42 UTC 2021] http services were restarted [Fri Jul 23 20:22:42 UTC 2021] Success le "http services were restarted" est important, c'est ce qui confirme que les serveurs web du dsm ont bien pris en compte le nouveau certificat (on aura un "not restarted" si on ne fait que rajouter / remplacer un certificat non-défaut). En dernière vérif: refresh la page web dsm (relance ton navigateur au besoin pour forcer le refresh) et dans le cadenas à coté de l'url, regardes les propriétés du cert, tu devrais bien avoir ton wildcard dans details / subject alternative name vala
  6. Yep, faut plutôt voir ça comme un ultime garde-fou (on ne doit recevoir aucun e-mail si le docker marche car il renouvelle à 60 jours, les mails eux ne commencent qu’à 70). L’avantage c’est que c’est indépendant de toute config sur le Nas !
  7. Je ne pense pas non, mais tu peux toujours le faire au cas où tu supprimerai le dossier /ca , qui occasionnerai la création d’un nouveau compte Letsencrypt, tu n’aurais alors pas besoin de repasser la commande update-account
  8. tant que j'y pense, si vous voulez que let's encrypt vous envoie un mail de rappel pour le renouvellement (ça commence à partir de 20 jours de validité restante sur les 90 si on a pas déjà renouvelé) vous pouvez ajouter à votre account.conf avant la première demande de certificat : ACCOUNT_EMAIL='votre@email.tld' si vous avez déjà un certificat mis en place par acme (et donc un compte letsencrypt, automatiquement crée lors de la toute première demande), il faut passer la commande (en ssh ou tache planifiée exec unique) docker exec Acme --update-account --accountemail 'votre@email.tld' qui doit retourner account update success for https://acme-v02.api.letsencrypt.org/acme/acct/xxxxxxxxx c'est un mécanisme finalement assez utile, ça permet de se rendre compte si le docker déconne
  9. si le firewall de ton syno est actif, tu peux essayer de le désactiver temporairement ? le account.conf, tu l'as bien crée depuis l'éditeur de texte du syno en mode utf-8 ? car si tu l'as crée sur windows, les fin de lignes (caractère invisible cr-lf sur windows vs lf sur linux) peuvent foutre en carafe quand acme le relis. sinon, peux-tu paste la sortie de docker inspect Acme a call en ssh sur le nas
  10. yep, c'est tout à fait ce que je j'observe et décrit dans l'issue github j'ai testé mon fix comme un porc et y'a plus aucun soucis ni de délivrance du certificat ni de pollution, yay !
  11. ma PR a été mergée dans la branche dev, neil à meme pas posé de question donc mon fix sera dispo sur le docker à la prochaine release (merge de dev vers master) en attendant, si vous avez le problème, la seule solution est d'insister comme un porc sur la requête issue, ça fini par passer... c'est normal que tu vois des requetes /domain/zone/__acme-challenge.ndd.tld par contre elles doivent être refusées avec un 403 Unauthorized + "this call has not been granted" des fois elles ne le sont pas et acme considère que ton domaine est "__acme-challenge.ndd.tld" au lieu de "ndd.tld" et ca fait déconner tout le reste vu que c'est pas le bon domaine
  12. pour info, j'ai bien galéré, mais j'ai fini par trouver et ai proposé un patch pour fix le bug d'ajout/suppression des TXT https://github.com/acmesh-official/acme.sh/issues/3616
  13. problème de config réseau en dirait, acme.sh arrive pas à contacter l'API LE. ton nas à bien accès au net ? en ssh dessus, tu peux ping letsencrypt.org ? sinon un log plus long pourrais aider...
  14. bon j'ai une piste qui indiquerai que c'est pas les API ovh qui déconnent mais acme.sh... quand ça fail, c'est le script qui construit une requête "records of the zone" mal formée de Ia forme get domain/zone/_acme-challenge.ndd.tld/record?... au lieu de get domain/zone/ndd.tld/record?... l'api répond du json pour dire que ca n'existe pas (obviously, c'est pas le bon domaine). Le script lui s'attends à l'ID (rid, record id) associé au TXT demandé dans les params du get... il essaye de continuer avec le json au lieu d'un long int sur le call d'après (get record id properties ) et se fait jeter par curl qui lui dit requete mal formée ! maintenant reste à trouver pourquoi... si c'est avéré j'irai ouvrir une issue (ou ptet une PR de fix si c'est facile) sur GH bon, peux pas tester plus maintenant, incident let's encrypt
  15. ahah, je vois je suis donc pas fou ton script sera plus que le bienvenu !! Je viens de faire 10 essais de suite: 100% ok : 1 cert ok mais suppr record nok : 2 nok no cert : 7 donc, même avec le script de bruno pour dépolluer la zone, on est sur un taux de réussite de seulement 30% Et à priori c'est juste OVH qui déconne car -sur les problèmes que je vois- la partie LE concerne uniquement l'acquisition des challenges à mettre dans les TXT, pas leur création / suppression. A continuer de tester dans les jours/semaines qui suivent mais si OVH continue à faire des siennes, une solution plus pérenne pourrait être délocaliser la zone DNS chez DigitalOcean, CloudFlare, ... pas idéal mais bon C'est un txt nommé __acme_challenge.ndd.tld ? tu peux le supprimer, car justement il est (sont) normalement crée et détruit durant la procédure de renouvellement