Appariement de certificats et de clés

Déposez n’importe quel mélange de certificats, de clés privées et de CSR — PEM ou DER — et cet établi prouve quelle clé correspond à quel certificat, ordonne les certificats en une chaîne, convertit les formats et génère des CSR. Les clés privées ne quittent jamais votre navigateur : tout est analysé localement dans cet onglet, les clés sont conservées en mémoire uniquement et ne sont jamais téléversées, journalisées ni stockées, et cette page ne fait aucune requête réseau. Pour décoder un certificat en profondeur, utilisez l’analyseur de certificats SSL ; pour un certificat auto-signé rapide, le générateur de certificats auto-signés.

Ajouter certificats, clés et CSR

Verdict d’appariement

Ajoutez un certificat et une clé privée et le verdict apparaît ici : quelle clé correspond à quel certificat, prouvé par une clé publique identique — jamais deviné d’après les noms de fichiers.

Constructeur de chaînes

Avec deux certificats ou plus chargés, le constructeur les ordonne feuille d’abord, puis le ou les intermédiaires, puis la racine, en appariant les noms d’émetteur et de sujet — et ensuite, là où la cryptographie du navigateur le permet, il vérifie la signature réelle de chaque maillon au lieu de faire confiance aux noms.

Générer un CSR

Une demande de signature de certificat pour une clé générée ici, dans votre navigateur : remplissez le sujet, choisissez le type de clé et téléchargez le CSR à envoyer à votre AC — plus la clé privée, que vous devez conserver en sécurité vous-même. La clé n’est affichée qu’ici ; cette page ne la garde pas.

Comment l’appariement fonctionne réellement

Un certificat et une clé privée ne sont pas deux moitiés d’un même fichier ; ce sont deux fichiers qui partagent un même objet mathématique. Quand une paire de clés est générée, la moitié publique est placée dans le certificat (et dans tout CSR fait à partir de cette clé), tandis que la moitié privée reste dans le fichier de clé. Deux éléments s’apparient exactement quand ils portent la même clé publique — pour RSA, le même module et le même exposant ; pour EC, le même point sur la même courbe. Cette page encode cette clé publique dans son habillage standard (le SubjectPublicKeyInfo), hache l’encodage avec SHA-256 et regroupe chaque élément chargé par ce hachage. Le hachage affiché sur chaque carte est donc la preuve, pas un résumé : des hachages identiques ne peuvent pas arriver par accident, et une non-correspondance est tout aussi certaine, et c’est pourquoi le verdict peut être énoncé sans détour — cette clé correspond à ce certificat, ou aucune clé chargée ne le fait. La panne classique que cela attrape est décrite dans quand votre clé ne correspond pas à votre certificat : le rechargement de 2 heures du matin où le certificat renouvelé sur le disque appartient à une clé différente de celle que le serveur a chargée.

Les noms de fichiers ne prouvent rien. Un répertoire plein de server.crt, server.key, final-v2.pem et d’un CSR de la tentative de renouvellement de l’an dernier est l’état normal d’une infrastructure héritée, et les noms relèvent de l’archéologie, pas de la documentation. Une extension de fichier concordante ou une date concordante ne prouvent rien non plus. Et la vérification traditionnelle d’openssl — comparer le hachage du module du certificat au hachage du module de la clé ? C’est exactement la vérification de cette page, limitée à RSA et à une paire à la fois, et elle passe complètement à côté des clés EC parce que les clés EC n’ont pas de module. L’empreinte de la clé publique couvre tous les algorithmes de manière uniforme, et c’est pourquoi elle est ici la clé de regroupement.

Chaînes, ordre, et ce que « vérifié » signifie

On attend des serveurs qu’ils présentent d’abord le certificat feuille, puis chaque intermédiaire dans l’ordre, afin qu’un client puisse parcourir les maillons d’émetteur à sujet jusqu’à une racine à laquelle il fait déjà confiance. Présenter les mêmes certificats dans le mauvais ordre — ou avec un intermédiaire manquant — produit la classique famille d’erreurs « unable to get local issuer certificate » chez les clients qui ne peuvent pas récupérer eux-mêmes le maillon manquant. Le constructeur ci-dessus reconstruit l’ordre à partir des seuls noms, ce qui est toujours possible, puis va un pas plus loin : pour les signatures RSA et ECDSA, il importe la clé publique de l’émetteur et vérifie la signature sur les octets signés du certificat. Un maillon étiqueté signature vérifiée est prouvé cryptographiquement. Un maillon étiqueté correspondance de nom uniquement ne l’est pas — les noms s’enchaînent, mais la signature utilise un algorithme que cette plateforme ne vérifie pas (RSA-PSS est le cas habituel), et la page le dit au lieu de déguiser une correspondance de nom en preuve. Si une vérification de signature échoue, les noms étaient une coïncidence ou une contrefaçon, et le constructeur affiche l’échec en rouge au lieu de produire un lot en silence.

Formats : PEM, DER et la question du .pfx

PEM, ce sont des octets DER enveloppés en Base64 avec un en-tête étiqueté ; DER est l’encodage brut. Convertir entre les deux ne perd rien et ne prouve rien — c’est le même objet dans une enveloppe différente — et c’est pourquoi chaque carte propose les deux téléchargements. Windows et certains outils Java préfèrent DER ou PKCS#12 ; la plupart des outils Unix veulent PEM. PKCS#12 (.pfx/.p12) est une autre affaire : c’est un conteneur chiffré avec son propre MAC d’intégrité, et en produire un que tous les consommateurs acceptent — avec une protection qui mérite ce nom — n’est pas quelque chose à bricoler dans une page web. Cet outil ne le propose délibérément pas. Pour empaqueter vous-même une paire appariée, exécutez openssl là où vivent les fichiers : openssl pkcs12 -export -inkey key.pem -in cert.pem -certfile chain.pem -out bundle.pfx — après que cette page vous a dit quelle clé, quel certificat et quelle chaîne vont réellement ensemble.

L’analyse et l’enchaînement sont du code DER écrit à la main pour ce site (style BSD, aucun analyseur tiers) ; le hachage, la vérification de signatures et la génération de clés utilisent le WebCrypto du navigateur. Aucune partie de cet outil ne fait de requête réseau.

Questions fréquentes

Comment l’outil d’appariement prouve-t-il qu’une clé et un certificat vont ensemble ?

En comparant la clé publique, pas les fichiers. Chaque certificat, CSR et clé privée produit la même clé publique encodée (le SubjectPublicKeyInfo) ; cette page la hache avec SHA-256 et regroupe les éléments dont les hachages concordent. Une clé publique identique signifie que la clé privée est mathématiquement celle pour laquelle le certificat a été émis — la même vérification qu’openssl effectue avec sa comparaison de modules, faite pour tous les fichiers à la fois et pour les clés EC comme pour RSA.

Est-il sûr de charger une vraie clé privée dans une page web ?

Sur cette page, oui, en raison de sa construction : tout est analysé localement dans votre navigateur, les clés sont conservées uniquement dans la mémoire de cet onglet, rien n’est téléversé, journalisé ni écrit dans un stockage, et la page ne fait aucune requête réseau. L’habitude à garder est de vérifier cette affirmation sur tout outil avant d’y coller une clé — et de ne jamais coller une clé privée dans un chat, un ticket ou un « vérificateur » côté serveur qui la traite à distance.

Que signifie « correspondance de nom uniquement » dans le constructeur de chaînes ?

Le constructeur de chaînes ordonne les certificats en appariant le nom d’émetteur de chaque certificat au nom de sujet du suivant, puis essaie de vérifier la signature réelle avec la clé publique de l’émetteur. Quand l’algorithme de signature est l’un de ceux que le WebCrypto du navigateur peut vérifier (RSA et ECDSA en pratique), le maillon est étiqueté « signature vérifiée » ou, si la vérification échoue, « signature ÉCHOUÉE ». Tout le reste — RSA-PSS est le cas courant — est honnêtement étiqueté « correspondance de nom uniquement » : les noms s’alignent, mais cette page n’a pas prouvé le maillon cryptographiquement.

Pourquoi n’y a-t-il pas d’export PKCS#12 (.pfx) ?

Un fichier PKCS#12 enveloppe une clé et un certificat dans un chiffrement à base de mot de passe avec intégrité MAC — un format qui exige un encodage soigneux et bien testé. Plutôt que de livrer une version bricolée qui pourrait produire des fichiers que d’autres logiciels rejettent (ou, pire, des clés faiblement protégées), cette page convertit entre PEM et DER et laisse l’empaquetage .pfx à openssl : la commande est affichée sur la page pour que vous puissiez l’exécuter là où la clé vit déjà.

Cette page peut-elle lire une clé privée chiffrée ?

Elle peut en identifier une et le dire, mais elle ne peut pas l’utiliser : une clé chiffrée (protégée par mot de passe) ne révèle sa clé publique qu’une fois déchiffrée, et l’appariement se fait sur la clé publique. Déchiffrez une copie localement avec openssl (pkcs8 -topk8 -nocrypt, ou rsa/ec) et chargez la copie déchiffrée — sur une machine à laquelle vous faites confiance, et supprimez la copie ensuite.