Jeff777

Bonjour, Oui tout à fait. Si ton fournisseur d'accès ne fait pas de loopback (accès en local en passant par le réseau externe) il faut avoir une zone privée pour que tu puisses te connecter avec tes noms de domaines appli.ndd sinon ça ne fonctionne pas. Il faut donc implémenter la partie zone privée du tuto : Pour être certain de se connecter en 4G depuis un smartphone il faut couper le WIFI et utiliser les données mobiles. Essaie également, si tu as cette possibilité, de te connecter depuis une autre box.

Bonsoir, C'est normal. Si tu veux être sécurisé sur une requête en http il faut une redirection vers du https. Je te conseille d'utiliser un fichier .htaccess comme indiquer dans ce tuto en partie VII :

Comment tu fais pour arriver sur l'interface du DSM ?

Ok donc je suppose que tu as fait le test zonemaster et que ta zone est correcte. Au fait tu essaies de te connecter depuis ton LAN ou bien en 4G ?

c'est quel tuto ? il faudra que je me documente un jour sur les IP dynamique par curiosité.

Tu n'as pas d'autres enregistrements? Tu dois au minimum avoir un enregistrement A de ton domaine vers l'adresse IP publique. Edit : sauf que pour les IP non fixe que tu sembles avoir je ne sais pas comment on fait.

Qu'a tu mis comme enregistrements dans ta zone ?

oui photo.ndd.tld c'est = à ce que tu mets comme reverse proxy pour arriver sur photostation. ndd.tld, ça c'est forcément ton domaine et photo ou photos ou n'importe quoi d'autre ce que tu utilises devant ton nom de domaine pour le reverse proxy. Pour être certain que le .htaccess est correct regarde si la partie redirection http vers https fonctionne. Par exemple tape dans le navigateur "fichiers.ton_domaine" sans rien devant et vérifie que l'adresse passe bien en https avec un cadenas. Essaie aussi de changer de navigateur.

Donc c'est htaccess qui ne fonctionne pas. Vérifie : Que si tu as placé le fichier .htaccess sous le répertoire web que ce fichier est correctement constitué (créé un fichier texte. Copier/coller le texte que je t'ai indiqué. enregistrer sous .htaccess. Ne pas oublier le point, et s'assurer que dans l'onglet affichage de l'explorateur de fichier, la case "afficher/masquer" "extensions de fichiers" est bien décochée pour être certain que le fichier .htaccess n'a pas l'extension .txt . Que webstation est correctement installé. En résumé tout est dans ce tuto en plus de de que j'ai indiqué spécifique à photostation.

Est-ce que ton .htaccess est opérationnel ? Quand tu tapes un reverse proxy qui marche en http est-ce que tu arrives bien en https avec le cadenas ? Que veux-tu dire par là???

après ça dépend des droits que tu donnes. Dossier partagé ne veut pas dire que tu l'ouvre au monde mais tu te réserves le droit de pouvoir l'ouvrir à d'autres. Ceci étant dit il faut-être prudent. Essaie ceci (à le place de syno..... tu mets le reverse proxy qui est dirigé vers DSM), ça veut dire que les raccourcis utiliseront ce schéma :

Euh...que veux-tu dire par là. Personnellement je mets toutes mes photos dans le dossier partagé photo de photostation. Tu peux y accéder aussi par Moments dans la "bibliothèque de photos partagée.

Voilà ce que j'ai dans les paramètres photostation (surtout ce qui est fléché). (l'accès doit être possible avec ip_local_nas/photo )

Par DS PHOTO tu dis que tu as accès ! avec le reverse proxy ?? Au pire tu redémarre le NAS. Et surtout tu vides bien le cache de ton navigateur. Réseau/paramètre DSM la case de redirection de http vers https est bien décochée (si la redirection est faite par .htaccess cette case ne doit pas être cochée).

Peut-être les paramètres généraux de photo-station. Je n'ai rien coché dans port du routeur ni la redirection http vers https dans "autres paramètres" du même onglet.

Pas de quoi

Bonjour Avec ceci en htaccess : RewriteEngine On RewriteCond %{HTTPS} off RewriteRule (.*) https://%{HTTP_HOST}%{REQUEST_URI} RewriteCond %{HTTP_HOST} ^photo.ndd.tld$ RewriteRule ^$ https://photo.ndd.tld/photo [L,R=301] Et un reverse : https://photo.ndd.tld ==> iplocaledu NAS ça fonctionne bien 😉

Bonjour @oracle7 Je crois que chacun va rester sur sa position.🙄 Ah oui @Fenrir nous aiderait bien à faire la lumière ! Bonne journée

Oui mais si on lit le début de l'article. J'ai bien l'impression que l'on parle des deux défis. Let’s Encrypt prend en charge IPv6 pour accéder à l’API ACME à l’aide d’un client ACME, et pour les recherches DNS et les requêtes HTTP que nous faisons lors de la validation de votre contrôle des noms de domaine. ...........Étant donné que le client ACME configure uniquement le serveur IPv4 pour répondre au défi, la validation du domaine échouera lorsque l’IPv6 du serveur sera utilisée. Répondre au défi sans précision duquel Comme toi je voudrais bien que cela ne concerne pas le défi DNS-01,.....bien que : Ma zone que j'héberge sur le NAS1 ( et qui possède un slave sur le NAS2) a un enregistrement A et un enregistrement AAAA. A pointe sur le NAS1 de mon LAN (IPV4 de mon domaine et redirection vers le NAS1) et AAAA est l'adresse IPV6 de mon NAS2. Dans le cas d'un renouvellement de certificat Let's encrypt par acme sur le NAS1 Let’s Encrypt préférera toujours les adresses IPv6 pour la connexion initiale. Donc dans mon cas le NAS2 et Étant donné que le client ACME configure uniquement le serveur IPv4 pour répondre au défi, la validation du domaine échouera lorsque l’IPv6 du serveur sera utilisée. sauf que dans mon cas le serveur IPV4 configuré c'est le NAS1 mais la zone slave du NAS2 reproduit les enregistrements TXT faits sur le NAS1 dans le cas d'un défi DNS-1 et la validation du domaine n'échouera pas sur ce dernier. Ce que je cherchais à comprendre c'est pourquoi malgré ma config. le renouvellement d'un certificat avec acme fonctionne. Je voudrais savoir si ce que je raconte ici tiens la route, ou bien si, comme tu le dis, DNS-1 n'est pas concerné par ce problème.

Si je te pose la question c'est que j'ai relu plusieurs fois l'article et que je ne vois nulle part que c'est uniquement dans le cas d'un défi HTTPS-01. L'article donne bien des précisions dans le cas de ce défi mais ne limite pas le pb à celui-ci. Du moins avec mon maigre niveau de compréhension 🤣

Euh...je n'ai pas compris que ce problème était uniquement dans le cas d'un défi "HTTP-01". Si c'est vraiment le cas ça m'arrangerai en effet.

Bonjour à tous, Voilà peut-être l'explication ☺️. Je viens de tomber par hasard sur ce site et je me suis souvenu de ce post.

@bruno78 @oracle7 @.Shad. Bon je serai très prudent. J'ai peut-être une piste pour l'automatisation de l'affectation des services. Du moins dans le cas du remplacement d'un certificat. Je l'ai fait en staging car je n'ai plus de cartouche pour le faire hors staging j'ai donc un certificat "fake" mais les services lui sont affectés. D'autre part, même si je suis chez OVH je n'utilise pas les DNS d'OVH mais DNSServeur et un DNS secondaire chez HE. Le certificat a été obtenu sur un deuxième NAS en utilisant acme sur le premier. Alors question : Si la procédure est délocalisée du NAS dont on veut renouveler le certificat (sur un autre NAS ou peut-être un Rasberry) est-ce que cela pourrait fonctionner?

Oui mais pour mon cas il faut qu'il soit présent sur les deux nas pour assurer la redondance en cas de crash d'un des deux .

Bonjour @oracle7 Je confirme que cela fonctionne. Je viens de créer un certificat sur mon deuxième NAS à l'aide de son hostname à partir du premier NAS. Je pense que l'on doit pouvoir lors des renouvellements déployer le même certificat sur les deux NAS. Edit : il est bien par défaut mais les services ne lui sont pas affectés. Cela ne te surprendra pas 😄