Inspecter un certificat VPN sans exposer sa clé

Lire les champs publics d'un certificat n'exige jamais d'afficher la clé privée qui lui correspond, et l'outillage nécessaire est livré avec tout système qui termine un VPN. Le risque se situe une étape plus tôt : le fichier qu'on vous a remis n'est peut-être pas un certificat du tout. Un certificat PEM, un blob DER, un paquet PKCS#12 et un profil OpenVPN peuvent arriver sous le même nom et contenir des matières très différentes, alors identifiez le conteneur avant de choisir une commande.

Trois faits décident quelle commande est sûre : ce que contient le fichier, ce que vous devez en lire et qui verra la sortie. Errez sur un seul et l'inspection devient elle-même l'incident.

Lequel des trois fichiers on vous a remis

Un certificat PEM est du texte avec des marqueurs BEGIN et END visibles, un fichier DER est du binaire qui exige un indicateur de format d'entrée, et un paquet est un conteneur qui peut tenir une clé à côté du certificat. file server.crt sépare le texte du binaire en une seconde, et un coup d'œil à la première ligne sépare un certificat nu d'un profil qui en intègre un. C'est deviner ici qui transforme une inspection en incident.

Si le fichier est un profil plutôt qu'un certificat, traitez-le comme un secret jusqu'à preuve du contraire. Cette hypothèse ne coûte rien et évite l'erreur la plus courante de toute cette tâche.

Lire les champs publics d'un certificat PEM

Pour un certificat que vous êtes autorisé à inspecter, la sous-commande x509 avec -noout imprime les champs que vous sélectionnez et rien d'autre. Supprimer le corps est ce qui garde la sortie au niveau des métadonnées, ce qui la rend aussi sûre à coller dans un ticket. Les sélecteurs ci-dessous sont les publics, et la documentation openssl x509 liste les autres.

openssl x509 -in server.crt -noout -subject -issuer -dates -fingerprint -sha256

Sur un certificat de test généré localement, cette commande imprime une ligne subject et issuer, la paire notBefore et notAfter, et une empreinte SHA-256. Ces champs identifient l'objet ; ils n'établissent pas un chemin de confiance valide, ce qui est une tâche de vérification distincte avec sa propre commande et sa propre réponse. Un fichier de chaîne peut aussi n'imprimer que le premier certificat, sauf si vous parcourez le fichier vous-même. Comparer deux fichiers de cette façon coûte une commande et tranche lequel des deux le pair présente réellement.

Les paquets qui tiennent une clé à côté du certificat

Un fichier .p12 ou .pfx peut porter une clé privée, et la commande d'analyse l'imprime sauf si vous supprimez cette partie de la sortie. Avec -nokeys, la même commande rapporte encore la structure du conteneur, y compris un sac de clé enveloppé, sans émettre la moindre matière de clé ; retirez cet indicateur et un bloc de clé apparaît dans votre terminal et dans l'historique de votre shell.

openssl pkcs12 -in bundle.p12 -nokeys -info -passin env:P12PASS

Un profil OpenVPN intègre la même matière sous forme de texte, donc la frontière est visible si vous savez où regarder. La matière publique se trouve entre BEGIN CERTIFICATE et END CERTIFICATE, tandis que tout ce qui est entre BEGIN PRIVATE KEY et sa ligne END correspondante est la clé et ne doit pas quitter l'hôte. Copier le profil tel quel publie les deux.

Obtenir la valeur de référence ailleurs

Une empreinte lue depuis la connexion que vous cherchez à vérifier ne prouve rien, car la partie à laquelle vous ne faites pas confiance l'a fournie. Ce n'est pas un argument contre les empreintes ; c'est un argument sur la provenance. Comparez la valeur à une autre obtenue par un canal où le pair ne peut pas écrire, comme le certificat publié dans un dépôt interne ou le hachage imprimé dans un enregistrement de changement signé.

Là où un magasin de confiance effectue la validation, laissez-le faire, et lisez l'erreur qu'il produit au lieu de substituer votre propre comparaison. La distinction qui compte est qui a fourni la référence, pas quelle fonction de hachage a été utilisée.

Partager le résultat, et que faire après une fuite

Envoyez l'erreur de validation exacte, les dates pertinentes et seulement les détails d'identité dont le destinataire a besoin. Les noms d'hôte internes et les identifiants de compte restent sensibles même sans clé, et un service de collage public est la mauvaise destination pour tout cela. Collez dans le ticket, pas dans un tampon que quelqu'un d'autre partage.

Si de la matière de clé est bien apparue à l'écran ou dans un fichier, traitez-la comme compromise et renouvelez-la au lieu d'espérer que personne n'ait regardé. Notez ensuite le fichier inspecté, la commande utilisée et où la sortie est allée, car c'est cet enregistrement qui transforme une frayeur en procédure. Le renouvellement coûte peu face au prix de supposer que personne n'a gardé de capture d'écran, et le même enregistrement indique au prochain ingénieur quels fichiers ont été touchés. Faites les deux avant la clôture du ticket.