Aller au contenu

Inspecteur de magasin de clés

Keystore Inspector

Ouvre les paquets PKCS#12, JKS ou PEM et liste les certificats, les chaînes et les algorithmes de clé qu’ils contiennent.

Un `.p12` remis par une équipe d’exploitation est opaque : vous ne pouvez pas voir ce qu’il contient, si la chaîne est complète, ni quand le certificat final expire, sans une ligne de commande et les bonnes options. Ceci ouvre les paquets PKCS#12, JKS et PEM et liste ce qu’il y a dedans.

🔒 Fonctionne entièrement dans votre navigateurkeystorepkcs12certificateinspect

Le certificat est décodé dans cet onglet par le lecteur ASN.1 de cette page. Rien n’est envoyé, et c’est tout l’intérêt : une CSR, une CA interne ou une clé collée par erreur ne devraient jamais partir sur le serveur d’un inconnu pour y être lues.

Déposez un certificat, un lot, une CSR ou une clé publique

PEM ou DER — .pem, .crt, .cer, .der, .csr, ou une ligne d’authorized_keys. Ou collez-le ci-dessous.

Ce que ceci ne fait pas

  • Il ne vérifie pas les signatures. Le « Émis par » ci-dessus est une correspondance de noms, pas une preuve : n’importe qui peut écrire n’importe quel nom d’émetteur dans un certificat qu’il fabrique lui-même.
  • Il ne sait pas à quelles autorités vous faites confiance. Cela vit dans votre système d’exploitation et dans votre navigateur, et une page web ne peut pas le lire.
  • Il ne vérifie pas la révocation. Les adresses OCSP et CRL sont affichées pour que vous puissiez le faire, mais les interroger est une requête réseau que cet outil ne fait délibérément pas.

Pour savoir ce qu’un serveur en fonctionnement sert vraiment — ordre de la chaîne, versions du protocole, expiration — il vous faut une connexion vers lui : le vérificateur SSL est l’outil pour cette question.

Comment s’en servir

  1. Déposez le paquet

    Les fichiers `.p12`/`.pfx`, `.jks` et PEM sont tous lus. Un magasin protégé par mot de passe a besoin de son mot de passe pour ouvrir le matériel de clé ; les parties certificat sont souvent lisibles sans lui.

  2. Vérifiez la chaîne, pas seulement le certificat final

    Chaque certificat est montré avec son sujet, son émetteur, sa validité et son algorithme de clé. Un paquet qui s’installe sur votre machine et échoue sur un serveur, c’est d’ordinaire un certificat intermédiaire manquant.

  3. Confirmez que la clé correspond au certificat

    La clé publique du certificat final et la clé privée du magasin doivent s’accorder. Un désaccord est l’autre raison courante pour laquelle un paquet apparemment valide refuse de servir du trafic.

Questions fréquentes

Le magasin de clés est-il envoyé quelque part ?

Non. Il est analysé dans le navigateur, mot de passe compris. Un magasin contient une clé privée, donc toute autre solution serait indéfendable.

Me dit-il que le certificat est de confiance ?

Non. Il lit ce que dit le fichier. La confiance dépend du magasin de racines de ce qui le validera et de l’état de révocation, et ni l’un ni l’autre n’est dans le fichier. C’est un inspecteur, pas un validateur.

Le mot de passe est refusé alors que je suis sûr qu’il est bon.

Les vieux fichiers JKS et les fichiers PKCS#12 écrits par des outils anciens emploient parfois des algorithmes que les navigateurs modernes n’implémentent pas, et un magasin peut avoir un mot de passe pour le magasin et un autre pour chaque clé. Essayez aussi le mot de passe de la clé.

À alimenter depuis

Ensuite

Ces outils acceptent ce que celui-ci produit : le résultat peut y aller directement.