OpenVPN username-as-common-name : pourquoi votre contrôle CN est vide

Vous ajoutez un script client-connect qui rejette toute connexion où common_name diffère de username, et cela ressemble à un lien entre un certificat et un compte. Sur un serveur qui exécute username-as-common-name, cette comparaison a déjà perdu son sens au moment où le script s’exécute. Les deux valeurs sont la même chaîne, donc le test passe pour un certificat délivré à une personne totalement différente.

Le contrôle n’est pas faux parce que le script est mal écrit. Il est faux parce que la valeur qu’il lit a été remplacée plus tôt dans la même connexion.

Ce que la comparaison semble prouver

L’authentification par certificat et l’authentification par mot de passe sont deux preuves distinctes, et un serveur peut exiger les deux sans exiger qu’elles appartiennent à la même personne. L’écart est réel : un certificat d’appareil valide plus n’importe quel compte valide est une affirmation différente de ce certificat plus un compte nommé. Un script qui compare common_name à username se lit comme le chaînon manquant entre les deux. Et il le serait, si common_name signifiait encore ce que disait le certificat.

Que ce soit le cas dépend d’une option du serveur, et cette option est généralement activée pour une raison sans rapport, comme faciliter le nommage des fichiers de configuration par utilisateur.

Ce que username-as-common-name fait au nom

Avec username-as-common-name activé, OpenVPN remplace le nom commun du certificat par le nom d’utilisateur authentifié une fois le nom d’utilisateur et le mot de passe vérifiés. Le crochet de vérification qui s’exécute pendant ce contrôle reçoit toujours le nom commun du certificat, car le remplacement n’a pas encore eu lieu. Tout ce qui suit, y compris client-connect, voit le nom d’utilisateur. L’appel ultérieur reçoit donc une identité deux fois et ne peut pas la comparer au certificat présenté.

Suivez une connexion illustrative : un certificat délivré pour bob-device, une connexion réussie à l’annuaire en tant que alice et l’option activée. L’étape de vérification peut encore voir deux chaînes différentes. L’étape de connexion voit alice et alice.

Cet exemple montre pourquoi la comparaison est vide. Il ne montre pas que la connexion serait autrement acceptée, car la validation du certificat et la vérification du mot de passe s’exécutent toujours de leur côté.

Placez le lien là où les deux identités existent encore

La règle doit être appliquée à une étape qui voit l’identité du certificat et le compte en même temps, ce qui signifie en pratique le crochet de vérification du nom d’utilisateur et du mot de passe ou un greffon chargé à cet endroit. Un greffon pris en charge qui effectue déjà la vérification du mot de passe est généralement le bon endroit pour ajouter une règle d’appariement, car le remplacer par une comparaison de noms supprimerait entièrement le contrôle du mot de passe.

Définissez la correspondance avant d’écrire du code, car l’égalité est rarement la vraie politique. Un certificat identifie souvent un appareil tandis que la connexion identifie une personne, et un appareil peut légitimement servir plusieurs personnes. Stockez la relation sous une forme dont vous contrôlez l’émission, et décidez ce qui se passe lors d’un renommage, d’une réémission et pour les noms qualifiés par domaine. Mettre en minuscules ou retirer un préfixe de domaine sans comprendre l’annuaire peut fusionner deux comptes qui devaient rester distincts.

N’oubliez pas que l’option change aussi la configuration par client qui s’applique, car client-config-dir est indexé par le nom commun.

Testez l’appariement avec deux identifiants valides

Commencez par la paire que votre politique autorise et confirmez qu’elle se connecte. Présentez ensuite le même certificat valide avec un compte différent mais valide par ailleurs : cette tentative doit échouer, et elle doit échouer à cause de la règle d’appariement, non à cause d’un mot de passe mal saisi. Un mot de passe erroné prouve que le contrôle du mot de passe fonctionne et ne dit rien sur la règle entre certificat et compte.

Vérifiez aussi les chemins du certificat absent et du certificat invalide, et confirmez quelle identité le serveur utilise pour les paramètres par client. Si le seul moyen de faire fonctionner la comparaison est de désactiver username-as-common-name, chiffrez d’abord le coût de ce changement, car il ramène la recherche de configuration de chaque client au nom du certificat.