Ok, je vois, mais stp, arrête de dire que Let's Encrypt ne sait utiliser que du port 80 ou 443: c'est tout bonnement faux.
De souvenir quand tu utilises un port non standard, alors ce port est inséré dans le nom de domaine (par exemple HelloWorld.com:8666 et le certif n'est alors pas utilisable sans alerte pour HelloWorld.com).
Pour le challenge HTTP ("montre moi que tu peux poser un fichier sur un serveur web accessible avec ce domaine"), oui, c'est bien le port 80 qui est requis et ce simplement pour prouver que tu maîtrises l'infrastructure Web du nom de domaine.
Tu peux utiliser le challenge DNS ("montre moi que tu peux créer une ressource DNS pour ce domaine"), eh bien, c'est le port 53 qui est utilisé.
Pour l'instant, ces 2 challenges sont les seuls disponibles et donc les ports 53 et 80.
Si tu veux pouvoir créer des certificats tu dois donc nécessairement avoir un de ces 2 ports accessibles sur Internet, si non, ça veut dire que tu n'es pas capable de prouver que ces domaines t'appartiennent.
Serait-ce utilisable pour jean-kévin qui voudrait sécuriser l'accès à la WEBUI de sa seedbox Deluge ?
Je ne sais pas ce qu'est une seedbox Deluge, mais si tu es capable d'y associer un nom de domaine oui, tu peux la sécuriser par une des 2 techniques proposées par le protocole ACME.
Mon outil, acme-dns-tiny, par exemple nécessite une machine avec un service DNS qui est capable de faire de la mise à jour dynamique des ressources DNS grâce à TSIG. Sur une autre machine (ta seedbox par exemple), tu as juste besoin d'avoir python3 (avec les modules dnspython et requests) et openssl d'installé. Tu peux voir la documentation pour configurer ta seedbox et le serveur avec bind9 dans le wiki.
Cet outil, n'est pas le seul à savoir faire des certificats avec le challenge DNS, je te laisse chercher sur le web celui qui te convient le mieux.
Pour la partie certificats auto-signés, je vois donc que ce n'est pas facilement cassable si tu sais gérer les certificats installés sur tes machines (donc en les pré-installant sur les machines concernées pour ne pas avoir à faire des comportements dangereux comme "accepter par défaut tous les certificats auto-signés"). Et comme ce serait pour utiliser dans un réseau local, ça devrait le faire assez facilement et donc l'excuse "j'utilise un VPN" n'est pas du tout un bon argument.
Note d'ailleurs que SSH a exactement le même défaut si tu n'installes pas les clés de l'hôte dans des ressources DNS sécurisées par DNSSEC: tu dois manuellement vérifier les fingerprint des certificats utilisé par SSH.
[^] # Re: ca commence
Posté par Adrien Dorsaz (site web personnel, Mastodon) . En réponse à la dépêche Firefox 68 et 68 ESR par le menu. Évalué à 3.
Pour le challenge HTTP ("montre moi que tu peux poser un fichier sur un serveur web accessible avec ce domaine"), oui, c'est bien le port 80 qui est requis et ce simplement pour prouver que tu maîtrises l'infrastructure Web du nom de domaine.
Tu peux utiliser le challenge DNS ("montre moi que tu peux créer une ressource DNS pour ce domaine"), eh bien, c'est le port 53 qui est utilisé.
Pour l'instant, ces 2 challenges sont les seuls disponibles et donc les ports 53 et 80.
Si tu veux pouvoir créer des certificats tu dois donc nécessairement avoir un de ces 2 ports accessibles sur Internet, si non, ça veut dire que tu n'es pas capable de prouver que ces domaines t'appartiennent.
Je ne sais pas ce qu'est une seedbox Deluge, mais si tu es capable d'y associer un nom de domaine oui, tu peux la sécuriser par une des 2 techniques proposées par le protocole ACME.
Mon outil, acme-dns-tiny, par exemple nécessite une machine avec un service DNS qui est capable de faire de la mise à jour dynamique des ressources DNS grâce à TSIG. Sur une autre machine (ta seedbox par exemple), tu as juste besoin d'avoir python3 (avec les modules
dnspythonetrequests) et openssl d'installé. Tu peux voir la documentation pour configurer ta seedbox et le serveur avec bind9 dans le wiki.Cet outil, n'est pas le seul à savoir faire des certificats avec le challenge DNS, je te laisse chercher sur le web celui qui te convient le mieux.
Pour la partie certificats auto-signés, je vois donc que ce n'est pas facilement cassable si tu sais gérer les certificats installés sur tes machines (donc en les pré-installant sur les machines concernées pour ne pas avoir à faire des comportements dangereux comme "accepter par défaut tous les certificats auto-signés"). Et comme ce serait pour utiliser dans un réseau local, ça devrait le faire assez facilement et donc l'excuse "j'utilise un VPN" n'est pas du tout un bon argument.
Note d'ailleurs que SSH a exactement le même défaut si tu n'installes pas les clés de l'hôte dans des ressources DNS sécurisées par DNSSEC: tu dois manuellement vérifier les fingerprint des certificats utilisé par SSH.