Pourquoi copier ca.key sur chaque client VPN détruit l’autorité de certification
Le client vérifie le certificat public de l’AC ; il n’a jamais besoin de la clé qui signe. Copier ca.key sur chaque appareil confie le pouvoir d’émission à quiconque en prend une copie.
Quelque part dans les instructions d’installation, un répertoire est copié tel quel sur chaque portable parce que c’était plus simple que de décider quels fichiers y ont leur place. Ce répertoire contient ca.key, et dès qu’il atteint un deuxième appareil, l’autorité de certification cesse d’être une autorité. Chaque détenteur peut désormais émettre des identités auxquelles le reste du réseau fera confiance.
Cette confusion vaut la peine d’être démêlée une fois, car les deux fichiers se ressemblent et font des choses opposées.
Matériel de vérification et matériel de signature
Un client a besoin du certificat public de l’AC pour vérifier que le certificat présenté par un pair a été signé par cette autorité. C’est une tâche de vérification et elle n’exige aucun secret. Signer le certificat d’un pair est une autre tâche, exécutée une seule fois par celui qui exploite l’AC, avec la clé privée qui ne quitte jamais son stockage protégé. Garder ces deux tâches séparées est tout l’intérêt de livrer deux fichiers.
Ainsi, ca.crt appartient au profil et ca.key n’a sa place nulle part à proximité. Les noms de fichiers sont une convention, pas une garantie, et c’est pourquoi le type doit être inspecté plutôt que déduit du nom.
Une architecture avec une AC intermédiaire ou un service d’émission en ligne n’y fait pas exception. C’est la manière habituelle de tenir le pouvoir de signature loin des postes terminaux tout en émettant des certificats d’appareil à grande échelle.
Ce qu’un client doit prouver avec sa propre clé
Chaque appareil reçoit sa propre paire de clés et son propre certificat, signé une fois par l’AC. Le client présente ce certificat et prouve qu’il possède la clé privée correspondante, et le serveur décide de l’accepter ou non. C’est l’identité qui est révoquée lorsqu’un portable est perdu.
Le contraste compte surtout après un vol. Avec des identités par appareil, un client exposé est retiré par révocation ou par suppression du pair, et le reste du parc continue de fonctionner.
Une clé d’autorité divulguée ne peut pas être traitée ainsi. Chaque certificat qu’elle a signé ou aurait pu signer devient suspect, la réponse est donc un remplacement de la confiance et non une révocation unique. C’est un projet, pas un ticket.
| File | Role | Belongs on |
|---|---|---|
ca.crt | Public certificate used to verify signatures | Every client profile |
ca.key | Private key that issues certificates | Protected CA storage only |
| client key pair | Proves one device's identity | That device alone |
Lire un fichier avant de le copier quelque part
Deux commandes vous indiquent quel type d’objet vous tenez sans imprimer aucun secret. La première nomme le sujet et l’indicateur d’AC d’un certificat ; la seconde valide une clé et en indique le type. Exécutez les deux sur les fichiers du paquet que vous êtes sur le point de distribuer. Tout ce qui se valide comme clé privée n’a pas sa place dans un répertoire client.
openssl x509 -in ca.crt -noout -subject -ext basicConstraints openssl pkey -in ca.key -noout -check
Si la seconde commande réussit sur un fichier qui se trouve dans un paquet client, arrêtez-vous et considérez le paquet comme compromis. Une sortie qui dit qu’une clé est valide dit aussi qu’elle est présente, et cette présence est tout le problème.
Remarquez aussi le sens inverse : un profil client contient légitimement la clé privée de ce client. Supprimer toutes les clés que vous trouvez coupe la connexion sans rien améliorer, il faut donc identifier l’objet avant de le retirer.
Contenir une clé déjà distribuée
Ne supposez pas que supprimer la copie locale annule l’exposition. Quiconque a détenu le fichier a pu le copier, et l’hypothèse sûre est qu’il l’a fait. Suivez la procédure d’incident de l’exploitant et remplacez l’ancre de confiance, en réémettant les certificats d’appareil sous une nouvelle AC.
Changez ensuite le conditionnement qui a créé le problème. Envoyez une liste de répertoire avec une liste blanche explicite de fichiers, gardez la clé de l’AC sur une machine qui ne rejoint jamais le parc client, et notez quel système la détient.
Si l’autorité doit émettre souvent, placez la signature derrière un service ou une intermédiaire à périmètre étroit et à durée de validité courte. Ainsi, une erreur future n’expose qu’un sous-ensemble de l’émission et non la racine de confiance de tout le déploiement.