Résumé

  • Le client construit ses identifiants de référence indépendamment des identifiants présentés par le serveur dans son certificat ; sinon, le serveur définirait lui-même la condition de réussite.
  • Une correspondance exacte ne corrige ni une entrée malveillante ni une mauvaise dérivation, et les noms intermédiaires ou cibles SVCB ne remplacent pas spontanément l'identité du service d'origine.

Deux listes et aucun droit à l'autoréférence

La vérification décrite par RFC 9525 met face à face deux ensembles. Le premier appartient au client : les identifiants qu'il jugerait acceptables. Le second arrive avec le certificat feuille : les identifiants que présente le serveur. Le contrôle cherche une correspondance entre eux.

Construire les deux ensembles à partir du certificat rendrait le test circulaire. Un serveur pourrait annoncer un nom puis réussir parce que le client vient d'adopter ce nom comme attente. Le texte exige donc que la liste de référence soit indépendante de ce que le serveur présente.

L'identité de référence vient d'un domaine source, parfois complété par un type de service applicatif. Elle peut prendre la forme d'un DNS-ID, IP-ID, SRV-ID ou URI-ID selon le protocole. La liste n'est pas une collecte opportuniste de toutes les chaînes ressemblant à un nom ; elle traduit une intention préalable dans des types précis.

Quand la recherche réussit, c'est l'identifiant de référence correspondant qui devient l'identité validée du service. L'ordre logique ne s'inverse pas : le certificat répond à l'attente, il ne décide pas de l'attente.

L'adresse d'origine fait partie de la preuve

Un domaine source peut provenir d'une URL saisie, d'une configuration de compte, d'un lien ou d'une autre information interprétée par l'application. Ces canaux ne portent pas la même confiance. Une valeur administrée n'a pas la même provenance qu'un lien reçu dans un message inattendu.

Le document le dit sans détour : si l'entrée est corrompue, un client peut finir par communiquer avec un service inattendu. Le certificat de ce service peut être parfaitement valide. Le calcul a réussi ; l'intention a été détournée avant que le calcul ne commence.

Le protocole ou l'application doit donc définir la dérivation. Il peut limiter les schémas d'URI, imposer une correspondance avec le type de service et exiger que certains domaines soient obtenus dans un contexte authentifié et chiffré. Sans règle observable, personne ne peut expliquer pourquoi tel nom figurait dans la liste acceptable.

La portée du certificat reste nette. Il ne connaît pas la page qui a livré le lien, le réglage approuvé par l'administrateur ni le but que poursuivait la personne. Il vérifie une relation entre deux identifiants, pas l'histoire complète de l'un d'eux.

Un nom découvert n'est pas une nouvelle intention

La résolution d'un service produit souvent d'autres noms. Alias DNS, cible de répartition ou infrastructure d'un prestataire peuvent tous sembler plausibles dans un certificat. RFC 9525 refuse de les promouvoir automatiquement au rang de référence.

Une application peut spécifier une procédure authentifiée qui autorise cette promotion. À défaut, les valeurs intermédiaires ne doivent pas être traitées comme identifiants de référence. La résolution choisit un chemin ; elle n'a pas reçu, par cette seule fonction, le pouvoir de redéfinir le service demandé.

Ce principe permet à une origine d'utiliser une infrastructure portant un autre domaine. Le client se connecte à cette infrastructure, mais le certificat doit satisfaire l'identité d'origine suivant les règles applicables. Vérifier uniquement la cible technique reviendrait à authentifier la route plutôt que la destination sémantique.

SVCB déplace la connexion, pas l'autorité

RFC 9460 formalise cette séparation. AliasMode peut déléguer la conduite opérationnelle d'une ressource ; ServiceMode publie des points de terminaison alternatifs et leurs paramètres. Aucun de ces mécanismes ne change l'origine ni l'autorité utilisée pour sa validation.

Dans HTTPS, le client continue de vérifier le certificat à partir du nom d'origine. SNI et l'autorité HTTP désignent également cette origine, non le TargetName de l'enregistrement. La cible sert à établir la connexion ; elle n'est pas, par défaut, le nom que l'utilisateur voulait authentifier.

L'exploitation devrait donc conserver deux colonnes : identité de service et point de terminaison. Un équilibrage, une reprise ou un changement de prestataire modifie la seconde sans nécessairement toucher la première. Les fusionner rend toute transition suspecte ou, inversement, toute dérive invisible.

Les types et les jokers ont une grammaire

Une ressemblance visuelle ne constitue pas une correspondance. Les noms DNS suivent une comparaison de labels ; les IP exigent l'égalité exacte des octets ; SRV-ID et URI-ID peuvent imposer aussi le type de service. Il est interdit de recomposer un identifiant acceptable avec le domaine d'une entrée et le service d'une autre.

Un joker, quand le protocole l'admet, doit occuper à lui seul le label le plus à gauche et ne correspond qu'à un seul label. Cette limite réduit l'ambiguïté. Elle ne transforme pas le joker en preuve que chaque hôte correspondant est bien administré ou appartient au même opérateur de confiance.

Autoriser plusieurs identifiants de référence augmente encore la surface de raisonnement. Le client gagne en souplesse, mais chaque type accepté doit être cohérent avec les contraintes des autorités de certification et la politique locale. La compatibilité élargit une frontière ; elle ne la sécurise pas automatiquement.

Le nom feuille n'est qu'une partie du dossier

RFC 9525 ne crée ni ne valide la chaîne de certification. Il traite des formes de nom dans le certificat serveur terminal. Expiration, révocation, ancres de confiance, usages de clé et chemin complet exigent leurs propres contrôles. Une correspondance peut réussir tandis que l'ensemble du certificat doit être refusé.

Le résultat ne certifie pas non plus un chemin ou une requête dans une URI, un droit sur une ressource, le comportement du serveur ou l'issue d'une transaction. TLS 1.3 est indépendant des protocoles applicatifs ; ceux-ci restent responsables du déclenchement de TLS et de l'interprétation du matériel d'authentification.

Enfin, un certificat couvrant de nombreux noms relie leurs risques. Si plusieurs serveurs peuvent utiliser la même clé ou le même certificat, le plus faible peut affecter les autres identités couvertes. « Le nom correspond » n'indique pas lequel de ces détenteurs a la meilleure hygiène opérationnelle.

Refuser l'écart, documenter le point de départ

Sans correspondance, un client automatisé devrait interrompre la tentative ; un client piloté par une personne devrait normalement faire de même après avoir signalé l'écart. L'exception immédiate et l'épinglage improvisé demandent une grande prudence.

Même une politique de refus parfaite laisse une question d'audit : quelle entrée a donné naissance à l'identité de référence ? Le dossier utile conserve l'entrée, le domaine source, le type de service, la liste construite, la chaîne de découverte, le point de connexion, l'identifiant présenté qui a correspondu et le résultat indépendant de validation du chemin.

Sources