Un même nom commun, deux certificats : liste blanche ou révocation ?

Réémettre un certificat d’ordinateur portable sous le même nom commun donne l’impression d’un remplacement, et tout le monde suppose que l’ancien est mort. Il ne l’est pas. Le prédécesseur reste un certificat valide signé par la même autorité, et tout contrôle qui admet des clients par leur nom continuera de l’admettre. Ce qui sépare une vérification d’identité d’une vérification d’identifiant, c’est le numéro de série, et c’est là que se situe la correction.

Commencez par la politique de nommage utilisée par le serveur

Deux contrôles sont confondus : admettre un client pour ce qu’il prétend être, et retirer du service un certificat précis. Le premier est un contrôle de nom, le second un contrôle de révocation. Ils répondent à des questions différentes, et un déploiement peut avoir l’un sans l’autre.

Lisez la configuration du serveur et notez quelle source d’identité est en jeu. username-as-common-name fait du nom d’utilisateur authentifié le nom effectif pour les recherches propres au client. Sans cela, c’est le nom commun du sujet du certificat qui est utilisé. Quelle que soit la réponse, notez-la avant de toucher à une liste blanche.

Les deux chemins produisent un ensemble différent de noms autorisés pour le même certificat. Deviner ici signifie modifier le mauvais fichier et conclure que le contrôle ne fonctionne pas.

Vérifiez ce qui admet réellement un client

Un client-config-dir avec un fichier correspondant fournit des options par client ; à lui seul, ce n’est pas une règle d’admission. L’admission par nom exige ccd-exclusive, qui refuse les clients sans fichier correspondant. L’activer sur un déploiement en production déconnecte tous ceux dont le nom n’a pas de fichier, alors comptez les fichiers avant de basculer quoi que ce soit.

grep -nE 'ccd-exclusive|client-config-dir|username-as-common-name' /etc/openvpn/server/server.conf
ls -1 /etc/openvpn/ccd/

Le décompte est le contrôle : comparez la liste du répertoire aux identités que vous attendez.

Confirmez ensuite que chaque nom de fichier correspond exactement à l’identité effective, y compris la casse et les espaces. Un fichier pour office-laptop ne fait rien pour un certificat dont le sujet indique Office-Laptop. Les espaces de fin échappent aussi à une simple liste, et c’est ainsi qu’un fichier qui semble présent reste non lu.

Vérifiez la CRL que charge la passerelle

Une CRL nomme les certificats révoqués par émetteur et numéro de série, ce qui est la granularité qui manque à un contrôle de nom. Deux certificats peuvent partager un nom commun et différer par le numéro de série, et seule une liste au niveau du numéro de série les sépare.

Confirmez le chemin configuré, la date d’émission et le champ de prochaine mise à jour avant de faire confiance au fichier.

openssl crl -in /etc/openvpn/crl.pem -noout -lastupdate -nextupdate
openssl x509 -in office-laptop.crt -noout -serial -subject

Comparez le numéro de série de la CRL au numéro de série du certificat que vous comptez conserver. Cette comparaison est tout le test, et la faire une fois à l’œil vaut mieux que de faire confiance à un script que personne n’a lu. Diffusez la CRL mise à jour par le chemin que la passerelle lit déjà. Une CRL placée dans le mauvais répertoire n’impose rien, et aucun journal client ne le mentionnera.

Remplacez, puis prouvez les deux issues

Émettez le remplacement sous le même nom commun, enregistrez les deux numéros de série, et seulement ensuite révoquez l’ancien. Cet ordre garde une identité fonctionnelle disponible pendant que vous préparez le changement.

Testez d’abord le remplacement : il doit s’authentifier et atteindre tout ce à quoi son nom donne droit. Testez ensuite l’ancien certificat et confirmez qu’il est refusé, car un remplacement réussi ne dit rien de la révocation. Si les deux se connectent encore, l’entrée de révocation n’est pas lue ou l’ancien numéro de série n’a jamais été listé. Si aucun ne se connecte, vous avez cassé la règle d’admission, pas l’identifiant.

Les sessions déjà établies sont une autre affaire, car la révocation s’applique aux nouvelles authentifications, sauf si la passerelle est aussi configurée pour couper les connexions actives. Décidez si une suppression immédiate est requise avant de le promettre à quiconque.

Ce qu’un contrôle de nom ne peut jamais faire

Une liste blanche répond si cette identité peut se connecter. Elle ne peut pas dire quel certificat cette identité a utilisé, et elle admettra un identifiant plus ancien tant que celui-ci reste valide et non révoqué. Cet écart apparaît lors d’un incident, quand le remplacement a été émis il y a des mois et que le prédécesseur fonctionne encore.

Là où un contrôle au niveau du certificat est requis, utilisez un mécanisme qui nomme le certificat : des entrées de CRL, ou un hook de vérification qui contrôle une empreinte maintenue par l’opérateur. Les deux coûtent de la maintenance, et les deux sont honnêtes quant à l’objet qu’ils examinent. Le manuel OpenVPN 2.6 documente crl-verify et l’admission propre à un client comme des options distinctes pour cette raison.

Notez quel contrôle fait quel travail, puis testez le cas négatif. Une révocation que vous n’avez jamais vue refuser une connexion est une configuration dont vous espérez qu’elle fonctionne.