Differences

This shows you the differences between two versions of the page.

--- informatique:hardware:synology_ds415plus [2018/10/26 16:58] – [Erreur find en tâche planifiée] pteu
+++ informatique:hardware:synology_ds415plus [2018/11/02 16:33] – [Erreur syno-letsencrypt] TLDR pteu
@@ Line 252: / Line 252: @@
 ====Certificat SSL/TLS let's encrypt====
-Pour revalider son certificat [[https://letsencrypt.org/|let's encrypt]] (qui n'est valide que 3 mois) :
+Pour renouveler son certificat [[https://letsencrypt.org/|let's encrypt]] (qui n'est valide que 3 mois) :
-  * ouvrir le port tcp/80 vers le syno
+  * ouvrir le port public tcp/80 vers le port tcp/80 syno
-  * lancer en tant que root (login SSH + ''sudo -i'')
+  * se logguer en SSH avec un compte admin au syno, puis :
 <code bash>
-/usr/syno/sbin/syno-letsencrypt renew-all [ -v ]
+sudo /usr/syno/sbin/syno-letsencrypt renew-all [ -v[v] ]
 </code>
+(PS : le ''sudo -i'' marche aussi)
+Et si KO : penser à ouvrir bien grand (permit any any) le firewall Syno, cf anecdote qui suit.
+====Erreur syno-letsencrypt====
+<WRAP center round tip 80%>
+TL;DR : Le problème vient d'un filtrage géographique dans le firewall du Syno. Malgré que celui-ci soit désactivé, il bloque quand même les serveurs de letsencrypt. En créant une règle permissive (genre permit any en HTTP) on  fait tomber le script en marche !
+</WRAP>
+Je suis récemment tombé sur un os lors du renouvellement de mon certificat letsencrypt : alors que la redirection tcp/80 était bien en place sur mon routeur, le script se vautre en renvoyant l'erreur suivante :
+<code bash>
+sudo /usr/syno/sbin/syno-letsencrypt renew-all -v
+[..]
+DEBUG: DNS challenge failed, reason: {"error":108,"file":"challenge.cpp","msg":"Not synology DDNS."}
+DEBUG: Normal challenge failed, reason: {"error":200,"file":"client.cpp","msg":"new_authz: unexpect httpcode."}
+</code>
+Sympa l'erreur : "unexpect httpcode". Bon.
+On passe en mode Columbo : on désactive le firewall du Syno et on relance le script avec l'option //debug de la dernière chance// (''syno-letsencrypt -vv'') ; on voit que notre Syno génère un fichier de "challenge" et le mettre à disposition des serveurs letsencrypt :
+<code bash>
+# morceaux choisis du debug :
+      "error": {
+        "type": "urn:acme:error:connection",
+        "detail": "Fetching http://mydomain.com/.well-known/acme-challenge/YuOX1zXw-\
+lD20Th6mHJzDNhBDkURHo1ZFBHxh5F-A-0: Timeout during connect (likely firewall problem)",
+        "status": 400
+      }
+</code>
+Ce challenge permet de valider que :
+  * c'est bien vous qui avez initié la demande de renouvellement
+  * c'est bien vous le propriétaire du domaine
+Ce fichier est mis à disposition en HTTP par le serveur nginx du Syno :
+<code bash>
+grep -Ri -A3 "acme-challenge" /etc/nginx/*
+/etc/nginx/nginx.conf-        location ^~ /.well-known/acme-challenge {
+/etc/nginx/nginx.conf:            root /var/lib/letsencrypt;
+/etc/nginx/nginx.conf-            default_type text/plain;
+/etc/nginx/nginx.conf-        }
+</code>
+C'est bourrin mais ça paie : le dossier est bien configuré dans nginx, et il est situé "en vrai" dans **/var/lib/letsencrypt/.well-known/acme-challenge/** !
+Le dossier existe bel et bien et dispose des bons droits, mais en fouinant dans les logs d'erreur du serveur nginx du Syno, je trouve ceci :
+<code bash>
+/11/02 15:35:20 [error] 6972#6972: *51124 access forbidden by rule, client: 64.78.149.164, server: _, request: \
+"GET /.well-known/acme-challenge/56f1J6p6Wf3o-g219MmcZS7tCNufwA1Dj1Dm-ddGy1Y HTTP/1.1", host: "mydomain.com"
+</code>
+J'aime les erreurs "access forbidden by rule", ça m'aide beaucoup : je n'ai jamais défini de règle de filtrage dans nginx et il n'y en a pas sur ce dossier...
+Les fichiers de challenge sont temporaires et supprimés à la fin du script ; aussi on va faire le test avec un autre fichier :
+<code bash>
+echo "TEST" > /var/lib/letsencrypt/.well-known/acme-challenge/test
+</code>
+Puis, j'appelle le fichier depuis mon navigateur ou un wget :
+<code bash>
+wget -d http://mydomain.com/.well-known/acme-challenge/test
+[..]
+-11-02 16:21:06 (121 KB/s) — « test » sauvegardé [5/5]
+</code>
+Et là ça passe !
+C'est donc un filtrage en fonction de l'IP source ; n'ayant rien à perdre, je réactive le pare-feu de mon Syno et supprime le filtrage géographique (le champ "emplacement" dans la conf du firewall) : en mode "permit any any". Je relance le script...
+<code bash>
+/usr/syno/sbin/syno-letsencrypt renew-all -v
+[..]
+DEBUG: renew success. [/usr/syno/etc/certificate/_archive/OufCaMarche].
+</code>
+... et BIM ça marche !
+Aussi saugrenu que ça paraisse^W soit, chez Synology quand on décoche la case "Activer le pare-feu", ben ça vaut pas dire que ça le désactive (même après reboot du NAS) ! Par ailleurs vu que c'est de l'iptables, c'est étonnant que cela puisse arriver dans les logs nginx...
+Mais ma curiosité s'arrête là ; à dans 3 mois !
 ====Erreur find en tâche planifiée====