10. Nom du service et validation TLS

Comprendre le mécanisme

Une chaîne approuvée ne suffit pas si le certificat n’identifie pas le service demandé. La vérification d’identité compare le nom de référence issu du contrat de connexion aux identifiants appropriés du certificat selon les règles applicables, notamment les SAN. Les règles de wildcard sont contraintes ; une simple recherche de sous-chaîne dans le nom n’est pas une validation. Une adresse IP demande également le type d’identifiant correspondant.

Raisonner et vérifier

Ne désactivez pas verify_peer ou la vérification de nom pour résoudre une erreur de certificat. Corrigez le nom, la chaîne ou le magasin de confiance du laboratoire. SNI aide le serveur à sélectionner un certificat mais ne remplace pas la décision du client. Les tests doivent distinguer mauvaise chaîne, mauvais nom et expiration afin de rendre la correction précise.

Référence de destination

Le nom de référence vient de la destination attendue. La vérification doit conserver le contrat du client. Le nom attendu vient de l’URL ou du contrat de connexion maîtrisé par le client. Ne remplacez pas cette attente par le nom que le certificat annonce simplement pour faire réussir la comparaison.

SAN

Les SAN portent des identifiants selon des règles précises. Une comparaison approximative peut accepter un autre service. Les subjectAltName portent des identifiants typés. Appliquez les règles de correspondance du protocole client ; l’affichage convivial du subject ne suffit pas à résumer l’identité utilisable pour la destination.

Adresse IP

Une IP demande l’identifiant de type approprié. La nature de l’identifiant compte. Une connexion attendue vers une adresse IP demande un identifiant IP conforme au profil applicable. Une chaîne DNS contenant des chiffres n’est pas automatiquement équivalente à une identité IP dans un SAN.

SNI et sélection

SNI aide à sélectionner un contexte serveur. La sélection et la vérification sont distinctes. SNI permet au serveur de choisir son contexte et son certificat. Il ne constitue pas la vérification cliente de ce certificat ; les deux étapes ont des responsabilités différentes.

Wildcards limitées

Les wildcards ont une portée contrainte. Les règles ne sont pas une recherche de sous-chaîne. Un certificat générique ne couvre pas arbitrairement tous les sous-domaines et profondeurs. Vérifiez les règles du client et les noms concrets utilisés plutôt que déduire une couverture illimitée du caractère étoile.

Échec fermé

Un mauvais nom doit provoquer un refus. Le pair doit correspondre au service attendu. Le nom api-b ne correspond pas à un certificat qui identifie uniquement api-a. Le bon comportement est un refus, même si l’autorité et les dates du certificat sont valides.

Réparer sans contourner

La correction doit conserver verify_peer et le contrôle de nom. Cela retire précisément la garantie recherchée. Corrigez DNS, URL ou certificat selon la cause puis conservez verify_peer et le contrôle du nom. Une option de désactivation permanente transformerait une erreur visible en faiblesse silencieuse.

Autorité de laboratoire

Un laboratoire peut utiliser une autorité locale maîtrisée. Des clés de test suffisent à vérifier les comportements. Une CA locale maîtrisée permet des tests reproductibles sur des noms de développement. Limitez son périmètre et sa clé privée ; ne l’installez pas partout comme solution universelle aux erreurs de confiance.

Causes distinctes

Une expiration et un mauvais nom sont des causes distinctes. Identifier la cause permet de restaurer le bon contrôle. Testez séparément certificat expiré, autorité inconnue et nom incorrect. Un message générique de connexion échouée ne suffit pas à choisir la bonne réparation ou à démontrer chaque frontière.

Redirection

Une redirection peut demander une nouvelle validation de destination. Chaque connexion doit rejoindre le pair attendu. Une redirection vers une autre destination ouvre une nouvelle connexion et une nouvelle décision de confiance. Réévaluez aussi la politique SSRF et les credentials transmis au lieu de suivre aveuglément la cible.

Atelier guidé : lire, expliquer et vérifier le code

Destination : https://api-b.example.test
Certificat valide, SAN : DNS:api-a.example.test
Vérification de nom : activée

La chaîne du certificat est supposée valide mais son SAN ne désigne pas la destination attendue. Identifiez précisément cette différence puis proposez un certificat ou une URL conforme au contrat. Le fait de désactiver le contrôle de nom ferait disparaître le symptôme en supprimant la garantie recherchée.

La validation du nom complète celle du chemin. Le client ne doit pas réécrire sa confiance vers le nom reçu. Aucun format de corps ne décide de la validation TLS. Le nom attendu n’est pas identifié par ce SAN.

Travail pratique : Présentez au client local un certificat approuvé pour service-a.test alors qu’il demande service-b.test.

Critères de correction : Observez le refus de nom avec une chaîne autrement correcte. Corrigez le certificat ou la destination attendue, puis ajoutez un test de non-régression qui conserve toutes les vérifications.