Un certificat par appareil ne lie pas la clé à l’appareil

Vous émettez un certificat distinct pour chaque ordinateur portable, donc vous supposez que le VPN peut les distinguer. Il ne peut pas. Un certificat client prouve que celui qui se connecte détient la clé privée correspondante, et un profil copié la détient aussi.

Le certificat par appareil reste une bonne idée. Il fait simplement un autre travail que celui que la plupart des gens attendent.

Ce qu’un certificat client prouve réellement

Pendant la poignée de main, le client signe avec la clé privée qui correspond à son certificat, et le serveur vérifie cette signature auprès de l’AC à laquelle il fait confiance. Rien dans cet échange ne décrit la machine. Tout appareil détenant à la fois le certificat et la clé produit une signature identique, donc un profil copié sur un second ordinateur portable ressemble exactement à l’original. Le certificat nomme une identité ; il ne nomme pas le matériel.

L’unicité par appareil garde son intérêt, car elle rend la révocation précise. C’est une propriété administrative, pas un verrou technique.

Trois niveaux de stockage de la clé

Le premier niveau est un fichier de clé sur le disque. Il est portable par conception, et c’est là que vivent la plupart des profils OpenVPN.

Le deuxième niveau est une clé que le système d’exploitation marque comme non exportable. Windows peut générer une clé d’appareil dans son magasin de certificats et refuser l’exportation ordinaire, ce qui arrête la copie occasionnelle. Elle n’est pas adossée au matériel, et avec assez d’accès à la machine, ces clés peuvent être récupérées, donc elle augmente l’effort au lieu d’élever un mur.

Le troisième niveau est une clé générée à l’intérieur d’un matériel de sécurité : un TPM, une carte à puce, une SIM ou un jeton PIV. Ces modules n’ont pas les circuits pour exporter la clé qu’ils ont générée, et la signature se fait à l’intérieur du module. La clé ne devient jamais un fichier que quiconque peut copier.

Ce tableau, c’est tout l’argument en trois lignes.

Ce qu’easy-rsa peut faire et ce qu’il ne peut pas faire

Émettre des certificats par appareil est simple. Créez un nom commun distinct par appareil auprès de la même AC, par exemple ./easyrsa build-client-full laptop-a nopass, et répétez pour chaque appareil. Notez quel nom commun appartient à quelle personne et à quelle machine.

La révocation est tout aussi directe : ./easyrsa revoke laptop-a, régénérez la CRL avec ./easyrsa gen-crl, et assurez-vous que le serveur la lit réellement via crl-verify.

Ce que l’AC ne peut pas faire, c’est vérifier où la clé privée se trouve ensuite. Si vous générez la clé sur l’hôte de l’AC et la copiez sur l’appareil, vous avez créé une seconde copie lors de l’émission. Une clé non exportable doit être générée sur l’appareil, ou importée dans un matériel qui ne la libérera pas.

Des contrôles qui survivent à un profil copié

Supposez que le profil peut être copié et concevez en conséquence. Liez le compte à un second facteur pour qu’un certificat seul ne suffise pas. Donnez à chaque appareil sa propre politique pour que la portée d’une identité reste limitée. Et surveillez le même nom commun connecté depuis deux adresses à la fois, car c’est à cela que ressemble un profil partagé dans un journal de connexions.

Une révocation rapide et documentée est le contrôle qui fonctionne encore après qu’une copie a eu lieu. Tout le reste est de la prévention.

L’affirmation sur laquelle le serveur peut réellement compter

L’unicité vient de l’AC. La liaison à l’appareil vient du stockage de la clé. Seul un matériel qui ne peut pas exporter sa clé transforme un certificat par appareil en une affirmation que le serveur impose, plutôt qu’en une politique que tout le monde accepte de suivre.