Authentification

à, et sont décodées par, un pirate mal intentionné. Il faut être sûr de les envoyer à quelqu’un digne de confiance.

Comment SSL sait-il à qui il parle ? Chaque côté de la connexion a une identité numérique appelée « certificat ». Ce certificat contient une clé cryptographique qui fournit une identification positive. Ainsi, je pourrais avoir sur mon serveur Web un certificat qui l’identifie en tant que www.klements. com. Quand vous vous connectez à moi avec SSL, ce certificat vous est envoyé.

Comment savez-vous que je ne mens pas quand je dis être www.klements.com? C’est une CA (Certificate Authority) qui doit émettre les certificats. La CA signe numériquement le certificat pour vérifier qu’elle s’est livrée à une certaine recherche, qu’elle confirme que je suis vraiment Scott Klement et que je possède réellement www.klements. com. Si vous faites confiance à la CA, vous savez que je suis réellement celui que je dis.

Vous manifestez votre confiance envers une CA en installant son certificat CA sur votre système. Quand vous vous connectez avec SSL à un système prétendant être signé par cette CA, la cryptographie sert à vérifier que la clé du certificat CA a été utilisée pour signer le certificat du serveur du système auquel vous vous êtes connectés.

Imaginez que vous exploitiez un site tel qu’Amazon, auquel des millions de personnes se connectent avec SSL. Pas question pour Amazon de demander à chaque client de télécharger et d’installer son certificat CA sur son navigateur Web. C’est la raison pour laquelle Amazon et d’autres sociétés de même nature qui veulent que tout le monde fasse confiance à leurs serveurs, achètent leurs certificats auprès d’une CA publique. Les certificats CA que les CA publiques utilisent pour signer les certificats, sont distribués avec les navigateurs, lesquels font confiance aux certificats qu’ils ont signés.

Par exemple, VeriSgn et Thawte sont deux des firmes de CA publiques les plus connues. Vous pouvez leur commander un certificat que vous installerez sur votre système. Aussitôt, elles mènent une courte enquête pour s’assurer que vous êtes bien qui vous dites, puis elles créent un certificat à votre intention. Le certificat est signé numériquement d’une manière qui permet la vérification par rapport à leurs certificats CA. Comme les certificats de ces sociétés CA sont distribués avec Internet Explorer, Firefox et Netscape, les applications SSL font confiance aux certificats par défaut.

Quand vous installez le Digital Certificate Manager (DCM – un outil pour gérer les certificats) et que vous l’utilisez pour créer un stockage de certificats *SYSTEM (nous verrons plus loin comment faire cela) sur votre System i, les certificats CA publics sont installés automatiquement et donc vos applications SSL System i approuvent automatiquement VeriSign, Thawte et autres CA publiques par défaut.

D’un autre côté, si je crée ma propre autorité de certificat et si j’émets mes propres certificats, je peux économiser de l’argent – particulièrement si j’ai des centaines de milliers de certificats à émettre. Le seul problème est que mon certificat d’autorité de certificat devrait être installé manuellement dans le navigateur, ou un autre logiciel SSL, de quiconque veut utiliser mes services. C’est parfois une bonne chose. Par exemple, si je mets en place un serveur réservé aux employés de ma société, il serait absurde de payer une CA publique pour émettre un certificat. Je peux créer mes propres certificats pour mon serveur TN5250 puis émettre un certificat séparé pour chaque employé qui veut s’y connecter. J’organise les choses pour que seule ma propre CA soit approuvée pour TN5250. Ainsi, je sais que qui conque se connecte ou utilise mon système est vraiment un employé, parce que seuls les employés ont des certificats signés par ma CA privée.