Vérificateur de certificat et de clé privée

Collez le certificat qu’utilise un serveur et la clé privée que vous allez déployer avec lui, et cette page répond à la question sur laquelle échoue un site déployé : les deux viennent-ils de la même paire de clés ? La réponse n’est pas une supposition fondée sur la longueur des modules ou sur les empreintes seules : la page signe un défi fixe avec la clé privée et vérifie cette signature avec la clé publique contenue dans le certificat. Si la vérification réussit, les deux vont ensemble ; si elle échoue, aucune modification de la configuration ne les fera fonctionner. Les deux lectures sont affichées côte à côte avec l’algorithme, la taille de clé, l’identifiant de clé du sujet et l’empreinte de la clé publique, et rien de ce que vous collez ne quitte le navigateur.
1. Certificat ou chaîne
Collez autant de blocs que vous voulez. Chaque certificat est comparé à chaque clé : une chaîne plus une clé vous indique donc exactement à quel certificat de la chaîne appartient cette clé — une surprise fréquente sur un serveur qui présente le mauvais certificat d’un ensemble. Le PEM, le corps base64 nu ou hexadécimal et un fichier PKCS#7 .p7b sont tous lus ; le vérificateur de certificats audite le certificat lui-même une fois la clé établie.
2. Clé privée, ou clé publique
Les clés PKCS#8 (BEGIN PRIVATE KEY), PKCS#1 (BEGIN RSA PRIVATE KEY), SEC1 (BEGIN EC PRIVATE KEY) et une clé publique SPKI nue (BEGIN PUBLIC KEY) sont toutes reconnues, de même qu’un fichier de clé collé en base64 ou en hexadécimal. Une clé PKCS#8 chiffrée (BEGIN ENCRYPTED PRIVATE KEY) ne peut pas être lue par un navigateur : la page le signale, avec la commande qui retire la phrase de passe.
rien n’a encore été vérifié
L’exemple est un certificat auto-signé et la clé privée qui lui appartient, tous deux créés pour cette page et ne protégeant rien. Remplacez la clé par une autre pour obtenir l’autre verdict, ou déposez le bloc de clé publique à la place de la clé privée pour voir la correspondance de la clé publique.
Une clé privée collée dans n’importe quelle page web mérite d’abord une seconde réflexion. Cette page est un seul fichier de JavaScript simple ; elle ne charge rien d’ailleurs et n’émet aucune requête, si bien que la clé est lue, utilisée puis oubliée dans cet onglet. C’est tout de même une promesse faite par du code que vous pouvez lire, et non une garantie venant d’un réseau que vous pourriez observer : si vous manipulez une clé de production, travaillez hors ligne, et sachez que la vérification la plus sûre reste la même commande openssl sur votre propre serveur. Une clé collée ici n’est jamais conservée, jamais placée dans un fichier, et jamais envoyée nulle part — y compris par les boutons d’export, qui écrivent les constats sur la clé et jamais la clé elle-même.
Pourquoi la signature est la réponse. Deux fichiers peuvent se ressembler et ne pas correspondre pour autant : la plupart des guides comparent les clés RSA par leur module, mais cela ne fonctionne que pour le RSA, et une clé peut porter le bon module avec un exposant endommagé ou un mauvais rembourrage. Cette page prouve la paire comme le fait une poignée de main TLS : elle signe un défi fixe avec la clé privée et le vérifie avec la clé publique du certificat — le verdict tient donc pour le RSA, l’ECDSA et l’Ed25519. Lorsque seule la moitié publique est collée, les octets de la clé publique sont comparés à ceux du certificat, tout aussi concluant pour l’identité, mais sans preuve que quelqu’un détient la moitié privée.

Ce qu’une correspondance ne dit pas. Que la clé est bien celle que charge réellement le serveur, que le certificat est approuvé, que le fichier de clé est intact sur le disque, ou que la clé n’a pas été copiée par quelqu’un d’autre. Elle ne peut pas non plus dire si le certificat est celui que recevra un client, car un répartiteur de charge ou un CDN placé devant le site peut en présenter un autre. Pour vérifier ce qu’un serveur en production présente réellement, lancez openssl s_client -connect example.com:443 -servername example.com -showcerts et collez cette sortie dans la zone du certificat.

D’où viennent les fichiers. Le certificat est celui avec lequel votre serveur est configuré, ou celui exporté depuis un navigateur ou extrait d’un ensemble .p7b. La clé privée est le fichier que votre serveur web lit au démarrage, en général quelque chose comme privkey.pem ou server.key. Si votre clé est chiffrée, déchiffrez d’abord une copie avec openssl pkcs8 -topk8 -nocrypt -in key.pem -out key-plain.pem, collez ce fichier, puis supprimez la copie.
Rien n’a encore été vérifié. Collez un certificat et une clé ci-dessus, puis appuyez sur Vérifier s’ils correspondent. Le verdict apparaît ici avec les éléments qui le fondent, et le rapport peut être copié ou enregistré.
La même vérification avec openssl, sur votre propre machine
# clé publique contenue dans le certificat openssl x509 -in cert.pem -noout -pubkey | openssl pkey -pubin -outform DER | openssl sha256 # clé publique contenue dans la clé privée openssl pkey -in key.pem -pubout | openssl pkey -pubin -outform DER | openssl sha256 # les deux condensats ne sont égaux que si la paire va ensemble # l’ancienne méthode, propre au RSA : comparer les modules openssl x509 -in cert.pem -noout -modulus | openssl md5 openssl rsa -in key.pem -noout -modulus | openssl md5
La comparaison des condensats fonctionne pour tous les types de clés et correspond à l’empreinte de la clé publique que cette page affiche, tandis que la comparaison des modules n’existe que pour le RSA. Aucune des deux ne prouve que quelqu’un détient la moitié privée : c’est la vérification par signature ci-dessus qui le fait, et c’est pourquoi cette page l’utilise.
Ce que contient le rapport. Le verdict, les deux lectures dont il est issu (algorithme, taille de clé, courbe, identifiant de clé du sujet et empreinte de la clé publique, pour le certificat et pour la clé), et le test exact qui a été exécuté. Le rapport ne contient jamais la clé privée elle-même : la clé sert à produire une signature et n’est écrite ni dans le texte, ni dans le JSON, ni dans le presse-papiers. Ce que vous copiez ou enregistrez peut être joint à un ticket ; la clé que vous avez collée ne le peut pas, et le presse-papiers est le seul autre endroit où elle a jamais existé.

Confidentialité : le certificat et la clé sont lus dans l’onglet, rien n’est envoyé, et la page n’émet aucune requête — il n’y a ni sonde ni recherche sur cette page. Pour créer une paire correspondante, utilisez le générateur de certificats auto-signés ; pour demander un certificat pour une clé que vous possédez déjà, utilisez le générateur de CSR ; pour lire le contenu d’un certificat, utilisez le décodeur de certificats.