Un ancien P12 échoue sur OpenSSL 3 : mot de passe erroné ou chiffrement obsolète ?

La boîte d'importation prend votre mot de passe, tourne un instant, puis annonce qu'elle ne peut pas lire le paquet. Rien dans ce message ne vous dit si vous avez mal saisi la phrase secrète ou si le fichier a été scellé avec un chiffrement que le client ne fournit plus. Ce sont deux pannes différentes avec deux corrections différentes, et le mauvais choix mène à une rétrogradation du client qui ne fait que reporter la décision. Observer l'étape où le client s'arrête les sépare en une minute environ.

Ce qui se passe entre la boîte de dialogue et la liste des certificats

Un fichier .p12 est un conteneur, pas un certificat. À l'intérieur se trouvent un ou plusieurs sacs de certificats et un sac de clé privée chiffré avec une clé dérivée de votre mot de passe, plus un contrôle d'intégrité appelé MAC sur l'ensemble du fichier. L'ouvrir signifie vérifier ce MAC, déchiffrer le sac de clé et faire correspondre le certificat à la clé qui en sort.

Le problème de mot de passe survient à l'étape du MAC. Le problème de chiffrement survient plus tard, quand il faut déballer le sac de clé et que la version qui s'en charge n'a aucune implémentation de l'algorithme nommé dans le fichier.

Le second cas est courant sur les systèmes actuels parce qu'OpenSSL 3 a déplacé un groupe d'anciens algorithmes vers un fournisseur legacy optionnel. Les paquets exportés par OpenSSL 1.x scellaient généralement les certificats avec RC2 sur 40 bits et la clé privée avec Triple DES à trois clés. Une version par défaut d'OpenSSL 3 vérifie encore le MAC avec votre mot de passe correct, puis échoue sur le sac : le mot de passe n'a donc jamais été faux et le ressaisir ne change rien.

Lisez le conteneur sans écrire de clé sur le disque

Demandez à la version d'OpenSSL de votre propre machine d'analyser le fichier et de lire le point où elle abandonne. Une inspection sans fichier de sortie laisse la clé chiffrée sur le disque, et c'est la seule raison pour laquelle cette étape est sûre sur un hôte partagé.

openssl pkcs12 -in vpn-identity.p12 -info -noout

Sur un paquet legacy avec le bon mot de passe, cela affiche les attributs du sac puis s'arrête sur digital envelope routines::unsupported. Avec un mot de passe erroné, vous obtenez Mac verify error: invalid password? avant qu'aucun sac ne soit lu. Les deux messages pointent dans des directions opposées, et c'est exactement l'information que le client a retenue.

Si la panne est celle de l'algorithme non pris en charge, relancez la même commande en ajoutant -legacy et sans rien changer d'autre. Ce drapeau charge le fournisseur legacy pour ce seul processus. Il ne fait pas analyser les anciens paquets par le client VPN, il ne touche pas à la politique cryptographique du système et c'est une mesure, pas une réparation, car le fichier doit tout de même être remplacé.

Quelle erreur correspond à quelle étape

Un tableau court garde les trois issues séparées, et la formulation compte plus que l'endroit où la boîte de dialogue est apparue.

Un texte comme not enough data ou header too long n'appartient à aucun des deux premiers groupes. C'est un problème de format : un fichier DER renommé en .pem, une copie abîmée par un éditeur qui a réécrit les fins de ligne, ou un téléchargement incomplet. Comparez la somme de contrôle à celle que l'émetteur a envoyée avant de commencer à regarder les chiffrements.

Traitez Mac verify error comme une preuve concernant le mot de passe seulement. Cela signifie que le MAC calculé à partir de ce que vous avez saisi ne correspond pas à la valeur stockée, ce qui arrive avec une faute de frappe, avec un mot de passe mis en cache lors d'une importation précédente ou avec un fichier réexporté sous une autre phrase secrète. Cela ne dit rien sur l'ancienneté des algorithmes à l'intérieur.

Construisez un paquet que le client peut réellement ouvrir

Une fois que l'analyseur legacy a confirmé que le fichier est sain, la correction durable est un remplacement dont les algorithmes sont pris en charge par le client cible : AES-256-CBC pour les sacs de clé et de certificats, PBKDF2 avec SHA-256 pour la dérivation et SHA-256 pour le MAC. Votre administrateur PKI peut l'exporter à partir du même matériel de clé, et le certificat à l'intérieur reste celui auquel vos serveurs font déjà confiance.

Lorsque vous devez convertir localement, demandez à l'outil pkcs12 de resceller les sacs au lieu de les vider d'abord. Gardez les deux phrases secrètes hors de l'historique du shell en les lisant depuis un fichier.

openssl pkcs12 -in vpn-identity.p12 -out vpn-identity-aes.p12 \
  -keypbe AES-256-CBC -certpbe AES-256-CBC -macalg sha256 \
  -passin file:old.pass -passout file:new.pass

Une conversion réussie ne dit rien sur l'expiration, l'usage de la clé, la correspondance de la clé privée ou la confiance du serveur dans la chaîne émettrice. Le réempaquetage est un changement de transport, pas un renouvellement, et chacun de ces points demande encore sa propre vérification.

Écartez toute recette qui écrit une clé intermédiaire non protégée ou un mot de passe de sortie vide simplement parce que le client a ensuite accepté le fichier. Un paquet lisible dont la protection a été retirée est un résultat pire que l'échec d'importation avec lequel vous avez commencé.

Confirmez que le client a importé le fichier que vous avez créé

Une analyse propre dans un terminal prouve que le conteneur est valide. Elle ne prouve pas que le client l'a choisi, car un profil résiduel peut continuer à pointer vers l'ancien fichier, et certains clients mettent en cache une identité importée sous un nom que vous n'avez pas choisi.

Affichez l'identité que vous êtes sur le point d'importer et comparez-la à ce que le client montre dans sa vue des certificats.

openssl pkcs12 -in vpn-identity-aes.p12 -clcerts -nokeys -passin file:new.pass \
  | openssl x509 -noout -subject -dates -fingerprint -sha256

Supprimez d'abord l'entrée de profil obsolète, puis importez. Si le client journalise le sujet ou l'empreinte qu'il a chargés, comparez-les à la ligne ci-dessus ; s'il n'affiche qu'un nom convivial, vérifiez plutôt la date d'expiration, car elle est plus difficile à confondre avec un autre certificat du même émetteur.

La référence PKCS12 liste les options de fournisseur, de phrase secrète et de sortie utilisées ici. L'objectif est de garder le fournisseur legacy hors de l'environnement du client : mesurez avec lui, livrez sans lui et laissez la clé privée protégée sur le disque.