Résumé

  • L’extension TLS 1.3 certificate_authorities transporte des noms distinctifs X.501 encodés en DER. Ces noms orientent la sélection d’un certificat ; ils ne transportent ni certificat d’AC, ni clé de confiance, ni chemin validé, ni droit applicatif.
  • Dans ClientHello, elle aide le serveur à choisir sa chaîne. Dans CertificateRequest, elle aide le client à choisir son identité. Une syntaxe commune ne confond pas ces deux sens ni leurs conséquences.
  • Une preuve exploitable sépare la production de la liste, le choix du justificatif, la validation du chemin et l’autorisation de l’identité. Un booléen de correspondance d’AC efface précisément cette séparation.

Le premier refus utile

Le cas le plus révélateur n’est pas une signature invalide. C’est un certificat correctement sélectionné et correctement validé, suivi d’un refus métier. Ce refus démontre que le service a conservé une frontière que l’observabilité avait perdue.

Une chaîne valide établit un lien cryptographique vers un ancrage accepté, sous des contraintes données. Elle ne dit pas que le SAN correspond au bon espace de noms, que le sujet est inscrit dans le bon tenant, ni que son rôle permet de modifier une route, de lire un secret ou de déployer une charge.

Il faut donc poser quatre questions : quelle configuration a produit les noms annoncés ? Parmi quels certificats le pair a-t-il choisi ? Quel ancrage et quelles contraintes le vérificateur a-t-il réellement appliqués ? Quelle règle a transformé l’identité authentifiée en autorisation ou en refus ?

Un nom ne transporte pas son objet

L’IANA attribue la valeur 47 à certificate_authorities. RFC 9846 décrit un vecteur non vide de noms distinctifs encodés en DER. Chaque nom peut désigner un ancrage souhaité ou une AC subordonnée et sert à guider le choix de la chaîne.

Le message ne contient pas pour autant la clé publique de l’AC, ses contraintes, sa politique, ni l’entrée correspondante d’un magasin de confiance. Deux certificats d’AC peuvent porter le même subject avec des clés différentes. Un nom extrait d’un fichier n’atteste même pas, à lui seul, que le certificat source possède les capacités d’une AC.

La validation RFC 5280 travaille sur d’autres objets : ancrage effectivement configuré, signatures, périodes de validité, Basic Constraints, Name Constraints, usages de clés et paramètres de politique. L’ancrage peut être absent de la chaîne transmise, puisqu’il est distribué séparément. Le nom annoncé n’abrège aucun de ces contrôles.

La présence prouve seulement qu’un émetteur a placé ce nom encodé dans ce message. Elle ne garantit pas l’acceptation de toute chaîne émise sous ce nom. L’absence ne prouve pas davantage une défiance générale : une liste peut être réduite, indisponible, limitée à un cas de sélection ou volontairement discrète.

Deux voyages, deux propriétaires

Quand le client envoie la liste dans ClientHello, il renseigne le serveur sur les chaînes serveur qu’il pourrait préférer. Quand le serveur la place dans CertificateRequest, il oriente le choix d’un certificat client. Le producteur et le consommateur changent de côté.

Cette distinction commande aussi la confidentialité. OpenSSL avertit que les noms d’AC provenant du client sont envoyés en clair au serveur. Exporter automatiquement tout un inventaire d’entreprise peut révéler des noms d’organisation et une architecture PKI. Une liste serveur trop large expose elle aussi une structure et gonfle la poignée de main.

L’ancien trusted_ca_keys n’est pas utilisé par TLS 1.3. Sur un ClientHello compatible avec plusieurs versions, des signaux anciens peuvent coexister. La télémétrie doit donc conserver version négociée, message, direction et numéro d’extension.

Le choix est une intersection de contraintes

La correspondance d’un nom d’AC ne suffit jamais. Les algorithmes de signature annoncés, parfois les algorithmes de signature du certificat, le type de clé, la clé privée disponible, Key Usage, EKU, SNI, filtres OID, validité et chaînes locales participent à la décision.

Les candidats écartés sont des preuves, pas du bruit. Un certificat peut correspondre au nom mais échouer sur l’EKU ; un autre peut offrir le bon algorithme sans chaîne vers l’autorité souhaitée ; un troisième peut manquer de clé privée. Conserver seulement l’empreinte du leaf sélectionné rend la décision inexplicable.

Si aucun certificat client ne convient, TLS 1.3 prévoit un message Certificate vide. Le serveur choisit alors de poursuivre selon son profil ou d’émettre certificate_required. Ce résultat explicite vaut mieux qu’une chaîne inventée ou un repli silencieux vers une identité sans rapport.

La liste d’annonce n’est pas le magasin de vérification

OpenSSL sépare les interfaces qui configurent les noms envoyés au pair de celles qui chargent les certificats de confiance. Définir une liste d’AC ne rend pas ces AC fiables. Le magasin de vérification doit être alimenté indépendamment.

Un test simple expose la frontière : annoncer le subject d’une AC sans charger sa clé comme ancrage. Le client peut sélectionner une chaîne correspondante, alors que le serveur répond unknown_ca. L’inverse est également possible : une chaîne localement acceptable peut ne pas figurer dans la liste d’indication.

Ce sont deux générations de configuration. Une recharge à chaud peut modifier la liste sans le magasin, ou le magasin sans la liste. Il faut enregistrer le hachage et l’instant d’activation de chacun, puis rattacher la connexion aux états exécutés.

Le chargeur de noms d’AC client d’OpenSSL renforce la prudence : il extrait des subjects et son entrée n’est pas limitée à des certificats d’AC. La réussite du chargement prouve une lecture, pas l’autorité des objets lus.

Authentifier n’est pas attribuer un rôle

Après réception de la chaîne, le vérificateur évalue le chemin, le but, les contraintes et les règles d’identité du protocole. L’application doit ensuite normaliser le sujet et le relier à un tenant, un compte, une charge, un rôle et une action.

Cette relation peut dépendre d’une forme précise de SAN, d’un couple issuer–subject, d’un OID de politique, d’un registre d’enrôlement ou d’un droit externe. Un certificat valide peut donc être refusé sans aucune anomalie TLS.

Le client ne peut pas non plus conclure, à la seule fin de la poignée de main, que le serveur le considère authentifié pour l’opération demandée. Un résultat applicatif explicite peut être nécessaire. La fin de TLS n’est pas une délégation d’autorité.

Mesurer l’exécution, pas l’existence d’une fonction

OpenSSL, GnuTLS et BoringSSL offrent des rappels de sélection et des fonctions de vérification. Un rappel installé prouve une capacité. Seule une invocation horodatée et liée à une connexion prouve que ce chemin a servi.

BoringSSL limite certains accès aux noms à la durée du rappel de sélection ou de la poignée de main suspendue. Pour une preuve durable, les valeurs DER doivent être copiées ou hachées pendant cette durée. GnuTLS distingue lui aussi le choix du justificatif de la vérification par la liste de confiance.

La reprise PSK déplace encore la frontière. Une reprise TLS 1.3 n’effectue pas nécessairement un nouvel échange CertificateRequest dans la poignée principale. Si aucun rappel n’a été invoqué, les compteurs ne doivent pas annoncer une nouvelle décision de certificat client.

Les essais qui empêchent la promotion du signal

Annoncez un DN sans faire confiance à la clé correspondante. Présentez deux AC au même subject et ne faites confiance qu’à l’une. Ajoutez un certificat dont le nom concorde mais dont l’EKU, la période, la politique ou la clé privée échoue. Vérifiez que chaque rejet garde sa cause.

Faites réussir le chemin, puis refusez le sujet à la frontière du tenant. Retirez tous les justificatifs convenables et observez Certificate vide puis la décision du serveur. Modifiez séparément la liste et le magasin pour vérifier les alertes de dérive.

Capturez une liste ClientHello pour mesurer la divulgation, testez de nombreux DN, reprenez une session sans incrémenter un compteur de nouvelle authentification, et séparez les états configured, invoked, selected, verified et authorized.

L’échelle de preuve devient alors lisible : nom annoncé, candidats, justificatif choisi, possession de clé, chemin validé, identité interprétée, action autorisée. Chaque échelon possède sa propre autorité.

Sources