Copier un certificat VPN ne copie pas la clé

Le parcours commence dans la liste des certificats du client, où l'entrée affiche un nom, un émetteur et une date d'expiration, et rien d'autre. Exportez-la, importez-la sur le second appareil, et la connexion est refusée parce que le client ne peut pas prouver qu'il possède la clé privée. Le fichier a été copié en entier ; l'erreur est de croire qu'un certificat transporte sa propre clé. Lisez la boîte de dialogue d'export avant de choisir le format, puis inspectez le fichier que vous avez réellement reçu.

Deux clics, deux artefacts très différents.

Lisez la boîte de dialogue d'export, pas le suffixe du fichier

Un export de certificat DER ou PEM contient une clé publique et les déclarations d'identité signées, c'est-à-dire ce dont un serveur a besoin pour vous faire confiance et ce dont un client a besoin pour vérifier un serveur. Un paquet PKCS#12 est un conteneur qui peut contenir un certificat, sa chaîne et la clé privée correspondante, protégé par un mot de passe, bien qu'il puisse aussi être créé sans la clé.

PEM n'est qu'un encodage texte, pas une promesse sur le contenu. Le même suffixe peut décrire un certificat unique ou un fichier contenant plusieurs blocs étiquetés, et les options d'export décident lequel.

La bonne question n'est donc jamais l'extension obtenue, mais les blocs que contient le fichier. Un paquet exporté sans sa clé reste un paquet. Vérifiez le contenu plutôt que la popularité du format.

Inspectez ce que vous avez réellement obtenu

Cherchez les étiquettes avant d'importer quoi que ce soit, puis lisez les champs du certificat pour confirmer quelle identité vous détenez. Exécutez les contrôles sur le fichier qui sera réellement importé. Répétez-les après tout nouvel export, car les options peuvent différer.

grep -E 'BEGIN (CERTIFICATE|PRIVATE KEY|ENCRYPTED PRIVATE KEY)' bundle.pem
openssl x509 -in client.crt -noout -subject -issuer -dates
openssl pkey -in client.key -noout -text | head -5
openssl pkcs12 -info -in client.p12 -noout

Un export ne contenant qu'un bloc de certificat est un objet public et ne peut pas s'authentifier. Un bloc de clé sans certificat vous laisse sans la chaîne que le serveur attend. La sortie d'informations PKCS#12 indique aussi si une clé est présente, ce qui règle la question pour ce format. Elle nomme également l'algorithme et la taille de clé, et échoue complètement quand aucune clé n'est là.

Ne collez jamais un fichier contenant une clé privée dans un fil d'assistance, un gestionnaire de tickets ou une discussion, même lorsqu'il ressemble au certificat que vous partagiez déjà. Les captures d'un panneau de clés méritent la même prudence.

La clé peut résider là où vous ne pouvez pas la copier

Sur les appareils gérés, la clé privée peut se trouver dans le trousseau du système d'exploitation, dans un jeton matériel ou dans une enclave sécurisée, avec une stratégie qui la marque comme non exportable. Le gestionnaire de certificats affiche alors l'objet public tandis que le secret reste en place, et aucune commande d'export ne produira de copie portable. L'enrôlement via la gestion des appareils mobiles fonctionne souvent ainsi par conception.

C'est un contrôle, pas un obstacle à contourner. Reconstruire une clé privée à partir du certificat public est impossible, et tout outil qui prétend le faire fait autre chose.

Enrôlez une nouvelle identité au lieu de copier

La voie prise en charge consiste généralement à enrôler une identité distincte pour le nouvel appareil et révoquer l'ancienne lorsqu'elle est retirée, afin que chaque appareil puisse être retiré indépendamment. Lorsqu'un export avec la clé est réellement approuvé, traitez le fichier obtenu et son mot de passe comme des identifiants : chiffrés au repos, transférés par un canal de confiance et supprimés une fois l'enrôlement terminé.

Vérifiez en vous authentifiant avec l'identité importée, pas en constatant la réussite de l'import. Un client qui accepte un certificat public dans son magasin n'a rien prouvé sur la clé.

Terminez en confirmant que le serveur accepte la nouvelle identité et que l'ancienne se comporte toujours comme la stratégie le prévoit. Le parcours se conclut ainsi par des preuves, et non par un fichier qui semble correct.