Un certificat est un document envoyé par le destinataire d'une connexion sécurisée, contenant un nom, une clé publique et une signature électronique. Le nom permet de vérifier que l'on parle à la bonne personne ; la clé publique sert à chiffrer les données que l'on va envoyer au destinataire, qui est le possesseur de la clé privée correspondante, de sorte que seul lui pourra les déchiffrer ; et la signature électronique permet de garantir que les deux informations précédentes sont authentiques et dignes de confiance. Ainsi, lorsqu'on utilise un certificat pour sécuriser une connexion, on est certain que seul le destinataire auquel on pense pourra lire les données que l'on envoie, que ce soit effectivement avec lui ou avec un imposteur que l'on parle, et même si des pirates espionnent la connexion : il assure la confidentialité.
Malheureusement, si le principe de base des certificats semble simple, il n'est pas si facile en pratique de vérifier l'authenticité d'une signature électronique, et c'est là qu'interviennent les "certificats racine". En réalité, on peut tenter de distinguer deux sortes de certificats : les certificats servant effectivement à sécuriser une connexion, et les certificats servant à vérifier les signatures des premiers ; ce sont ces derniers qu'on appelle les certificats racine. Sans eux, il n'y a pour ainsi dire pas de sécurité : si un client ne peut pas vérifier la signature d'un certificat, il ne peut pas être sur de l'authenticité du nom et de la clé publique de ce certificat. Il faut donc les connaître avant, et c'est cela qu'on entend par "installer un certificat" : enregistrer un certificat racine, afin de pouvoir s'assurer, par la suite, que d'autres certificats utilisés pour sécuriser les connexions sont authentiques. Installer un certificat racine signifie faire confiance au créateur de ce certificat racine pour que tous les destinataires dont il permet de vérifier les certificats sont bien ceux qu'ils prétendent être, et non des imposteurs.
Dans l'Internet de tous les jours, les certificats racine ont été créés par des autorités indépendantes (comme VeriSign, Thawte, GeoTrust, etc) connues de tous, et leurs certificats racine sont déjà connus de tous (ils sont inclus par défaut dans les navigateurs, voire les systèmes d'exploitation). Or, par simplicité, j'ai fait mon propre certificat racine, parce qu'il y a de nombreuses connexions à sécuriser : celles utilisées par OpenVPN (pour lesquelles chaque client doit avoir un certificat différent), celles de chacun des sous-domaines de traynard.fr, celles pour d'autres services (comme les mails). Il coûte très cher de faire certifier ne serait-ce qu'un seul sous-domaine par une autorité indépendante professionnelle, parce que cela nécessite des vérifications d'identité, et inclut des garanties en cas de piratage ; si c'est clairement adapté à un service commercial, ce ne l'est pas pour moi. Le revers de la médaille, c'est que ce certificat racine n'est connu de personne, à part de mon serveur. Il faut donc que vous l'installiez pour pouvoir vérifier les connexions qui en proviennent ; c'est la seule façon possible pour avoir des connexions sécurisées.
En pratique, si vous essayez d'accéder avec une connexion sécurisée à un site web dont votre navigateur ne peut vérifier l'identité, parce qu'il ne possède pas le bon certificat racine, il va vous prévenir par une page d'erreur plus ou moins intimidante, vous demandant si vous êtes sûr de ce que vous faites. Si vous continuez, il va alors sauter l'étape de vérification de l'identité, mais il chiffrera tout de même la connexion avec la clé publique du certificat. Enfin, pour savoir si l'on utilise une connexion sécurisée ou non à un site web, il faut regarder l'adresse de connexion : si elle commence en http://, la connexion n'est pas sécurisée ; si elle commence en https://, elle l'est.
Dans les réseaux se posent beaucoup de problèmes pour sécuriser les connexions, c'est-à-dire les chiffrer, pour que personne ne puisse espionner les informations transmises, qui peuvent contenir par exemple des mots de passe ou des moyens de paiements. On dispose d'algorithmes de chiffrement efficaces, mais ce sont des algorithmes à chiffrement symétrique, c'est-à-dire que chacun des deux bouts de la connexion doit connaître la même clé secrète, qui permet à la fois de chiffrer et de déchiffrer les données transmises. Le problème de ces algorithmes survient alors quand l'un des deux bouts de la connexion, par exemple le client, doit communiquer à l'autre bout, qui sera le serveur, le secret en question : ce dernier ne peut pas être envoyé sans être protégé lui aussi, ou alors quelqu'un qui surveillerait la connexion découvrirait aussi le secret, et pourrait par la suite déchiffrer toute la communication. Par ailleurs, pour que les algorithmes utilisés restent efficaces, il est bon de changer souvent cette clé secrète (en fait, à chaque connexion) ; donc avoir une méthode sécurisée et relativement efficace pour transmettre ces clés secrètes est une nécessité.
On a alors inventé les algorithmes à chiffrement asymétrique, qui permettent de se passer de clé secrète connue des deux bouts de la connexion ; à la place, chaque participant a une clé publique, utilisée par l'autre pour chiffrer les données qu'il envoie, et une clé privée, confidentielle, servant à déchiffrer les données reçues ; seule la clé privée permet de déchiffrer les données chiffrées avec la clé publique, d'où l'asymétrie. Ces algorithmes étant sensiblement plus compliqués que ceux à chiffrement symétrique, ou s'en sert de méthode pour transmettre la clé secrète partagée au début de la connexion, puis on utilise un chiffrement symétrique de façon complètement sécurisée.
Sauf que ce n'est pas si sécurisé que cela, parce que dans les méandres de l'Internet, il peut se passer beaucoup de choses, et on ne peut pas faire confiance aux intermédiaires. En particulier, il est impossible de savoir, pour aucun des deux interlocuteurs légitimes, si la clé publique reçue est bien la clé publique de l'autre participant : aussi bien, il pourrait y avoir un pirate entre les deux participants, qui intercepterait tous les messages et y répondrait à la place du destinataire légitime, y compris les premiers messages contenant l'échange des clés publiques. En envoyant sa clé publique à chacun des deux participants légitimes, le pirate se fait passer pour le premier participant auprès du second, et pour le second auprès du premier, et peut déchiffrer les messages envoyés par chacun des deux participants. Il peut donc toujours espionner la connexion (c'est juste un peu plus compliqué, mais loin d'être insurmontable).
Le problème posé par l'impossibilité de faire confiance aux intermédiaires de la connexion est assez profond ; il semble en réalité impossible de faire passer des informations de façon totalement confidentielle avec un tel schéma, si aucun des deux participants légitimes n'a de moyen de vérifier l'authenticité des données sensées avoir été envoyées par l'autre. Dans ce cadre, la solution la plus efficace est d'avoir recours à des tiers de confiance, c'est-à-dire des tierces parties qui ont mené au préalable le travail de vérification de l'identité des participants, et qui sont alors capables de certifier que lorsque l'on reçoit la clé publique de quelqu'un, il s'agit bien de la clé publique de la bonne personne. Ainsi, un pirate interceptant les clés publiques et tentant d'envoyer sa propre clé publique à la place se ferait repérer : chacun des deux participants légitimes, allant se renseigner auprès du tiers de confiance pour savoir si la clé publique de l'autre est correcte, se verrait répondre que non. Au passage, vous vous posez peut-être la question de comment les deux participants à la connexion peuvent contacter le tiers de confiance sans que le pirate intercepte ces communications au passage ; la réponse est simple : les clés publiques des tiers de confiance sont déjà connues des participants. Ces tiers s'appellent VeriSign, GeoTrust ou encore Thawte, et ils ont négocié avec Microsoft, Mozilla ou Google pour que leurs systèmes et navigateurs aient déjà une copie de leurs clés publiques ; et de fait, ces acteurs garantissent effectivement que, par exemple, votre navigateur connaisse déjà les clés publiques d'un certain nombre de tiers de confiance.
Ces tiers de confiance publient des certificats, qui sont des documents possédant en gros un nom, une clé publique, et sont signés électroniquement. La signature électronique est une suite de chiffres construite à partir du nom et de la clé publique inclus dans le certificat, et de la clé privée du tiers de confiance (c'est lui qui a signé) ; elle est telle que seul le tiers de confiance a pu la générer (car seul lui connaît sa clé privée), et que n'importe qui connaissant la clé publique du tiers de confiance peut vérifier que la signature est correcte, c'est-à-dire qu'elle correspond bien au nom et à la clé publique du certificat (le procédé n'est pas si mystérieux, il suffit au tiers de confiance de chiffrer le nom et la clé publique à signer avec sa clé privée : n'importe qui peut alors déchiffrer cette signature avec la clé publique du tiers de confiance, et vérifier que le résultat obtenu est bien égal au nom et à la clé publique du certificat. En pratique, c'est un peu plus compliqué, mais l'idée est celle-là). Ainsi, en échangeant des certificats signés et non juste des clés publiques, les deux participants à la conversation peuvent être sûrs de l'identité de l'autre participant : il leur suffit de vérifier que la signature du certificat de l'autre est correcte, ce qu'ils peuvent faire grâce à la clé publique du tiers de confiance. Notons d'ailleurs que finalement, il n'est donc même pas nécessaire de contacter réellement le tiers de confiance pour vérifier une signature.
Une telle organisation suppose bien sûr que le tiers de confiance ne délivre pas de certificat à un pirate lui permettant de se faire passer pour quelqu'un d'autre, donc qu'il vérifie sérieusement et physiquement l'identité des gens dont il va certifier la clé publique. Elle reporte aussi les attaques d'un éventuel pirate sur le tiers de confiance, pour essayer de lui voler sa clé privée. Mais elle s'avère efficace, et c'est celle qui est utilisée sur le net généralement (d'autres méthodes ad-hoc peuvent exister, mais demandent des logiciels spécifiques).
La réponse est assez simple : n'importe qui peut l'être, mais il faut que les autres lui fassent confiance. Ce dernier point n'est pas très évident quand il s'agit de de garantir la sécurité de transactions marchandes à grande échelle, donc il y a de vrais professionnels qui ont pour seule activité d'ˆetre des tiers de confiance ; mais pour l'intranet d'une entreprise ou une communauté plus ou moins fermée, il est assez naturel de désigner un tiers de confiance, qu'on appellera autorité de certification : quelqu'un responsable de signer les certificats des différents membres, ou éventuellement de les distribuer, en s'assurant qu'ils correspondent bien aux bonnes personnes, etc.
Pour exister, l'autorité de certification commence par créer une clé privée qui doit absolument rester secrète et permettra de signer les certificats ; elle inclut la clé publique correspondante dans un certificat appelé certificat racine, et signe ce certificat avec sa propre clé privée (c'est une des caractéristiques d'un certificat racine : il a été signé par la clé privée correspondant à sa propre clé publique). Ensuite, l'autorité de certification distribue ce certificat racine à tous les membres de la communauté ; notons que cette distribution doit se faire de façon sécurisée : les membres n'ont aucun moyen jusque-là de vérifier tous seuls que le certificat racine qu'ils vont recevoir correspond bien à celui créé par l'autorité de certification (il pourrait avoir été créé par quelqu'un d'autre). Cette distribution revient donc à distribuer une clé publique à tout le monde, et tout le monde s'accorde pour faire confiance au possesseur de la clé privée correspondante pour signer et gérer les autres certificats.
Une fois cela en place, lorsqu'un membre veut un certificat, il crée une clé privée et une clé publique, garde la première pour lui et envoie la seconde avec quelques informations sur lui dans une requête de certificat à l'autorité de certification. L'autorité vérifie d'une façon ou d'une autre - pourvu que ce soit sécurisé - l'identité de celui qui a envoyé la requête, ainsi que la correction des informations et de la clé publique envoyées. Puis si tout va bien, il signe et renvoie le certificat, signé, à celui qui a envoyé la requête. Maintenant, n'importe quel autre membre connaissant le certificat racine peut vérifier que la clé publique de ce nouveau certificat est correcte, correspond au bon destinataire, etc. Bref, il peut initier une connexion sécurisée avec le détenteur de ce nouveau certificat, en étant sûr de parler à la bonne personne.
En pratique, dans le web actuel, les certificats servent beaucoup plus à certifier des identités qu'à chiffrer les connexions (elles le font aussi, mais on pourrait le faire autrement). D'ailleurs, pour beaucoup d'usages, par exemple des sites web marchands, il suffit que les serveurs en aient : si tous les clients ont les bons certificats racine, ils peuvent vérifier qu'ils parlent au bon serveur. En revanche, le serveur n'a pas besoin de vérifier qu'il parle au bon client (il aime tous les clients) ; en outre, les clients étant anonymes, il n'y aurait pas de sens à ce que leur identité soit certifiée. Et il est tout à fait possible d'initier une connexion sécurisée et de se trouver une clé secrète commune quand seulement l'une des deux parties possède une clé publique. Notez de toutes les façons que beaucoup de connexions ne sont simplement pas sécurisées, et se passent de certificats d'un côté comme de l'autre. D'ailleurs, pour savoir si l'on utilise une connexion sécurisée ou non à un site web, il faut regarder l'adresse de connexion : si elle commence en http://, la connexion n'est pas sécurisée ; si elle commence en https://, elle l'est.
Dans un cas comme un VPN, en revanche, où le serveur ne veut parler qu'à des clients déterminés, il est tout à fait sensé que les clients aient des certificats ; cela permet de remplacer, en plus sécurisé et plus simple pour les clients, une forme d'authentification qui serait sinon gérée par quelque chose comme un mot de passe.