La Fibre
Télécom => Réseau => Protocoles réseaux sécurisés (https) => Discussion démarrée par: vivien le 03 février 2017 à 14:02:51
-
Le cas qui est complexe pour la migration StartCom => Let's encrypt, ce sont ceux qui ont des serveurs web anycast (une même IP est annoncée par plusieurs serveurs distincts)
Un seul serveur va réussir le challenge de Let's encrypt...
Pour rappel : (Source : Wikipedia anycast (https://fr.wikipedia.org/wiki/Anycast))
- En unicast, il n'existe qu'une association entre une adresse réseau et le point d'arrivée final : chaque adresse de destination identifie de manière unique un seul receveur final. Exemple: Youtube
- En broadcast et multicast, il y a une association "de une à plusieurs" entre les adresses réseau et les points d'arrivées finaux : chaque adresse de destination identifie un ensemble de récepteurs finaux, sur lesquels toute l'information est répliquée. Exemple: Flux live de votre FAI
- En anycast, il y a aussi une association "de une à plusieurs" entre les adresses réseau et les points d'arrivées finaux : chaque adresse de destination identifie un ensemble de récepteurs finaux, mais un seul d'entre eux est choisi pour recevoir l'information à un moment donné pour un èmetteur donné. Exemple : DNS 8.8.8.8 de Google la même IP est utilise par de nombreux serveurs.
-
En effet
Dans ce genre de cas, en fait, je pense que les certificats + clefs doivent être généré via un autre moyen, et propagé ensuite sur l'ensemble du cluster
-
Ou alors mettre le challenge dans un montage distant/partagé, ça marche aussi.
-
Le cas qui est complexe pour la migration StartCom => Let's encrypt, ce sont ceux qui ont des serveurs web anycast (une même IP est annoncée par plusieurs serveurs distincts)
Un seul serveur va réussir le challenge de Let's encrypt...
J'avoue que je vois pas bien le souci...
Ne sachant forcèment pas quel serveur va être interrogé, il faut bien sûr pousser la config sur tous ceux qui sont susceptibles de l'être, ce qui de toute façon va être automatisé, puisque ces serveurs sont censés être substituables les uns aux autres.
-
La problématique en anycast, en supposant que tu as des serveurs sur plusieurs continents, c'est que le challenge pour renouveler les certificats va échouer, vu que Let's encrypt vérifie que le serveur est joint depuis plusieurs endroits dans le monde et que un seul échec compromet le certificat.
Si c'est de l'anycast limité à un seul pays par contre, cela risque de fonctionner : c'est toujours le même qui sera interrogé. il suffit ensuite aux serveurs qui ne sont pas utilisés par les transits de récupérer la conf de celui qui est en visibilité des transits.
-
c'est toujours le même qui sera interrogé.
Source ? Pour m'être tapé des pages et des pages de doc letsencrypt, je suis quasi sur du contraire.
La problématique en anycast, en supposant que tu as des serveurs sur plusieurs continents, c'est que le challenge pour renouveler les certificats va échouer
Transférer un fichier vers un autre serveur, c'est une opération relativement courante. Rsync toussa ::)
-
Anycast pour un opérateur national : Let's encrypt n'ayant pas de serveur pour vérifier le challenge dans le réseau de l'opérateur, ce sera toujours le même serveur qui est interrogé, celui qui est à Paris par exemple pour un réseau centré sur Paris. Les serveurs de province utiliseront Rsync pour récupérer le bon certificat.
Anycast sur plusieurs continent : Let's encrypt vérifie de plusieurs point du globe qu'il arrive sur le même serveur en interrogeant le nom de domaine : ce sera un échec systématique : aucun serveur n'arrivera à obtenir le certificat, il est donc inutile de faire du Rsync.
-
Anycast pour un opérateur national : Let's encrypt n'ayant pas de serveur pour vérifier le challenge dans le réseau de l'opérateur, ce sera toujours le même serveur qui est interrogé, celui qui est à Paris par exemple pour un réseau centré sur Paris. Les serveurs de province utiliseront Rsync pour récupérer le bon certificat.
Anycast sur plusieurs continent : Let's encrypt vérifie de plusieurs point du globe qu'il arrive sur le même serveur en interrogeant le nom de domaine : ce sera un échec systématique : aucun serveur n'arrivera à obtenir le certificat, il est donc inutile de faire du Rsync.
Bonjour,
il doit bien y avoir une solution puisque OVH (qui est sponsor au niveau maximum par contre) arrive à avoir le certificat Lets Encrypt sur le CDN en France et au Canada (par contre seulement 3 POP dans le monde et pas les 19 du CDN complet. (En théorie c'est ce qui est expliqué dans la newsletter, je n'ai pas testé.)
-
Anycast pour un opérateur national : Let's encrypt n'ayant pas de serveur pour vérifier le challenge dans le réseau de l'opérateur, ce sera toujours le même serveur qui est interrogé, celui qui est à Paris par exemple pour un réseau centré sur Paris. Les serveurs de province utiliseront Rsync pour récupérer le bon certificat.
Anycast sur plusieurs continent : Let's encrypt vérifie de plusieurs point du globe qu'il arrive sur le même serveur en interrogeant le nom de domaine : ce sera un échec systématique : aucun serveur n'arrivera à obtenir le certificat, il est donc inutile de faire du Rsync.
Letsencrypt verifie depuis plusieurs serveurs, pas forcèment le plus proche !
Sinon tu sous entends que letsencrypt proposerait plusieurs challenges de plusieurs serveurs différents, sauf que non, seul un serveur est utilisé pour vérifier, la verification depuis de multiples serveurs est prévue mais pas encore en place.
-
De toute manière, dans ce cas, tu utilises le challenge DNS, non ?
-
Certbot (le bot de verif pour LetsEncrypt) utilise l'URI ".well-known" (rfc5785) en mode 'webroot (https://letsencrypt.readthedocs.io/en/latest/using.html#webroot)':
il fait le contrôle en accédant en HTTP a "/.well-known/acme-challenge/..." qui est censé renvoyer les bonnes informations pour la vérification.
Dans le cas d'un anycast tu peux donc 'reverse proxyfier' tout les serveurs des différentes IPs unicast vers un seul serveur pour la verif certbot:
tu ajoute a chacun un truc du genre (code pour Apache:)
ProxyPass /.well-known/acme-challenge/ http://ip/.well-known/acme-challenge/
ProxyPassReverse /.well-known/acme-challenge/ http://ip/.well-known/acme-challenge/
quelque soit le serveur sur lequel le bot va tomber sa requête va être relayé toujours au même serveur en <ip> (sur lequel tourne le certbot) et la réponse revenir proprement aussi. apres tu distrib le certif a tout le monde.
En theorie on peut meme changer de port pendant le reverse proxy (http://ip:8080/.well-known/acme-challenge/) par exemple. ce qui permet d'avoir un serveur http minimum et dédié au certbot (idealement dans un container docker par exemple) sans consommer une IP public avec le port 80.
a tester.
-
a tester.
Je le fais c'est bien pratique pour mettre du HTTPS derrière une s*** en nodejs qui a décidé de gérer tout seul son serveur web (coucou hastebin) :)
-
De toute manière, dans ce cas, tu utilises le challenge DNS, non ?
C'est le plus fiable et le plus simple à mettre en oeuvre.
La méthode de kgersen est techniquement viable aussi, mais je vois déjà d’ici, les bot à la recherche de "/.well-known/acme-challenge/..." apparaître.
-
Ne sachant forcèment pas quel serveur va être interrogé, il faut bien sûr pousser la config sur tous ceux qui sont susceptibles de l'être, ce qui de toute façon va être automatisé, puisque ces serveurs sont censés être substituables les uns aux autres.
La config = ensembles de fichiers du serveur Web y compris contenus statiques et config Apache pour les redirections...
La problématique en anycast, en supposant que tu as des serveurs sur plusieurs continents, c'est que le challenge pour renouveler les certificats va échouer, vu que Let's encrypt vérifie que le serveur est joint depuis plusieurs endroits dans le monde et que un seul échec compromet le certificat.
Je voulais dire qu'un serveur en anycast correctement configuré doit déjà avoir les moyens de fournir un contenu strictement identique depuis partout, y compris ce que tu appelles bizarrement le "challenge" (le témoin, ou cookie).
Si il y a un site en partie dynamique, c'est plus compliqué évidemment! Le problème est ici que ce système risque à lui seul de rendre le site "dynamique".
Il y a deux manière de voir le "challenge" :
- c'est un élèment dynamique
- c'est un élèment statique modifié
Un élèment dynamique est comme un compte courriel, je dois pouvoir accéder via le Webmail depuis le monde entier donc il faut que tous les serveurs frontaux soient capables de trouver le serveur en charge de mon compte.
Un élèment statique est comme la date et la météo d'aujourd'hui, il suffit d'un script pour synchroniser à chaque modification.
Toute personne ayant une infra répliquée doit bien avoir déjà prévu le moyen de synchroniser les modifications de façon efficace, incrèmentale, automatique.
-
Toute personne ayant une infra répliquée doit bien avoir déjà prévu le moyen de synchroniser les modifications de façon efficace, incrèmentale, automatique.
Exactement !