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

Chaque fois que j'essaie de comprendre quoi que ce soit à propos de SSL, j'ai toujours du mal à garder une trace de ce à quoi "clé" et "certificat" font référence. Je crains que beaucoup de gens ne les utilisent pas correctement ou de manière interchangeable. Existe-t-il une différence standard entre une clé et un certificat?

Un certificat contient une clé publique.

Le certificat, en plus de contenir la clé publique, contient des informations supplémentaires telles que l'émetteur, l'utilisation que le certificat est censé utiliser et d'autres types de métadonnées.

Généralement, un certificat est lui-même signé par une autorité de certification utilisant sa clé privée. Ceci vérifie l'authenticité du certificat.

Ces deux images ensemble m'ont tout expliqué:

Source: linuxvoice

Source: infosecinstitute

Disons que la société A a une paire de clés et doit publier sa clé publique pour un usage public (alias ssl sur son site Web).

• La société A doit adresser 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 la société A est incluse dans la demande de certificat.
  
• L'autorité de certification utilise ensuite les informations d'identité de la société 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 envoie un certificat à la société A. En bref, la CA signe la clé publique de la société A avec sa clé privée (de la CA), ce qui en vérifie l'authenticité.
  

Ainsi, la clé publique de la société A signée avec une clé privée d'une autorité de certification valide s'appelle le certificat de la société A.

Laissez-moi vous expliquer avec un exemple.

Dans une infrastructure à clé publique normale basée sur une paire de clés, il existe une clé privée et une clé publique.

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

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

Vous pouvez télécharger ouvrir le fichier de clé privée et le fichier de certificat. Le fichier de certificat contient de nombreuses informations, comme indiqué ci-dessous.

Vous pouvez faire correspondre votre certificat généré (ouverture à l'aide d'un éditeur de texte) et votre clé privée (ouverture à l'aide d'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 certain que ce certificat est fourni par le client ou par l'agent de confiance du client.

Cependant, des problèmes ne se posent que dans les communications à clé privée et à certificat .

Parce que n'importe qui peut générer son propre certificat et sa propre clé privée, une simple poignée de main ne prouve rien sur le serveur, à part 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 d'avoir le client a un ensemble d'un ou plusieurs certificats qu'il fait confiance. Si le certificat n'est pas dans l'ensemble, le serveur ne doit pas être approuvé .

Cette approche simple présente plusieurs inconvénients. Les serveurs doivent pouvoir passer progressivement à des clés plus performantes ("rotation des clés"), qui remplacent la clé publique du certificat par une nouvelle. Malheureusement, l'application client doit maintenant être mise à jour en raison essentiellement d'un changement de configuration du serveur. Cela 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 présente également des problèmes si l'application doit communiquer avec des serveurs arbitraires tels qu'un navigateur Web ou une application de messagerie.

Afin de remédier à ces inconvénients, les serveurs sont généralement configurés avec des certificats d’émetteurs connus, appelés autorités de certification (CA). La plate-forme hôte (client) contient généralement une liste des autorités de certification bien connues sur lesquelles il fait confiance. Semblable à un serveur, une autorité de certification a un certificat et une clé privée. Lors de l'émission d'un certificat pour un serveur, l'autorité de certification signe le certificat de serveur à l'aide de sa clé privée. Le client peut ensuite vérifier que le serveur dispose d'un certificat émis par une autorité de certification connue de la plate-forme.

Cependant, tout en résolvant certains problèmes, l’utilisation des CA 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 de votre choix. Pour remédier à cela, le certificat émis par l'autorité de certification identifie le serveur avec un nom spécifique, tel que gmail.com, ou un ensemble d'hôtes avec des caractères génériques, tel que * .google.com.

L'exemple suivant va rendre ces concepts un peu plus concrets. Dans l'extrait de code ci-dessous, à partir d'une ligne de commande, la commande s_client de l'outil openssl examine les informations de certificat de serveur de Wikipedia. Il spécifie le port 443 car il s'agit du port par défaut pour HTTPS. La commande envoie la sortie de openssl s_client à openssl x509, qui formate les informations sur les certificats conformément à la norme X.509. Spécifiquement, la commande demande le sujet, qui contient les informations sur le 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 constater que le certificat a été émis pour les serveurs correspondant à * .wikipedia.org par l'autorité de certification RapidSSL.

Comme vous pouvez le constater, en raison des informations supplémentaires envoyées par l'autorité de certification aux serveurs, le client peut facilement savoir s'il communique avec son serveur ou non.

Un certificat SSL est obtenu auprès d'une autorité de certification de confiance, qui se porte garante d'une connexion sécurisée du site Web. Les certificats SSL contiennent généralement le logo de l'authentification ainsi que les clés publiques nécessaires pour chiffrer et déchiffrer les données à envoyer à l'ordinateur. Fonctions des clés SSL

Plusieurs clés SSL peuvent être générées au cours d'une session. Elles sont utilisées pour chiffrer et déchiffrer les informations envoyées vers et depuis l'ordinateur. Les clés permettent de vérifier que les informations n'ont pas été modifiées ni falsifiées.

Différence de cycle de vie

Les certificats durent plus longtemps que les clés SSL. Les certificats SSL sont obtenus auprès de l'autorité de certification, qui peut être renouvelée régulièrement par les banques et les entreprises. Les clés SSL ou les clés de session, en revanche, sont générées de manière unique au cours de la session et sont ignorées à la fin de la session.

Lire la suite ici

OK, décomposons cela pour que les non-techniciens 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 contient votre identité. Le certificat a une clé publique et nécessite une clé privée pour l'ouvrir.

Votre coffre-fort nécessite deux clés pour ouvrir aussi, tout comme un certificat.
Avec un coffre-fort, la clé du banquier ressemble à la clé publique, car 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 si vous demandiez un certificat). une fois que vous avez été identifié, vous utilisez votre clé privée avec la clé publique pour ouvrir votre coffre-fort. Cela revient un peu à faire votre demande de certificat, puis à obtenir votre certificat de l'autorité de certification (tant que vous pouvez être identifié (approuvé) et que vous avez la bonne clé).