Supprimer la phrase secrète d’une clé ou la garder ? La copie que vous créez

Une clé privée chiffrée et une clé non chiffrée contiennent le même matériel de clé. La conversion ne crée pas une nouvelle identité, ne réinitialise pas un compte VPN et n’invalide pas l’ancien fichier. Elle écrit une seconde copie, et cette copie porte un risque au repos différent.

Si l’échange en vaut la peine dépend de l’endroit où vivra le fichier et de qui peut le lire.

Ce que la conversion change réellement

Avant la conversion, la clé est protégée par une phrase secrète fournie par l’opérateur. Après la conversion, elle est protégée par les permissions du système de fichiers et par tout contrôle d’accès qui entoure le fichier. La cryptographie n’a pas changé ; le nombre de choses entre un attaquant et la clé a changé. C’est toute la comparaison.

Un tableau rend la différence concrète.

Aucune des deux formes n’est automatiquement plus sûre. Elles échouent de manières différentes, et une seule de ces manières laisse une entrée de journal.

Quand il vaut mieux garder la phrase secrète

Si un client pris en charge peut demander la phrase secrète ou la récupérer depuis un coffre de secrets approuvé, la conversion n’apporte rien. Vous gardez une copie, une frontière de protection et un fichier de moins à suivre. La plupart des clients VPN qui acceptent les clés PEM savent le faire.

La conversion est aussi le mauvais choix quand une équipe partage la clé. Un fichier non chiffré sur un hôte partagé devient un identifiant que quiconque a accès au shell peut copier.

Quand une copie non chiffrée est justifiée

Certains services ne peuvent pas demander, certains conteneurs montent des secrets en lecture seule, et certains appareils lisent un fichier de clé au démarrage sans chemin interactif. Dans ces cas, une clé non chiffrée dans un répertoire correctement restreint peut être la conception prise en charge. La justification est l’environnement, pas la commodité.

Si vous ne pouvez pas dire qui peut lire le fichier et pourquoi, la réponse est non.

La commande et ses arêtes vives

Pour une clé basée sur un fichier prise en charge par OpenSSL 3.5, la référence pkey documente la suppression de la phrase secrète et une invite interactive lorsque l’entrée est chiffrée et qu’aucune source de mot de passe n’est fournie. La forme minimale est courte, et il est facile de l’exécuter avec négligence.

umask 077
openssl pkey -in protected-key.pem -out new-private-key.pem

Trois arêtes vives. Les E/S du fichier de sortie ne sont pas atomiques, donc un chemin de sortie existant peut être tronqué en pleine écriture. N’utilisez pas le chemin d’entrée comme sortie et n’expérimentez pas sur l’unique copie protégée. Saisissez la phrase secrète à l’invite plutôt que sur la ligne de commande, où elle finit dans l’historique du shell.

Vérifiez le résultat avant de modifier une configuration VPN : openssl pkey -in new-private-key.pem -pubout devrait afficher la même clé publique que celle que vous aviez auparavant.

Ce que la conversion ne fait pas

Elle ne révoque pas la copie chiffrée, qui existe encore là où vous l’avez laissée. Elle ne change ni le mot de passe du compte VPN ni le certificat. Et elle ne répare pas une exposition déjà survenue. Si une clé a fuité, la solution est le remplacement et le retrait côté serveur, pas un changement de format local.

Supprimez délibérément le fichier intermédiaire, et confirmez que le chemin que vous supprimez est celui que vous avez créé.