Pourquoi un domaine personnalisé ne commence pas à router avant que vous ayez prouvé le posséder
Le détournement de sous-domaine (subdomain takeover) est une de ces classes de vulnérabilité qui semble obscure jusqu’à ce qu’on l’ait vue arriver une fois : une équipe pointe status.example.com vers un service tiers, arrête d’utiliser ce service, oublie de retirer l’enregistrement DNS, et des mois plus tard quelqu’un d’autre réclame ce même emplacement de service et contrôle maintenant ce que status.example.com sert — certificat valide inclus, pour quiconque visite. C’est une classe de bug bien documentée précisément parce que le mode de défaillance est si facile à créer par accident et si facile à manquer jusqu’à ce qu’il soit exploité.
Où se trouve vraiment la protection par défaut
Chaque application démarre avec une URL fonctionnelle et certifiée sans rien à configurer : https://<name>.<server-ip>.sslip.io — une astuce DNS gratuite (sslip.io résout selon l’IP intégrée dans le nom d’hôte lui-même) qui n’a besoin d’aucun enregistrement DNS propre, donc rien à mal configurer le premier jour.
Ajouter un vrai domaine personnalisé est là où vit habituellement le risque de détournement, et c’est là que la vérification réelle se produit : en plus de l’enregistrement DNS que vous ajoutez (un enregistrement A vers l’IP du serveur, ou CNAME pour un sous-domaine), un second enregistrement TXT est demandé — _railyard-verify.<domain> → railyard-verify=<token>. Vérifié automatiquement toutes les 30 secondes, ou à la demande avec Check now. Le certificat et le routage ne démarrent pas tant que cet enregistrement TXT n’est pas vraiment trouvé. Quelqu’un qui pointe un domaine qu’il ne contrôle pas vers une application — exactement le mécanisme derrière un détournement — ne dépasse tout simplement jamais « non vérifié », parce qu’il ne peut pas produire un jeton qui ne lui a jamais été donné.
Les états qui rendent ça lisible, pas juste appliqué
Un domaine affiche un de cinq états, et chacun répond honnêtement à une question différente plutôt que d’effondrer tout en un « en attente » générique : unverified (l’enregistrement TXT n’a pas encore été trouvé), pending (propriété confirmée, certificat pas encore émis), live (sert vraiment le trafic), unrouted (vérifié, mais l’application ne s’est pas redéployée depuis — un redéploiement est ce qui le route vraiment), ou misconfigured (l’émission du certificat a échoué, Check now montrant pourquoi). Savoir dans lequel de ces états un domaine se trouve fait la différence entre « c’est probablement correct » et vraiment savoir ce qu’il reste à faire.
Les domaines génériques reçoivent la même vérification, à plus grande échelle
Ajouter *.example.com route chaque sous-domaine vers l’application d’un coup plutôt que d’en ajouter un par un — vraiment utile pour un produit multi-locataire qui donne à chaque client son propre sous-domaine. La vérification de propriété s’adapte avec : elle sonde railyard-check.example.com plutôt que chaque sous-domaine possible, pour que le domaine générique ne puisse pas être réclamé sans contrôler la vraie zone. Par défaut, chaque sous-domaine reçoit son propre certificat à la première visite; ajouter un identifiant DNS obtient plutôt un seul certificat couvrant tout le domaine générique, un compromis entre complexité de configuration et nombre de certificats qui mérite d’être choisi délibérément plutôt que par défaut.
La paire www/domaine nu, gérée ensemble
Cochez Also add the www/bare-domain version et les deux sont ajoutés et vérifiés ensemble, redirigeant vers celui que vous marquez primaire plus tard — un détail qui compte parce que la moitié de cette paire que quelqu’un oublie est habituellement celle qui finit sans surveillance et, éventuellement, celle qu’un détournement cible vraiment.
Référence complète : Domaines et HTTPS.