OpenVPN verify-x509-name : subject, name et name-prefix

Lisez d’abord le type de correspondance, puis le texte : une verify-x509-name directive peut sembler correcte et pourtant accepter un certificat auquel vous ne vouliez pas faire confiance. Deux lignes au texte attendu identique mais de types différents sont des exigences différentes. Lisez d’abord le type, puis le texte. Traitez la directive comme une condition de plus sur la connexion, non comme la vérification entière.

Ce que l’option affirme réellement

La directive nomme une identité que le certificat de l’autre partie doit porter. Quand la comparaison échoue, OpenVPN interrompt la poignée de main et aucun tunnel ne monte. Tout le reste du profil s’applique toujours : le certificat doit se chaîner à une AC de confiance et le contrôle de rôle doit passer, donc c’est une condition supplémentaire et non un substitut. Un profil qui satisfait l’attente de nom et échoue au contrôle de rôle reste cassé, et le journal le dit généralement.

Elle diffère aussi de la validation du nom d’hôte qu’effectue un navigateur. Le navigateur compare les noms aux noms alternatifs du subject selon les règles de sa pile TLS, tandis qu’OpenVPN compare un seul champ du certificat avec le type que vous avez choisi. C’est pourquoi coller un nom d’hôte de style navigateur dans la directive peut produire une incohérence même quand le certificat couvre réellement le service.

subject : le nom distinctif complet, caractère par caractère

Avec subject, la valeur par défaut quand aucun type n’est écrit, la valeur attendue doit reproduire tout le DN du subject du certificat. L’ordre des champs, les séparateurs, les espaces et l’échappement comptent, car la comparaison porte sur la chaîne telle qu’elle est encodée. Si vous omettez le type, vous avez choisi la plus stricte des trois comparaisons. Il n’y a aucune étape de normalisation pour rattraper une différence cosmétique. Cela vaut la peine d’être su avant le premier renouvellement, pas après.

Cette rigidité est fragile d’un renouvellement à l’autre. Une AC qui réordonne les attributs, insère un champ supplémentaire ou change sa façon d’échapper une valeur produit une nouvelle chaîne pour la même machine, et une directive qui a fonctionné des années commence à échouer à la prochaine émission. Conserver le DN accepté dans le journal des changements transforme le prochain renouvellement en différence. Là où l’opérateur publie un DN complet et en garantit la forme, subject est un choix raisonnable ; ailleurs, un champ plus étroit est plus facile à maintenir exact.

name : un seul champ, généralement le nom commun

Le type name compare un seul champ du subject. Sauf indication contraire du profil, ce champ est le nom commun, et la valeur attendue est exactement ce champ, pas le DN qui l’entoure.

Le piège est que les certificats modernes ne mettent pas toujours le nom du service dans le CN. Beaucoup le portent dans un nom alternatif du subject et laissent le CN vide ou générique, si bien qu’un certificat qu’un navigateur accepte peut échouer à cette comparaison. Inspectez le certificat qui vous a réellement été délivré avant d’écrire l’attente, et confirmez quel champ le profil sélectionne. Un CN vide comparé à un nom est une incohérence, pas un accident de configuration.

name-prefix : large par conception, donc encadrez-le

Une attente de type name-prefix correspond au début du champ sélectionné. C’est pratique pour un schéma de nommage et dangereux pour tout ce qui est partagé.

Avec vpn.example comme attente, tant vpn.example.com que vpn.example.net passeraient, à condition que le reste de la chaîne soit de confiance. L’ampleur est la fonctionnalité, et c’est aussi la partie à justifier par écrit. Un préfixe est raisonnable quand l’AC et le schéma de nommage sont les vôtres, et bien plus faible quand une AC publique émet dans le même motif. Si le schéma a besoin de souplesse, contraintes-le au niveau de l’AC plutôt que d’élargir la vérification du client.

Choisissez le type d’après l’identifiant, puis prouvez-le

Partez à rebours de l’identité que l’opérateur prévoit. S’il publie un DN complet et le maintient stable, subject l’exprime. S’il nomme le service par le nom commun, utilisez name. S’il possède un schéma de nommage et en accepte tout l’espace, name-prefix le dit explicitement.

Les renouvellements sont là où la directive est mise à l’épreuve. Comparez l’identité approuvée au nouveau certificat plutôt qu’à l’ancien fichier, car une nouvelle adresse de point de terminaison n’implique pas une nouvelle identité de certificat. Ne supprimez pas la directive simplement parce qu’une adresse familière répond : l’accessibilité et la partie attendue sont des faits différents, et l’adresse ne prouve qu’une chose : que quelque chose a répondu. Consignez l’erreur exacte et les détails publics du nom dans un rapport nettoyé, car une incohérence de nom peut être montrée sans aucun matériel de clé privée.

Après une correction prise en charge, reconnectez-vous avec toutes les vérifications prévues activées et vérifiez la ressource dont vous avez réellement besoin. Le succès signifie que le serveur prévu a été accepté, non qu’un certificat ait été forcé au passage. Le manuel officiel OpenVPN 2.6 manual documente les trois types et leurs notes de confiance, et c’est la référence à citer quand une interface de fournisseur contredit le profil.