Pourquoi deux certificats OpenVPN peuvent partager une politique CCD

Une CA peut signer deux certificats qui reçoivent la même OpenVPN configuration propre au client, et rien dans l'un ou l'autre certificat n'avertit personne. Les numéros de série diffèrent, les clés diffèrent, et les sujets complets diffèrent aussi dès qu'une unité organisationnelle change. Le serveur résout la politique par client via un seul nom, et ce nom est la seule chose qui doive être unique.

Le serveur résout un nom, pas un numéro de série

Avec la recherche simple de certificat, le serveur prend le nom commun du certificat présenté et cherche une entrée client-config-dir de ce nom. Le numéro de série n'entre jamais dans la recherche. Deux certificats qui diffèrent dans tous les champs sauf le nom commun aboutissent au même fichier, si bien que la seconde connexion hérite de l'adresse fixe et des routes poussées du premier appareil.

Voilà comment un contrôle d'unicité côté CA passe alors que le VPN entre toujours en collision. Les deux contrôles répondent à des questions différentes.

Décidez quel doit être le nom effectif avant de signer quoi que ce soit, et consignez-le à côté de l'appareil ou du compte auquel il appartient. Un registre du nom, du propriétaire, de l'usage et de l'empreinte du certificat couvre la plupart des déploiements. Sans lui, l'archive des certificats est le seul relevé de quel nom appartient à quel appareil, et cette archive ne peut pas distinguer un remplacement autorisé d'un second appareil qui revendique un nom existant. Réservez le nom à l'enrôlement, sous un verrou si deux opérateurs peuvent émettre en même temps.

Quel nom le mappage utilise réellement

La recherche simple de certificat utilise le nom commun. Un serveur configuré pour mapper un nom d'utilisateur authentifié utilise cette valeur à la place, ce qui rend le nom commun du certificat sans importance pour le choix de la politique. Lisez la configuration en cours pour voir quel mappage est en vigueur.

Les deux mappages peuvent être présents en même temps, et le résultat dépend alors de l'ordre dans lequel le serveur les résout. Un mappage par nom d'utilisateur qui retombe sur le nom commun acceptera silencieusement un certificat que le registre n'a jamais approuvé. Écrivez le nom effectif à côté de la commande qui l'a produit, pour que l'opérateur suivant n'ait pas à redécouvrir l'ordre. Tester une connexion par mappage est peu coûteux et tranche la question.

Quoi que produise le mappage, c'est cette valeur qu'il faut réserver. Réserver des noms communs dans la CA alors que le serveur s'appuie sur des noms d'utilisateur réserve la mauvaise chose.

Deux CA peuvent approuver le même nom

Un service VPN peut faire confiance à plus d'une autorité émettrice, et chaque autorité garde sa propre idée des noms pris. Deux CA indépendantes peuvent toutes deux approuver le même nom commun pour des appareils différents, et le serveur accepte les deux certificats sans se plaindre. Inventoriez chaque autorité du paquet de confiance, pas seulement celle depuis laquelle vous émettez habituellement. La panne apparaît la première fois qu'un certificat de la seconde autorité est utilisé.

Le même raisonnement vaut pour une CA qui impose l'unicité du sujet complet plutôt que celle du nom commun.

Deux certificats qui partagent un nom commun mais diffèrent par l'unité organisationnelle ont des sujets différents, si bien que la CA ne signale aucun conflit tandis que le serveur voit un seul nom. Vérifiez le réglage que votre outil d'émission utilise réellement au lieu de supposer une valeur par défaut. La gestion de unique_subject dans la documentation d'openssl ca est le levier pertinent à cet endroit, et les enveloppes autour de cet outil l'exposent généralement plutôt que de le remplacer.

Le renouvellement est une réutilisation réservée, pas une collision

Un renouvellement qui conserve le nom est une réutilisation délibérée, et le registre devrait le dire en termes simples. Consignez l'ancienne empreinte et la nouvelle sous un seul nom afin qu'un relecteur puisse distinguer un remplacement d'une prise de contrôle. L'option duplicate-cn du serveur est sans rapport : elle régit les sessions simultanées, pas l'enrôlement ni les réservations de noms. Décidez combien de temps les deux identifiants peuvent exister et quand l'ancien cesse d'être accepté.

Avant de remettre le remplacement, relisez ce que le certificat contient réellement. La ligne de sujet est le champ que le serveur mappera, quoi que suggère le nom du fichier.

openssl x509 -in device42.crt -noout -subject -serial -issuer

La révocation identifie normalement un certificat sous son émetteur, donc retirer un numéro de série n'affecte pas un remplacement correctement émis par la même autorité. Ce comportement est exactement ce dont un renouvellement propre a besoin, et c'est aussi pourquoi la révocation ne peut pas nettoyer un nom partagé par deux appareils. Validez le nom de politique effectif et l'adresse attribuée sur une connexion de test avant que l'utilisateur voie l'appareil. Puis retirez l'ancien identifiant à dessein et consignez que vous l'avez fait.