Chaque fois que j'essaie de comprendre quoi que ce soit au sujet du SSL, j'ai toujours du mal à savoir à quoi se réfèrent les termes “clé” et “certificat”. Je crains que beaucoup de gens les utilisent de manière incorrecte ou interchangeable. Y a-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 prévue du certificat et d'autres types de métadonnées.
En général, un certificat est lui-même signé par une autorité de certification (CA) qui utilise la clé privée de la CA. Cela permet de vérifier l'authenticité du certificat.
Ces deux images ensemble m'ont tout expliqué :
Source : linuxvoice
Source : infosecrétariat
Supposons que l'entreprise A possède une paire de clés et qu'elle doit publier sa clé publique pour un usage public (alias ssl sur son site web).
La clé publique de la société A signée avec la clé privée d'une AC valide est donc appelée certificat de la société A.
Permettez-moi de vous expliquer à l'aide d'un exemple.
Dans une ICP 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 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 le fichier de clé privée et le fichier de certificat, vous voyez que le fichier de 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, ce certificat est donné par le client ou donné par l'agent de confiance (CA) du client.
** Cependant, seuls les communications basées sur la clé privée et le certificat posent des problèmes**.
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, 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 dispose d'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.
Il y a plusieurs inconvénients à cette approche simple. Les serveurs devraient pouvoir passer à des clés plus fortes 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. 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 pose également des problèmes si l'application doit parler à des serveurs arbitraires tels qu'un navigateur web ou une application de courrier électronique.
Afin de 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). a 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'AC signe le certificat du serveur à l'aide de 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 CA en introduit un autre. Comme l'autorité de certification émet des certificats pour de nombreux serveurs, vous devez encore trouver un moyen de vous assurer que vous parlez au serveur que vous voulez. Pour y remédier, le certificat délivré par l'autorité de certification identifie le serveur soit par un nom spécifique comme gmail.com, soit par un ensemble d'hôtes avec joker comme *.google.com.
L'exemple suivant rendra ces concepts un peu plus concrets. Dans l'extrait ci-dessous provenant d'une ligne de commande, la commande s_client de l'outil openssl examine les informations du certificat de serveur de Wikipedia. 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 la norme X.509. Plus précisément, 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 voir que le certificat a été émis pour des serveurs correspondant à *.wikipedia.org par l'AC RapidSSL.
Comme vous pouvez le voir, 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.
Un certificat SSL est obtenu auprès d'une autorité de certification de confiance, qui garantit la connexion sécurisée du site web . Les certificats SSL contiennent généralement le logo d'authentification ainsi que les clés publiques nécessaires pour crypter et décrypter les données qui doivent être envoyées à 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 crypter et décrypter les informations envoyées vers et depuis l'ordinateur. Les clés sont utilisées pour vérifier que les informations n'ont pas été modifiées ou altérées.
Différence de cycle de vie
Les certificats ont une durée de vie plus longue 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 clés de session, en revanche, sont générées uniquement pendant la session et sont jetées à la fin de celle-ci. Lire la suite
OK, décomposons cela pour que les personnes non techniques puissent comprendre.
Pensez-y comme ça. Un certificat est comme un coffre-fort à votre banque. Il contient beaucoup de choses importantes, généralement des choses qui contiennent votre identité. Le certificat a une clé publique et a besoin d'une clé privée pour l'ouvrir.
Pour ouvrir votre coffre-fort, il vous faut deux clés, tout comme pour un certificat.
Avec un coffre-fort, la clé du banquier est comme la clé publique puisqu'elle reste à la banque et que 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 également.
Avant de pouvoir effectivement 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 en plus de la clé publique pour ouvrir votre coffre-fort. C'est un peu comme si vous faisiez une demande de certificat, puis que vous obteniez votre certificat auprès de l'autorité de certification (à condition que vous puissiez être identifié (de confiance) et que vous ayez la bonne clé).