Invite de clé OpenVPN après OpenSSL 3 : vérifiez le fournisseur

Personne n’a touché au profil, et pourtant le même client réclame désormais une phrase secrète pour la clé privée à chaque démarrage. Quand ce changement survient quelques jours après une mise à niveau de la distribution, la mise à niveau en est la cause probable : OpenSSL 3 a réorganisé sa prise en charge des algorithmes, et une clé que l’ancienne bibliothèque lisait sans difficulté peut devenir illisible sans qu’un seul octet change. Faites les vérifications dans l’ordre, car deux d’entre elles sont identiques si l’on ne regarde que l’invite.

La première question est de savoir si la clé est chiffrée, et la seconde si cette compilation peut la déchiffrer. Les changements de configuration n’ont de sens qu’une fois les deux réponses connues.

Vérifiez si la clé est chiffrée

Lisez la première ligne du fichier, puis laissez la bibliothèque l’analyser, car un nom de fichier ne prouve rien. Un bloc PEM portant la mention ENCRYPTED PRIVATE KEY est du PKCS#8 chiffré, et un bloc RSA PRIVATE KEY plus ancien qui porte Proc-Type: 4,ENCRYPTED est la forme traditionnelle, et les deux attendent une phrase secrète. Un bloc PRIVATE KEY non chiffré ne devrait pas en demander du tout. Lancez l’analyse avec le compte qui possède le fichier, car un problème de permissions produit une erreur différente et bien moins intéressante.

Si la clé n’est vraiment pas chiffrée et que le client demande quand même, cessez de regarder la cryptographie et vérifiez si le profil nomme un fichier askpass que le service peut encore lire.

Vérifiez si cette compilation peut la déchiffrer

OpenSSL 3 a réparti sa prise en charge des algorithmes entre fournisseurs, et un ensemble de chiffrements plus anciens réside désormais dans le fournisseur legacy plutôt que dans celui par défaut. Une clé chiffrée avec l’un de ces chiffrements reste valide, mais une bibliothèque chargée sans le fournisseur legacy ne peut pas la décoder. Chez certains clients, cela se manifeste par une invite qui se répète, chez d’autres par un échec net juste après la phrase secrète.

Analysez la même clé deux fois avec le même binaire : d’abord avec le seul fournisseur par défaut, puis avec legacy et défaut tous deux demandés sur la ligne de commande. Si la seconde tentative réussit là où la première a échoué, le diagnostic repose sur des preuves et non sur le moment de la mise à niveau. Si les deux échouent de façon identique, la phrase secrète est fausse ou le fichier est endommagé, et aucun réglage de fournisseur ne répare l’un ou l’autre.

Vérifiez la correction la plus étroite disponible

Préférez un changement limité au client à un changement à l’échelle du système. Certaines compilations 2.6 acceptent une option de profil qui charge les deux fournisseurs pour le processus de ce démon, alors vérifiez la directive dans le manuel de votre version exacte avant de vous y fier ; modifier le openssl.cnf système à la place touche chaque programme OpenSSL de l’hôte. Le réglage plus étroit est aussi bien plus facile à annuler une fois la clé réencodée.

Ne supprimez pas la phrase secrète pour faire disparaître l’invite. Cela transforme un identifiant protégé en fichier en clair et change discrètement le risque de chaque sauvegarde, copie et paquet d’assistance où il apparaît. La distinction qui compte est entre une clé qui a besoin de sa phrase secrète et une clé que cette bibliothèque ne peut pas décoder.

Vérifiez le contexte du service, puis réencodez

Une fois la clé déverrouillable, chiffrez-la à nouveau avec un algorithme actuel afin que la dépendance disparaisse. Écrivez le nouveau fichier avec un chiffrement moderne, vérifiez qu’il s’analyse, mettez à jour le profil et ne gardez l’ancienne copie que jusqu’à ce qu’une connexion réussisse. Ne placez jamais la phrase secrète sur une ligne de commande, où tout utilisateur local peut la lire dans la liste des processus. Supprimez l’ancien fichier seulement après que le nouveau s’est connecté depuis le compte de service, pas seulement depuis votre shell.

Vérifiez ensuite l’unité qui lance réellement le client. Une clé lisible dans votre shell peut être illisible pour un service exécuté sous un autre compte ou avec un réglage de répertoire personnel durci.

Notez le réglage du fournisseur à côté du profil et conservez le test à deux commandes avec lui. Quand une mise à niveau ultérieure supprime le fournisseur legacy, relancez ce test pour voir si la clé en a encore besoin ou si le profil peut sortir du contournement.

Une invite est un symptôme qui a au moins trois causes, et une seule d’entre elles est une phrase secrète manquante.