Certificat Let's Encrypt / Domaine non valide !! ?

[Dimebag Darrell]

Je relance ce topic,

Bizarement, j'ai ce problème qui m'est apparu, hors, il y a quelques mois, ça fonctionnait correctement. (création de cerificats - récement, j'ai eu besoin d'un nouveau sous-domaine qui exige un certificat)

Par contre, pour les certificats existants, je n'ai aucun problème à les renouveler !

Quelqu'un a une idée ?

[Mic13710]

Il y a 6 heures, Dimebag Darrell a dit :

récement, j'ai eu besoin d'un nouveau sous-domaine qui exige un certificat

Est-ce que ce nouveau domaine est bien enregistré ? A vérifier https://dnslookup.fr/

Si je ne dis pas de bêtise, le certificat ne peux pas être délivré pour un CNAME. Si vous avez ajouté un CNAME toto.ndd, il faut demander un certificat à la fois pour le ndd et un SAN (autre nom) toto.ndd

Vous avez aussi la possibilité de redemander un certificat pour l'ensemble des domaines liés à votre domaine principal

[Dimebag Darrell]

Dans OVH, je vais dans Zone DNS, ensuite, ajouté une entrée, je choisis CNAME (je pointe vers ma cible).

J'ajoute mon sous domaine et ma cible (comme je l'ai fait précédemment pour mes autres sous-domaine).

Bizarrement par le passé, la génération de certificat se passait bien, et là ce n'est plus le cas

 

[Dimebag Darrell]

Je viens de refaire le test en supprimant le reverse proxy, et en ouvrant les port du NAS sur le modem/routeur.

Rien à faire, ça ne fonctionne pas, par contre la mise à jour des autres certificats, ça passe crème !

 

[Mic13710]

Est-ce que vous avez vérifié que le ndd est valide comme indiqué dans mon message ci-dessus ?

[Dimebag Darrell]

oui,

il est utilisé par les autres sous-domaine.

[Mic13710]

Premièrement, comme dirait Fenrir, un sous-domaine ça n'existe pas. ndd est un domaine, comme toto.ndd est un domaine, tout comme titi.toto.ndd est encore un domaine.

Quand je parlais de vérifier le domaine, c'est le domaine pour lequel vous avez activé un CNAME chez OVH, ou si vous préférez "lenouveaunomCNAME.ndd"

Si vous avez obtenu un certificat pour votre ndd et ses SAN, c'est que votre ndd et les SAN associés sont valides. Si vous ne pouvez pas créer un certificat pour le même ndd avec d'autres SAN, c'est qu'un ou plusieurs SAN n'est (ne sont) pas valide(s).

[Dimebag Darrell]

Oui, sorry pour le mauvais "wording"

Mes domaines sont bien créés chez OVH, pour confirmer que le problème ne se situait pas au niveau de mon réseau, j'ai mis mon NAS dans une DMZ.

Même en faisant cela, impossible de créer un certificat...

 

Citation

 

Si vous avez obtenu un certificat pour votre ndd et ses SAN, c'est que votre ndd et les SAN associés sont valides. Si vous ne pouvez pas créer un certificat pour le même ndd avec d'autres SAN, c'est qu'un ou plusieurs SAN n'est (ne sont) pas valide(s).

 

 

Que faire alors ?

[Mic13710]

Encore une fois, est-ce que vous avez vérifié si votre nouveau domaine est reconnu chez https://dnslookup.fr/

Je ne parle pas du domaine principal (bien que vous pouvez aussi le vérifier) mais bien du nouveau domaine, celui qui vous pose problème.

S'agissant d'un domaine avec un enregistrement CNAME, la réponse devrait être :

"Attention l'enregistrement pour le domaine est dans un champ CNAME au lieu d'être dans un champ A"

P.S. : inutile de mettre le NAS en danger en faisant de l'open bar. Si vous pouvez renouveler votre certificat valide, c'est que le port 80 est bien ouvert et bien dirigé vers le NAS. Dès lors, il ne sert à rien d'ouvrir en grand portes et fenêtres.

[Dimebag Darrell]

sur https://dnslookup.fr/

J'ai une réponse : 

• Attention l'enregistrement pour le domaine est dans un champ CNAME au lieu d'être dans un champ A

Il y a 3 heures, Mic13710 a dit :

P.S. : inutile de mettre le NAS en danger en faisant de l'open bar. Si vous pouvez renouveler votre certificat valide, c'est que le port 80 est bien ouvert et bien dirigé vers le NAS. Dès lors, il ne sert à rien d'ouvrir en grand portes et fenêtres.

 

Bien entendu, mais je voulais vérifier que ce n'était pas un soucis d'accès ou une restriction (via mon réseau local)

[Mic13710]

Si votre nouveau domaine est reconnu, il reste une possibilité qui empêche de créer ou renouveler un certificat, c'est le nombre de requêtes pour un même domaine qui est limité à 5 par semaine. Si vous avez atteint ce quota, il est possible que ce soit LE qui vous empêche de créer un nouveau certificat. Je crois que cette limitation a été plus ou moins levée mais je n'en suis pas sûr.

[Dimebag Darrell]

j'ai ouvert un ticket chez OVH, on verra leur réponse, merci pour les conseils

[Dimebag Darrell]

problème résolu.

J'ai essayé avec un domaine .synology.me, ça a fonctionné.

Dès que j'ai ré-essayé avec mon domaine OVH, c'est passé aussi 🙂

[TuringFan]

Bonjour @Mic13710 et @Dimebag Darrell,

Je suis novice en réseau et je suis face au même problème : "Echec de la connexion à Let's Encrypt. Assurez-vous que le nom de domaine est valide" quand j'essaie de créer un certificat pour ndd.eu.

J'ai attendu plus d'une dizaine de jours avant de renouveler mon test.
J'ai également testé mon domaine ici et j'ai bien mon IP qui est affichée.

J'avais historiquement créé un certificat sur mon domaine en synology.me (en intégrant ndd.eu en domaine supplémentaire) lorsque j'avais suivi le tuto de sécurisation de Fenrir : aucun problème alors.

Je me dis que c'est probablement moi qui ai fait une mauvaise configuration, j'ai mon NAS derrière un routeur Synology en DMZ de ma Livebox. Ci-après les captures d'écran de mes configurations.

Merci d'avance pour votre éventuelle aide car je sèche complètement.

 

[oracle7]

@TuringFan

Bonjour,

Voilà comment j'ai organisé mes règles de transfert de ports sur le RT :

Chez moi, après validation elles se retrouvent automatiquement (*) (je ne les ai pas créées manuellement dans le parefeu) dans le parefeu du RT "en grisé" telles que :

(*) c'est d'ailleurs le cas de toutes les règles de transfert que j'ai créées dans l'onglet adéquat.

Edit2 : pour la création automatique des règles de transfert dans le parefeu j'ai coché cela :

 

Je ne comprends pas non plus pourquoi dans le parefeu tu as limité les ports 80 et 443 aux @IP  sources de LE et aux ports source qui devraient être eux sur "Tous".

De plus, le port 443 doit être séparé du port 80 (une règle chacun), LE n'en fait pas le même usage d'une part et d'autre part le port 80 n'est utilisé QUE lors du renouvellement du certificat LE, le reste du temps il est fermé, règle désactivée (sauf cas d'usages particuliers).

Edit : idem dans le parefeu du NAS, sépares les règles sur ces ports.

Par ailleurs, saches que les @IP 66.133.109.36 et 64.78.149.144 ne sont à priori plus opérationnelles. Elles l'ont été quelques années durant mais plus maintenant depuis le changement de politique de LE. Pour le renouvellement du certificat LE , tout semble passer par le port 443 seul selon certains ici. Dans l'attente de confirmation, il semble qu'il faille tout de même ouvrir le port 80 au moment du renouvellement.

Cordialement

oracle7😉

Cordialement

 

 

 

Modifié le 10 mai 2020 par oracle7

[TuringFan]

TOP @oracle7,

Tu m'as encore aidé à résoudre un problème ! un merci de plus donc !

PS : si je n'accède qu'en local ou en VPN à mon NAS y a t il une contre indication à désactiver les règles 443/80 sur le RT et le NAS ou à contrario à les laisser toujours actives ?

Merci encore !

Je viens également de me rendre compte que pour que mon navigateur ne m'inique pas la page comme dangereuse il fallait supprimer le certificat par défaut en synology.me. Après relecture c'était bien indiqué dans le tuto de fenrir sur la sécurisation.

En revanche lors de la certification de mon ndd;eu j'ai également fait certifié de "sous domaine" (abu de langage car grâce à ce forum nous savons que ça n'existe pas) en nas.ndd.eu et en rt.ndd.eu : celui en nas.ndd.eu apparait comme sécurisé mai pas celui en rt.ndd.eu ! As tu une idée du problème ?

Modifié le 10 mai 2020 par TuringFan

[oracle7]

@TuringFan

Comme cela remplit ma boîte à bons points 😂😂😂

Pour moi, il faut les laisser actives dans le RT pour que le mécanisme de reverse proxy puisse fonctionner, sinon par ex pour le port 443, tu ne pourrais plus accéder de l'extérieur avec un simple "monsousdomaine.ndd.tld" et sûrement d'autres services qui utilisent ce port 443 seraient alors bloqués. C'est quand même le port de communication sécurisé par essence me semble-t-il. Non ?

PS : Attention j'ai édité ma précédente réponse.

Cordialement

oracle7😉

[TuringFan]

il y a 1 minute, oracle7 a dit :

PS : Attention j'ai édité ma précédente réponse

Oui, bien vu : j'ai volontairement décoché cette option poour avoir plus de possibilité sur les règles per-feu, notamment faire de la discrimination d'IP sources.

il y a 22 minutes, TuringFan a dit :

Je viens également de me rendre compte que pour que mon navigateur ne m'inique pas la page comme dangereuse il fallait supprimer le certificat par défaut en synology.me. Après relecture c'était bien indiqué dans le tuto de fenrir sur la sécurisation.

En revanche lors de la certification de mon ndd;eu j'ai également fait certifié de "sous domaine" (abu de langage car grâce à ce forum nous savons que ça n'existe pas) en nas.ndd.eu et en rt.ndd.eu : celui en nas.ndd.eu apparait comme sécurisé mai pas celui en rt.ndd.eu ! As tu une idée du problème ?

Par ailleurs en tapant uniquement nas.ndd.eu le port 5001 est automatiquement ajouté et j'arrive sur la page du DSM en revanche je dois mettre le port pour le routeur, rt.ndd.eu.

je ne comprends pas cette dissymétrie de comportement entre nas.ndd.eu et rt.ndd.eu tant au niveau du certificat que du port ajouté seul par le navigateur ?

Au fait @oracle7 as tu résussi à utiliser le nom de domaine depuis un accès VPN sans décocher l'option de "passerelles multiples" sur le NAS  ?

Merci encore,

[Kramlech]

Il y a 4 heures, TuringFan a dit :

Par ailleurs en tapant uniquement nas.ndd.eu le port 5001 est automatiquement ajouté

Ça c'est normal si tu n'as pas activé Web Station : une requête vers le NAS renvoie automatiquement sur le DSM

[oracle7]

@TuringFan

Bonjour,

Il y a 15 heures, TuringFan a dit :

Au fait @oracle7 as tu résussi à utiliser le nom de domaine depuis un accès VPN sans décocher l'option de "passerelles multiples" sur le NAS  ?

Non :

1. Il faut que "passerelles multiples" soit décochée pour que d'une part la connexion VPN puisse s'établir
2. D'autre part, une fois la connexion VPN établie depuis mon Smartphone par ex, impossible de se connecter en tapant "monNAS.ndd.tld". Cà n'aboutit pas !

Donc pour l'instant, la connexion VPN depuis l'extérieur semble inutilisable. 😩😩😩 même si elle est active.

Je continue à chercher pourquoi.

Cordialement

oracle7😉

[Juan luis]

il y a 20 minutes, oracle7 a dit :

 

 

1. Il faut que "passerelles multiples" soit décochée pour que d'une part la connexion VPN puisse s'établir
2. D'autre part, une fois la connexion VPN établie depuis mon Smartphone par ex, impossible de se connecter en tapant "monNAS.ndd.tld". Cà n'aboutit pas !

Donc pour l'instant, la connexion VPN depuis l'extérieur semble inutilisable. 😩😩😩 même si elle est active.

Je continue à chercher pourquoi.

Cordialement

oracle7😉

Bonjour,

En VPN est ce que vous parvenez à vous connecter en utilisant l'adresse privée du NAS ?

Si c'est le cas en quoi est ce si gênant  sachant que l'adresse privée du nas ne va pas changer toute seule et qu'elle se mémorise dans les applis...?

Cordialement

[Kramlech]

Il y a 2 heures, oracle7 a dit :

D'autre part, une fois la connexion VPN établie depuis mon Smartphone par ex, impossible de se connecter en tapant "monNAS.ndd.tld". Cà n'aboutit pas !

Est-ce que connecté sur ton réseau interne (sans VPN), la connexion via "monNAS.ndd.tld" abouti ? (autrement dit est-ce que ton routeur sait gérer le loopback, ou est-ce que tu as installé un serveur DSN sur ton NAS ?)

[oracle7]

@Kramlech

Bonjour,

il y a 2 minutes, Kramlech a dit :

Est-ce que connecté sur ton réseau interne (sans VPN), la connexion via "monNAS.ndd.tld" abouti ? (autrement dit est-ce que ton routeur sait gérer le loopback, ou est-ce que tu as installé un serveur DSN sur ton NAS ?)

Pas de soucis, j'accède (hors connexion VPN) sans problème avec "xxxx.ndd.tld" à toutes les applications (DSM, File, Audio, etc ...) en local comme de l'extérieur. Le reverse proxy fait son job à merveille en liaison avec le DNS installé sur le NAS.

Je viens de tester en tapant directement l'@IP du NAS (10.8.0.1:5000) depuis mon smartphone avec la connexion OpenVPN active, la liaison semble démarrer, mais l'indicateur d'avancement reste bloqué (après environ 2 minutes) à environ 85%. PAr ailleurs, dans VPN Serveur je me vois bien connecté avec l'@IP sur smartphone.

Voilà où j'en suis.

Cordialement

oracle7😉

[TuringFan]

Bonsoir et merci pour vos réponses.

Il y a 10 heures, Juan luis a dit :

Si c'est le cas en quoi est ce si gênant  sachant que l'adresse privée du nas ne va pas changer toute seule et qu'elle se mémorise dans les applis...?

Tu as raison modulo le fait que je souhaiterais accéder à d'autres appareils (donc d'autres IP) mais aussi et surtout que je souhaite relever le challenge technique "pour le sport" et pour apprendre.

Il y a 10 heures, Juan luis a dit :

En VPN est ce que vous parvenez à vous connecter en utilisant l'adresse privée du NAS ?

Oui du coup,

Il y a 8 heures, Kramlech a dit :

Est-ce que connecté sur ton réseau interne (sans VPN), la connexion via "monNAS.ndd.tld" abouti ? (autrement dit est-ce que ton routeur sait gérer le loopback, ou est-ce que tu as installé un serveur DSN sur ton NAS ?)

Oui monNAS.ndd.eu aboutie en LAN grâce à un DNS installé sur mon NAS et sur lequel sont renvoyés tous mes périphériques via mon RT (le DHCP du routeur indique comme DNS celui du NAS).

Il y a 8 heures, oracle7 a dit :

tld"

Question bête : que veut dire "tld" ?

Il y a 8 heures, oracle7 a dit :

Je viens de tester en tapant directement l'@IP du NAS (10.8.0.1:5000) depuis mon smartphone avec la connexion OpenVPN active, la liaison semble démarrer, mais l'indicateur d'avancement reste bloqué (après environ 2 minutes) à environ 85%. PAr ailleurs, dans VPN Serveur je me vois bien connecté avec l'@IP sur smartphone.

Même comportement :

• Je peux me connecter sans problème depuis mon LAN avec monNAS.ndd.eu et/ou l'IP privée du NAS en 192.
• Je déconnecte ensuite mon PC de mon WIFI pour passer par le partage de connexion de mon smartphone et lance le VPN, le montage se fait et la connexion est bien visible dans le paquet VPN Server du NAS, j'ai bien accès à internet mais impossible de me connecter au NAS que ce soit via monNAS.ndd.eu, via son IP privée en 192. ou via l'IP VPN en 10. : j'ai moi aussi un chargement de la page qui débute sans jamais se terminer.
• A noter que le comportement est similaire en OpenVPN ou en L2TP/IPSec et que ces deux tunnels sont sur des clients différents et étaient parfaitement fonctionnels avant.

Moi aussi preneur de ton aide @Kramlech.

Merci d'avance,

[oracle7]

@TuringFan

Bonjour,

il y a 55 minutes, TuringFan a dit :

Question bête : que veut dire "tld" ?

Un TLD, abréviation de Top Level Domain (domaine de premier niveau), est le dernier segment d’un nom de domaine – la partie qui vient après le point final. L’exemple le plus courant est le .com, mais il y a tout un monde de TLDs différents ....

il y a 55 minutes, TuringFan a dit :

Il y a 11 heures, Juan luis a dit :

En VPN est ce que vous parvenez à vous connecter en utilisant l'adresse privée du NAS ?

Oui du coup,

Là je ne comprends pas car plus loin tu dis que tu constates le même comportement que moi en tapant l'@IP VPN du NAS en 10.x.0.x avec la connexion VPN établie vers le NAS ???

Cordialement

oracle7😉

@TuringFan

Au passage, je m’aperçois que l'on est en train de "polluer" le sujet initial sur le renouvellement du certificat LE.

Je t'invite à poursuivre cet échange dans le sujet "VPN server" qui est plus approprié vu la tournure de nos échanges.

Merci de ta compréhension.

Cordialement

oracle7😉

Modifié le 11 mai 2020 par oracle7