Quelle est la différence entre un certificat et une clé en ce qui concerne SSL ?

Ces deux photos ensemble m'ont tout expliqué :

Quelle: linuxvoice

Quelle: infosecinstitute

Disons que l'entreprise A a un paire de clés et doit publier sa clé publique pour un usage public (aka ssl sur son site web).

• L'entreprise A doit faire une demande de certificat (CR) à une autorité de certification (CA) pour obtenir un certificat pour sa paire de clés.

• La clé publique, mais pas la clé privée, de la paire de clés de l'entreprise A est incluse dans la demande de certificat.

• L'autorité de certification utilise ensuite les informations relatives à l'identité de l'entreprise A pour déterminer si la demande répond aux critères de l'autorité de certification pour l'émission d'un certificat.
  Si l'autorité de certification approuve la demande, elle délivre un certificat à l'entreprise A. En bref, l'autorité de certification signe la clé publique de l'entreprise A avec sa clé privée (l'autorité de certification), ce qui vérifie son authenticité.

Ainsi, la clé publique de l'entreprise A signée avec la clé privée d'une autorité de certification valide est appelée certificat de l'entreprise A.

Laissez-moi vous expliquer avec un exemple.

Dans une ICP normale basée sur une paire de clés, il y a une clé privée et une clé publique.

Dans un système basé sur des certificats, il y a une clé privée et un certificat. Le certificat contient plus d'informations que la clé publique.

Demo (Vous pouvez générer un certificat et une clé privée) : http://www.selfsignedcertificate.com/

Vous pouvez télécharger et ouvrir le fichier de la clé privée et le fichier du certificat, vous voyez que le fichier du certificat contient beaucoup d'informations comme indiqué ci-dessous.

Vous pouvez faire correspondre votre certificat généré (ouverture par un éditeur de texte), et votre clé privée (ouverture par un éditeur de texte) à partir de ce site : https://www.sslshopper.com/certificate-key-matcher.html

Si le certificat correspond à la clé privée du client, le client est sûr que le certificat est donné par le client ou par son agent de confiance (CA).

Cependant, la communication basée uniquement sur les clés privées et les certificats pose des problèmes. .

En effet, n'importe qui peut générer son propre certificat et sa propre clé privée, de sorte qu'une simple poignée de main ne prouve rien sur le serveur, si ce n'est que le serveur connaît la clé privée qui correspond à la clé publique du certificat. Une façon de résoudre ce problème est de faire en sorte que le client ait un ensemble d'un ou plusieurs certificats auxquels il fait confiance. Si le certificat n'est pas dans le jeu, le serveur n'est pas digne de confiance. .

Cette approche simple présente plusieurs inconvénients. Les serveurs devraient être en mesure de passer à des clés plus solides au fil du temps ("rotation des clés"), ce qui remplace la clé publique du certificat par une nouvelle. Malheureusement, l'application client doit maintenant être mise à jour en raison de ce qui est essentiellement un changement de configuration du serveur. Ceci est particulièrement problématique si le serveur n'est pas sous le contrôle du développeur de l'application, par exemple, s'il s'agit d'un service web tiers. Cette approche pose également des problèmes si l'application doit communiquer avec des serveurs arbitraires, comme un navigateur Web ou une application de messagerie.

Pour remédier à ces inconvénients, les serveurs sont généralement configurés avec des certificats d'émetteurs bien connus, appelés autorités de certification (AC). La plate-forme hôte (client) contient généralement une liste d'AC bien connues auxquelles elle fait confiance. Tout comme un serveur, une AC possède un certificat et une clé privée. Lorsqu'elle émet un certificat pour un serveur, l'autorité de certification signe le certificat du serveur en utilisant sa clé privée. Le client peut alors vérifier que le serveur possède un certificat émis par une AC connue de la plate-forme.

Cependant, tout en résolvant certains problèmes, l'utilisation des AC en introduit un autre. Étant donné que l'autorité de certification émet des certificats pour de nombreux serveurs, vous avez toujours besoin d'un moyen de vous assurer que vous parlez au serveur que vous voulez. Pour résoudre ce problème, le certificat émis par l'autorité de certification identifie le serveur soit par un nom spécifique tel que gmail.com, soit par un ensemble d'hôtes génériques tels que *.google.com.

L'exemple suivant rendra ces concepts un peu plus concrets. Dans l'extrait de ligne de commande ci-dessous, la commande s_client de l'outil openssl examine les informations du certificat du serveur de Wikipédia. Elle spécifie le port 443 car c'est le port par défaut pour le HTTPS. La commande envoie la sortie de openssl s_client à openssl x509, qui formate les informations sur les certificats selon le standard X.509. Plus précisément, la commande demande le sujet, qui contient les informations relatives au nom du serveur, et l'émetteur, qui identifie l'autorité de certification.

$ openssl s_client -connect wikipedia.org:443 | openssl x509 -noout -subject -issuer
subject= /serialNumber=sOrr2rKpMVP70Z6E9BT5reY008SJEdYv/C=US/O=*.wikipedia.org/OU=GT03314600/OU=See www.rapidssl.com/resources/cps (c)11/OU=Domain Control Validated - RapidSSL(R)/CN=*.wikipedia.org
issuer= /C=US/O=GeoTrust, Inc./CN=RapidSSL CA

Vous pouvez voir que le certificat a été émis pour les serveurs correspondant à *.wikipedia.org par l'AC RapidSSL.

Comme vous pouvez le constater, grâce à ces informations supplémentaires envoyées par l'AC aux serveurs, le client peut facilement savoir s'il communique ou non avec son serveur.

OK, décomposons cela pour que les personnes non techniques puissent comprendre.

Pensez-y comme ça. Un certificat est comme un coffre-fort dans votre banque. Il contient beaucoup de choses importantes, généralement des choses qui contiennent votre identité. Le certificat possède une clé publique et nécessite une clé privée pour l'ouvrir.

Votre coffre-fort nécessite également deux clés pour l'ouvrir, tout comme un certificat.
Avec un coffre-fort, la clé du banquier est comme la clé publique puisqu'elle reste à la banque et la clé publique reste avec le certificat. Vous avez la clé privée, qui est nécessaire pour "obtenir votre certificat" et, dans l'exemple du coffre-fort, votre clé privée est nécessaire en plus de la clé publique.

Avant de pouvoir ouvrir votre coffre-fort, vous devez d'abord vérifier votre identité (un peu comme une demande de certificat). Une fois que vous avez été identifié, vous utilisez votre clé privée et la clé publique pour ouvrir votre coffre-fort. C'est un peu comme si vous faisiez une demande de certificat et que vous obteniez ensuite votre certificat auprès de l'autorité de certification (à condition que l'on puisse vous identifier (confiance) et que vous ayez la bonne clé).