Deux certificats OpenVPN, un seul nom CCD : ce qui a mal tourné

Deux certificats clients avec des numéros de série différents, des clés différentes et même des sujets complets différents peuvent malgré tout aboutir au même fichier de stratégie, car le serveur ne regarde rien de tout cela. Il lit un nom dans le certificat et ouvre le fichier de configuration client correspondant. Si les deux certificats portent le même nom, le second hérite de la stratégie du premier à l'instant où il se connecte.

La collision se crée à l'inscription et ne se découvre qu'à la connexion, généralement lorsqu'un appareil reçoit une adresse ou un jeu de routes qui appartient à une autre machine. La prévenir suppose de convenir du champ que le serveur mappe, puis de réserver cette valeur avant que quoi que ce soit soit signé.

Vos outils de certificats ne vous avertiront pas, car l'unicité au sein de X.509 et l'unicité d'un nom de stratégie OpenVPN sont des exigences différentes appliquées par des systèmes différents.

Le serveur cherche un nom, pas une empreinte

Avec le mappage habituel fondé sur les certificats, le serveur prend le nom commun du certificat présenté et cherche un fichier de ce nom dans son répertoire de configuration client. Ce fichier peut épingler une adresse statique, pousser des routes ou appliquer des marques de pare-feu par client. La recherche est une correspondance de chaîne avec un nom de fichier, donc la casse, les espaces et la ponctuation comptent tous.

Certains déploiements inversent délibérément le mappage pour qu'un nom d'utilisateur authentifié prenne le pas sur le nom commun, et c'est alors le nom d'utilisateur qui doit être unique. Dans tous les cas, la valeur qui sélectionne la stratégie est celle que vous réservez. Décidez laquelle avant d'émettre quoi que ce soit ; deviner après une collision coûte plus cher que demander.

Là où deux autorités se rejoignent sur un même nom

Une organisation qui accepte des certificats de plus d'une autorité émettrice exploite deux processus d'inscription indépendants qui écrivent dans un même espace de noms. Les règles d'unicité propres à chaque autorité s'appliquent en son sein, si bien que les deux peuvent légitimement émettre pour le même nom commun sans que l'une remarque quoi que ce soit d'anormal.

Les numéros de série n'aident pas. X.509 exige qu'un numéro de série soit unique dans le périmètre de son émetteur, ce qui est une propriété de la comptabilité de cette autorité et non une identité globale de l'appareil. Le contrôle du sujet est aussi un test différent de celui du nom commun : deux certificats peuvent partager un CN tout en différant par l'unité organisationnelle, et donc porter des sujets distincts. Chacune de ces propriétés peut être vérifiée tandis que le serveur mappe malgré tout les deux certificats vers un seul nom de fichier.

La documentation d'OpenSSL CA couvre le réglage unique_subject qui régit l'opinion de sa propre base de données, et le point de départ honnête est de lire votre configuration d'émission plutôt que de supposer qu'un défaut particulier d'EasyRSA ou d'OpenSSL s'applique.

Réservez le nom effectif avant de signer

Tenez un registre qui mappe un appareil à son enregistrement approuvé, puis à un nom de fichier de stratégie exact, afin qu'un nom soit alloué une fois et le reste. La réservation doit être atomique, ce qui en pratique signifie une contrainte de base de données ou un verrou autour de l'étape allouer-puis-signer, pas un tableur que deux personnes éditent.

Faites ensuite du contrôle une partie de l'émission : refusez de signer lorsque le nom demandé existe déjà, et incluez dans ce contrôle chaque autorité à laquelle le serveur fait confiance, car un nom réservé par l'autre autorité est tout aussi pris. Une demande rejetée avec un motif clair coûte moins cher qu'un ticket sur un appareil qui reçoit sans cesse l'adresse statique d'un autre.

Le renouvellement réutilise un nom à dessein

Une réémission pour un appareil existant devrait produire un nouveau numéro de série sous le même nom de stratégie, et c'est une réutilisation légitime et non une collision. Ce qu'il faut décider à l'avance, c'est le chevauchement : si les certificats ancien et nouveau peuvent être valides simultanément, et comment l'ancien justificatif est retiré.

Ne recourez pas à duplicate-cn pour résoudre cela. Cette option du serveur régit les connexions simultanées présentant le même nom ; elle ne verrouille pas l'inscription, et l'activer ne rend pas une adresse statique partagée sûre pour deux machines à la fois. La révocation identifie normalement un certificat par émetteur et numéro de série, de sorte que retirer l'ancien justificatif n'a pas besoin d'invalider son remplacement tant que le serveur reçoit et applique les bonnes données de révocation.

Confirmez le mappage avec les outils de la machine

Avant de remettre à un appareil son nouveau justificatif, lisez le nom dans le certificat comme le fera le serveur, puis comparez-le au fichier de stratégie que vous attendez voir choisi.

openssl x509 -in device42.crt -noout -subject -nameopt sep_multiline
ls -l /etc/openvpn/ccd/device42
grep -n "duplicate-cn" /etc/openvpn/server.conf

La première commande imprime les champs du sujet séparément, ce qui rend immédiatement visible une unité organisationnelle égarée ou un espace doublé. La deuxième confirme qu'un fichier de stratégie existe exactement sous ce nom, et la troisième montre si le serveur est configuré pour autoriser plusieurs sessions sur un même nom. Exécutez les trois sur un certificat neuf avant qu'il ne quitte l'étape d'inscription, tant qu'une erreur coûte encore une signature plutôt qu'un incident. Conservez la sortie avec le ticket pour que la personne suivante voie quel nom le serveur a réellement reçu.

Terminez par une connexion réelle et comparez l'adresse attribuée et les routes poussées au fichier de stratégie, plutôt qu'à ce que vous pensiez écrire. Si deux appareils signalent la même adresse statique, le registre comporte une collision qu'aucune inspection de certificats ne révélera jamais.