mozilla
Vos résultats de recherche

    Certificats et authentification

    Cette page vient d'être traduite, mais elle a besoin d'un relecteur différent du traducteur. Pensez également à toujours vérifier le contenu avec sa toute dernière version en anglais.

    Certificat identifiant une personne ou une entité

    Un certificat est un document électronique utilisé pour identifier un individu, un serveur, une entreprise ou toute autre entité et pour associer une clef publique à cette identité. Tout comme un permis de conduire, un passeport, ou tout autre moyen d'identification personnelle couramment utilisé, un certificat fournit généralement une preuve reconnue de l'identité de la personne. La cryptographie à clef publique utilise les certificats pour éviter les problèmes d'usurpation d'identité (voir Problèmes de sécurité sur Internet).

    Pour obtenir un permis de conduire, il faut s'inscrire dans une agence gouvernementale, telle que le Department of Motor Vehicles, qui vérifie votre identité, votre capacité à conduire, votre adresse, et d'autres information avant de délivrer le permis. Pour obtenir une carte d'étudiant, il faut s'adresser à une université ou une école, qui contrôle certaines informations (comme le paiement des frais d'inscription) avant de délivrer la carte d'étudiant. Pour obtenir une carte de bibliothèque, il faut uniquement fournir votre nom et une attestation de logement à vos nom et adresse.

    Les certificats fonctionnent sur les mêmes principes que ces différents documents d'identité. Les autorités de certification (AC ou CA) sont des entités qui valident les identités et émettent les certificats. Elles peuvent être des tierces-parties indépendantes ou des organisations possédant leur propre serveur d'émission de certificats (tel que Red Hat Certificate System). Les méthodes utilisées pour valider une identité varient selon les politiques d'émission d'une AC donnée — tout comme les méthodes de validation des autres formulaires d'identification varient selon les organismes d'émission et leurs domaines d'application. En général, avant d'émettre un certificat, une AC doit utiliser ses procédures de vérification publiées pour un type de certificat afin de s'assurer que l'entité demandant le certificat est bien celle qu'elle prétend être.

    Le certificat émis par l'AC lie une clef publique particulière au nom de l'entité qu'il identifie (tel qu'un nom d'employé ou de serveur). Les certificats aident à prévenir l'utilisation de fausses clefs publiques pour l'usurpation d'identité. Seule la clef publique certifiée dans le certificat fonctionnera avec la clef privée correspondante possédée par l'entité identifiée par le certificat.

    En plus de la clef publique, un certificat contient toujours le nom de l'entité qu'il identifie, une date d'expiration, le nom de son AC émettrice, un numéro de série et d'éventuelles autres informations utiles. Plus important, un certificat contient toujours la signature numérique de l'AC émettrice. La signature numérique de l'AC émettrice permet au certificat de fonctionner comme une lettre d'introduction pour les utilisateurs qui connaissent l'AC et lui font confiance mais qui ne connaissent pas l'entité identifiée par le certificat.

    Pour plus d'informations concernant le rôle des autorités de certification (AC), voir « Comment les certificats d'AC sont utilisés pour établir une relation de confiance ».

    L'authentification confirme une identité

    L'authentification est le processus de confirmation d'une identité. Dans le contexte d'interactions entre les réseaux, l'authentification comporte l'identification confiante d'une partie par une autre. L'authentification sur les réseaux pour avoir plusieurs formes. Les certificats sont un moyen d'authentification.

    Les interactions entre les réseaux se font généralement entre un client, tel que le navigateur d'un ordinateur personnel, et un serveur, tel que le matériel et le logiciel hébergeant un site Web. L'authentification cliente se réfère à l'identification confiante d'un client par un serveur (c'est-à-dire, l'identification de la personne supposée utiliser le logiciel client). L'authentification serveur se réfère à l'identification confiante d'un serveur par le client (c'est-à-dire, l'identification de l'organisation supposée être responsable du serveur à une adresse réseau particulière).

    Les authentifications cliente et serveur ne sont pas les seules formes d'authentification permises par les certificats. Par exemple, la signature numérique d'un courriel combinée au certificat identifiant l'expéditeur fournissent une forte preuve que la personne identifiée par le certificat a bien envoyé le message. De même, une signature numérique dans un formulaire HTML combinée à un certificat identifiant le signataire peut fournir une preuve, après coup, que la personne identifiée par le certificat est d'accord avec le contenu du formulaire. En plus de l'authentification, la signature numérique assure, dans les deux cas, un degré de non répudiation (c'est-à-dire que la signature numérique rend difficile la négation ultérieure par le signataire des informations présentes dans le message électronique ou le formulaire).

    L'authentification cliente est un élément essentiel de la sécurité réseau, sur les intranets ou les extranets. Les sections qui suivent présentes deux formes d'authentification cliente :

    • Authentification basée sur un mot de passe : Presque tous les serveurs permettent l'authentification cliente à l'aide d'un nom, ou pseudonyme, et d'un mot de passe. Par exemple, un serveur pour demander à un utilisateur de fournir un nom et un mot de passe avant de donner des droits d'accès à certaines parties du serveur. Le serveur maintient une liste des noms et des mots de passe ; si un nom particulier est dans cette liste, et que l'utilisateur fournit le bon mot de passe, le serveur donne des droit d'accès.
    • Authentification basée sur un certificat : L'authentification basée sur les certificats est une étape du protocole SSL. Le client signe numériquement des données générées aléatoirement et envoie à la fois ces données signées et le certificat sur le réseau. Le serveur utilise les techniques de cryptographie à clef publique pour valider la signature et confirmer la validité du certificat.

    L'authentification par mot de passe

    La figure 4 montre les étapes basiques mise en œuvre dans l'authentification d'un client à l'aide d'un nom et d'un mot de passe. Cette figure suppose que :

    • L'utilisateur a déjà décidé de faire confiance au serveur, sans authentification ou sur la base d'une authentification de serveur via SSL.
    • L'utilisateur a demandé une ressource contrôlée par le serveur.
    • Le serveur demande une authentification client avant de donner les droits d'accès aux ressources demandées.

    Figure 4. Utilisation d'un mot de passe pour authentifier un client auprès d'un serveur

    Voici les étapes décrites dans la figure 4 :

    1. En réponse à une demande d'authentification de la part du serveur, le client affiche une boîte de dialogue demandant le nom de l'utilisateur et son mot de passe pour accéder à ce serveur. L'utilisateur doit fournir séparément un nom et un mot de passe pour chaque nouveau serveur qu'il désire utiliser pendant sa session de travail.
    2. Le client envoie le nom et le mot de passe par le réseau, en clair ou par une connexion SSL chiffrée.
    3. Le serveur vérifie le nom et le mot de passe dans sa base de données locale et, s'ils correspondent, il les accepte comme preuves authentifiant l'identité de l'utilisateur.
    4. Le serveur détermine si l'utilisateur est autorisé à accéder aux ressources demandées, et si oui, autorise le client à y accéder.

    Avec cet arrangement, l'utilisateur doit fournir un mot de passe pour chaque serveur, et l'administrateur doit conserver les noms et les mots de passe de chaque utilisateur, généralement sur des serveurs distincts.

    Une implémentation propre ne mémorise pas les mots de passe en texte simple. À la place, il concatène le mot de passe avec une valeur aléatoire propre à chaque utilisateur (également appelée « salt ») et mémorise la valeur hachée du résultat avec le « salt ». Ceci rend plus difficile des attaques de force brute.

    Comme expliqué dans la section suivante, un des avantages de l'authentification par certificat est qu'elle peut être utilisée pour remplacer les trois premières étapes décrites à la figure 4 avec un mécanisme qui permet à l'utilisateur de fournir un seul mot de passe (qui n'est pas transmis à travers le réseau) et permet à l'administrateur de centraliser le contrôle de l'authentification des utilisateurs.

    L'authentification par certificat

    La figure 5 décrit le fonctionnement d'une authentification client à l'aide des certificats et du protocole SSL. Pour authentifier un utilisateur auprès d'un serveur, Le client signe numériquement des données générées aléatoirement et envoie à la fois ces données signées et le certificat sur le réseau. Pour les besoins de cette discussion, la signature numérique associée aux données signées peut être considérée comme une preuve fournie par le client au serveur. Le serveur authentifie l'identité de l'utilisateur en se basant sur la force de cette preuve.

    Comme pour la figure 4, la figure 5 suppose que l'utilisateur a déjà décidé de faire confiance dans le serveur et qu'il a demandé une ressource, et que le serveur a demandé une authentification client lors du processus d'évaluation des droits à accéder à la ressource demandée.

    Figure 5. Utilisation d'une authentification par certificat d'un client auprès d'un serveur

    Contrairement au processus décrit à la figure 4, celui de la figure 5 nécessite d'utiliser SSL. La figure 5 suppose également que le client possède un certificat valide qui peut être utilisé pour l'identifier auprès du serveur. L'authentification par certificat est généralement considérée comme préférable à l'authentification par mot de passe car elle est basée sur ce que l'utilisateur a (la clef privée) aussi bien que sur ce que l'utilisateur sait (le mot de passe qui protège cette clef privée). Cependant, il est important de remarquer que ces deux affirmations ne sont vraies que si aucune personne non autorisée n'a accès à l'ordinateur de l'utilisateur ou a son mot de passe, si le mot de passe de la base de données des clefs privées du logiciel client a été défini, et si le logiciel est paramétré pour demander le mot de passe à intervalles raisonnablement fréquents.

    Ni l'authentification par mot de passe, ni l'authentification par certificat ne répondent aux questions de sécurité soulevées par l'accès physique à l'ordinateur d'un individu ou à ses mots de passe. La cryptographie à clef publique peut uniquement vérifier qu'une clef privée utilisée pour signer des données, correspond à la clef publique présente dans un certificat. Il est de la responsabilité de l'utilisateur de protéger physiquement son ordinateur et de conserver secret le mot de passe de sa clef privée.

    Voici les étapes décrites dans la figure 5 :

    1. Le logiciel client, tel que le navigateur, maintient une base de données des clefs privées correspondantes aux clefs publiques publiées avec tous les certificats émis pour ce client. Le client demande le mot de passe de cette base de données la première fois qu'il a besoin d'y accéder lors d'une session donnée — par exemple, la première fois que l'utilisateur essaie d'accéder à un serveur SSL qui requiert une authentification par certificat. Après avoir renseigné une première fois ce mot de passe, l'utilisateur n'en a plus besoin pour la durée de la session, même en accédant à d'autres serveurs SSL.
    2. Le client débloque la base de données des clefs privées, récupère la clef privée du certificat de l'utilisateur et utilise cette clef privée pour signer numériquement des données générées aléatoirement dans ce but en se basant sur des entrées du client et du serveur. Ces données et la signature numérique constituent une « preuve » de la validité de la clef privée. La signature numérique peut uniquement être créée avec la clef privée et peut être validée par la clef privée associée aux données signées, ce qui est réservé à la session SSL.
    3. Le client envoie le certificat de l'utilisateur et la preuve (les données générées aléatoirement signées numériquement) par le réseau.
    4. Le serveur utilise le certificat et la preuve pour authentifier l'identité de l'utilisateur (pour plus de détails sur ce fonctionnement, voir « Introduction à SSL »).
    5. À ce moment, le serveur peut éventuellement exécuter des tâches d'authentification supplémentaires, comme vérifier si le certificat présenté par le client est stocké dans l'entrée de l'utilisateur d'un annuaire LDAP. Le serveur continue alors à évaluer si l'utilisateur identifié est autorisé ou non à accéder à la ressource demandée. Ce processus d'évaluation peut employer une variété de mécanismes standards d'autorisation, en utilisant éventuellement des informations présentes dans un annuaire LDAP, des bases de données d'entreprises, etc. Si le résultat de l'évaluation est positif, le serveur autorise le client à accéder à la ressource demandée.

    Comme on peut le voir en comparant les figures 4 et 5, les certificats remplacent la portion de l'authentification correspondant à l'interaction entre le client et le serveur. Plutôt que de demander à l'utilisateur d'envoyer des mots de passe par le réseau à longueur de journée, l'ouverture de session unique demande une seule fois à l'utilisateur de saisir son mot de passe de base de données de clefs privée, sans l'envoyer par le réseau. Pour la suite de la session, le client présente le certificat de l'utilisateur pour authentifier l'utilisateur auprès de chaque serveur auquel il se connecte. Les mécanismes d'autorisation existants basés sur l'authentification de l'identité du l'utilisateur ne sont pas concernés.

    Comment utiliser les certificats

    Types de certificats

    Cinq types de certificats sont couramment utilisé avec les produits Red Hat :

    • Certificats de client SSL : Utilisés pour identifier des client auprès de serveurs via SSL (authentification client). Généralement, l'identité du client est présumée être la même que celle d'un être humain, tel qu'un employé dans une entreprise. Voir L'authentification par certificat, pour une description de la façon dont les certificats d'un client SSL sont utilisés pour l'authentification client. Les certificats d'un client SSL peuvent également être utilisés pour la signature de formulaires et comme composante d'une solution de l'ouverture de session unique.
    Exemples 
    Une banque donne un certificat client SSL à l'un de ses usagers qui lui permet de s'identifier auprès du serveur de la banque et d'accéder à ses comptes. Une compagnie peut donner un certificat client SSL à l'un de ses nouveaux employés qui lui permet de s'identifier auprès du serveur de l'entreprise et d'obtenir accès aux ressources disponibles sur ce serveur.
    • Certificats de serveur SSL : Utilisé pour identifier les serveurs auprès des client via SSL (authentification serveur). L'authentification serveur peut être utilisée avec ou sans authentification client. L'authentification serveur est obligatoire lors de l'établissement d'une connexion SSL chiffrée. Pour plus d'informations, voir Le protocole SSL.
    Exemple 
    Les sites internet de commerce électronique (communément appelé e-commerce) supportent habituellement l'authentification serveur par certificat, au minimum, pour établir une session SSL chiffrée et assure les clients qu'ils traitent avec un site identifié comme étant celui d'une entreprise donnée. La session SSL assure que les informations personnelles renseignées par le client et transmises par le réseau, telles que son numéro de carte de crédit, ne seront pas aisément interceptées.
    • Certificats S/MIME : Utilisés pour signer et chiffrer les courriels. Comme pour les certificats client SSL, l'identité du client est généralement présumé être la même que celle d'un être humain, tel qu'un employé d'une entreprise. Un certificat unique peut être utilisé comme certificat S/MIME et comme certificat SSL (voir Messages signés et chiffrés). Les certificats S/MIME peuvent également être utilisés pour la signature de formulaires et comme composante d'une solution de l'ouverture de session unique.
    Exemples 
    Une entreprise déploie des certificats combinés S/MIME et SSL dans l'unique but d'authentifier l'identité des employés, permettant ainsi la signature de messages et l'authentification de client SSL, mais pas le chiffrage des messages. Une autre entreprise émet des certificats S/MIME uniquement dans le but de signer et de chiffrer les messages de natures financière ou légale qu'elle envoie.
    • Certificats de signature d'objet : Utilisés pour identifier les signataires de code Java, de scripts JavaScript, ou d'autres fichiers signés. Pour plus d'informations, voir Signature d'objets.
    Exemple 
    Une entreprise de logiciel signe les logiciels qu'elle distribue par Internet pour fournir l'assurance à ses utilisateurs que le logiciel est un produit légitime. L'utilisation des certificats et des signatures numériques de cette façon peut également servir pour que les utilisateurs identifient et contrôlent l'accès à leurs ordinateurs des logiciels téléchargés.
    • Certificats d'AC : Utilisés pour identifier les autorités de certification (AC). Les logiciels client et serveur utilisent les certificats d'AC pour déterminer quelles autres certifications peuvent être de confiance. Pour plus d'informations, voir Utilisation des certificats d'AC pour établir la confiance.
    Exemple 
    Les certificats d'AC stockés dans Communicator déterminent quels autres certificats peuvent être utilisés pour l'authentification. Un administrateur peut implémenter certains aspects de la politique de sécurité de son entreprise en contrôlant les certificats d'AC stockés dans les Communicator de chaque utilisateur.

    Les sections ci-dessous décrivent l'utilisation des certificats dans les produits Red Hat.

    Le protocole SSL

    Le protocole Secure Sockets Layer (SSL) est un ensemble de règles gouvernant l'authentification serveur, l'authentification client et les communications encryptées entre des serveurs et des clients. SSL est largement utilisé sur Internet, particulièrement pour les interactions mettant en œuvre l'échange d'informations confidentielles telles que les numéros de cartes de crédit.

    SSL requiert un certificat SSL serveur, au minimum. Comme partie du processus de négociation, le serveur présente son certificat au client afin d'authentifier son identité. Le processus d'authentification utilise le chiffrement par clef publique et les signatures numériques pour confirmer que ce serveur est bien celui-ci qu'il prétend être. Une fois le serveur authentifié, le client et le serveur utilisent des techniques de chiffrement à clefs symétriques, ce qui est rapide, pour chiffrer toutes les informations qu'ils échangent pour le reste de la session et pour détecter toutes tentatives d'altération des données qui peuvent arriver.

    Les serveurs peuvent éventuellement être configurés pour demander l'authentification client aussi bien que l'authentification serveur. Dans ce cas, après le succès de l'authentification serveur, le client doit à son tour présenter son certificat au serveur afin d'authentifier son identité avant qu'une connexion SSL ne puisse s'établir.

    Pour une présentation du l'authentification client avec SSL et ses différences par rapport à authentification par mot de passe, voir «  L'authentification confirme une identité ». Pour des d'informations plus détaillées à propos de SSL, voir « Introduction à SSL ».

    Messages signés et encryptés

    Certains logiciels de courriers électroniques (y compris Messenger, qui fait parti de Communicator) supportent les messages chiffrés et numériquement signés suivant un protocole largement accepté connu sous le nom de Secure Multipurpose Internet Mail Extension (S/MIME). L'utilisation de S/MIME pour signer et chiffrer des messages requiert que l'expéditeur possède un certificat S/MIME.

    Un message électronique qui comprend une signature numérique fournit l'assurance qu'il a bien été envoyé par la personne dont le nom apparaît dans l'en-tête du message, authentifiant ainsi l'expéditeur. Si la signature numérique ne peut pas être validée pour le courrieleur à la fin de la réception, l'utilisateur est alerté.

    La signature numérique est unique au message qu'elle accompagne. Si le message reçu diffère de quelque manière que se soit du message qui a été envoyé - même par l'ajout ou la suppression d'une virgule - la signature numérique ne peut pas être validée. Par conséquent un message signé fournit aussi une certaine assurance que les données qu'il contient n'ont pas été altérées. Comme on l'a vu au début de ce document, cette sorte d'assurance est connue sous le nom de non répudiation. En d'autres termes, lorsqu'un message est signé, il est très difficile à l'expéditeur de nier l'avoir envoyé. Ceci est capital pour de nombreuses formes de communications commerciales. Pour plus d'informations à propose du mécanisme de signature numérique, voir « Signatures numériques ».

    S/MIME rend également possible le chiffrement des messages électroniques. C'est aussi important pour certains utilisateur professionnels. Cependant, l'utilisation du chiffrement pour les messages requiert une gestion soigneuse. Si le destinataire des messages chiffrés perd sa clef privée et qu'il n'a pas de sauvegarde de la clef, par exemple, les messages chiffrés ne pourront jamais être déchiffrés.

    Signature de formulaire

    De nombreuses formes de e-commerce requièrent la possibilité de fournir une preuve persistante qu'une personne a autorisé une transaction. Bien que SSL fournisse une authentification cliente limitée à la durée de la connexion, il ne fournit pas d'authentification persistante pour les transactions pouvant intervenir pendant cette connexion SSL. S/MIME fournit une authentification persistante pour les messages électroniques, mais le e-commerce utilise souvent des formulaires dans des pages Web plutôt que l'échange de courriel.

    La technologie Red Hat connue sous le nom de signature de formulaire adresse le besoin pour l'authentification persistante des transactions financières. La signature de formulaire permet à un utilisateur d'associer une signature numérique avec les données Web générées comme résultat d'une transaction, telles qu'un ordre d'achat ou tout autre document financier. La clef privée associée avec soit le certificat SSL client, soit un certificat S/MIME peut être utilisée dans ce but.

    Lorsqu'un utilisateur clique sur le bouton « soumettre » d'un formulaire Web qui support la signature de formulaire, une boîte de dialogue affiche le texte exacte à signer. L'auteur du formulaire peut soit spécifier le certificat à utiliser soit sélectionner un certificat SSL ou S/MIME parmi ceux du client installés dans Communicator. Lorsque l'utilisateur clique sur « OK », le texte est signé et les deux (le texte et la signature numérique) sont envoyés au serveur. Le serveur peut alors utiliser un utilitaire Red Hat appelé Signature Verification Tool (Outil de Vérification de Signature) pour valider la signature numérique.

    Pour plus d'informations sur le support des signatures de formulaires dans les produits Red Hat, voir Red Hat Form Signing.

    Ouverture unique de session

    Les utilisateurs doivent souvent retenir plusieurs mots de passe pour les différents services qu'ils utilisent. Par exemple, un utilisateur peut devoir saisir des mots de passe différents pour accéder au réseau, collecter ses messages, accéder à un répertoire, utiliser le service d'agenda de son entreprise et accéder à une grande variété de serveurs. La multiplication des mots de passe devient vite un casse-tête pour les utilisateurs comme pour les administrateurs. Les utilisateurs ayant des difficultés à retenir leurs mots de passe ont tendances à en choisir de faible force et à les écrire dans des endroits accessibles. Les administrateurs doivent maintenir une base de données séparée de mot de passe sur chaque serveur et traiter des problèmes potentiels de sécurité liés au fait que des mots de passe sont envoyés sur le réseau par habitude et fréquemment.

    La solution à ce problème requiert un moyen pour l'utilisateur d'ouvrir une session unique, en utilisant un mot de passe unique, et d'obtenir un accès authentifié à toutes les ressources du réseau que l'utilisateur est autorisé à employer - sans envoyer aucun autre mot de passe. Cette possibilité est connue comme ouverture de session unique.

    Both client SSL certificates and S/MIME certificates can play a significant role in a comprehensive single sign-on solution. For example, one form of single sign-on supported by Red Hat products relies on SSL client authentication (see " L'authentification par certificat"). A user can log in once, using a single password to the local client's private-key database, and get authenticated access to all SSL-enabled servers that user is authorized to use-without sending any passwords over the network. This approach simplifies access for users, because they don't need to enter passwords for each new server. It also simplifies network management, since administrators can control access by controlling lists of certificate authorities (CAs) rather than much longer lists of users and passwords.

    En plus de l'utilisation des certificats, une solution d'ouverture de session unique complète doit être capable d'interopérer avec les systèmes d'entreprise, tels que les systèmes d'exploitation sous-jacents qui s'appuient sur les mots de passe ou toutes autres formes d'authentification.

    Signature d'objet

    Communicator supporte un ensemble d'outils et de technologies appelés signature d'objet. La signature d'objet utilise des techniques standard de cryptographie à clef publique pour permettre aux utilisateurs d'obtenir des informations fiables à propos du code qu'ils téléchargent de la même façon qu'ils peuvent obtenir des informations fiables à propos des logiciels prêt-à-installer.

    Plus important, la signature d'objet aide les utilisateurs et les administrateurs réseaux à prendre des décisions concernant les logiciels distribués par Internet ou intranet — par exemple, autoriser ou non les applets Java signés par une entité donnée à utiliser certaines fonctionnalités spécifiques d'un ordinateur.

    Les « objets » signés avec les technologies de signature d'objet peuvent être des applets ou tout autre code Java, scripts JavaScript, plugins, ou tout autre type de fichiers. La « signature » est une signature numérique. Les objets signés et leur signature sont généralement stockés dans une archive spéciale appelé archive JAR.

    Les développeurs de logiciels et toute personne désireuse de signés des fichiers à l'aide de cette technique doit tout d'abord obtenir un certificat de signature d'objet.

    Contenu d'un certificat

    Le contenu des certificats supportés par Red Hat et de nombreuses autres éditeurs de logiciels sont organisés selon la spécification de certificat X.509 v3, qui a été recommandée par l'International Telecommunications Union (ITU), une organisation de standardisation internationale, depuis 1988.

    Les utilisateurs n'ont généralement pas besoin de connaître le contenu exact d'un certificat. Cependant les administrateurs système travaillant avec les certificats peuvent avoir besoin de se familiariser avec les informations qu'il contient.

    Noms distincts

    Un certificat X.509 v3 relie un nom distinct (distinguished name ou DN en anglais) à une clef publique. Un DN est une série de paires nom-valeur, telle que uid=martin, qui identifie de façon unique une entité (qui est le « sujet » du certificat).

    Par exemple, voici ce que donnerai le DN typique d'un employé de Red Hat, Inc.:

    uid=martin,e=martin@exemple.net,cn=Jean Martin,o=Red Hat, Inc.,c=FR
    

    Les abréviation devant chaque signe égale « = » de cet exemple on les significations suivantes :

    • uid : ID utilisateur
    • e : adresse électronique
    • cn : le nom courant de l'utilisateur
    • o : organisation
    • c : pays

    Les DN peuvent inclure une grande variété d'autres paires nom-valeur. Elles sont utilisées pour identifier à la fois les sujets du certificat et les entrés dans les annuaires qui supportent LDAP (Lightweight Directory Access Protocol).

    Les règles régissant la construction des DN peuvent parfois être complexes et ne font pas parties de l'objectif de ce document. Pour de plus amples informations à propos des DN, voir A String Representation of Distinguished Names (en).

    Un certificat typique

    Chaque certificat de type X.509 comprend deux sections :

    • La section données inclut les informations suivantes :
      • Le numéro de version du standard X.509 supporté par le certificat.
      • Le numéro de série du certificat. Chaque certificat émis par une autorité de certification (AC) a un numéro de série unique parmi les certificats émis par cette AC.
      • Informations
      • Informations concernant la clef publique de l'utilisateur, comprenant l'algorithme utilisé et une représentation de la clef elle-même.
      • Le DN de l'AC émettrice du certificat.
      • La période de validité du certificat (par exemple, entre le 15 novembre 1999 à 13 h 00 et le 15 novembre 2000 à 13 h 00).
      • Le DN du sujet du certificat (par exemple, dans un certificat client SSL, le DN de l'utilisateur), également appelé le nom du sujet.
      • Des extensions de certificat optionnelles, pouvant fournir des données supplémentaires utilisées par le client ou le serveur. Par exemple, l'extension de certificat type indique le type auquel appartient le certificat : un certificat client SSL, un certificat serveur SSL, un certificat de signature de message, etc. Les extensions de certificat peuvent également être utilisées pour d'autres raisons.
    • La section signature inclut les informations suivantes :
      • L'algorithme de cryptographie, ou chiffrement, utilisé par l'AC émettrice pour créer sa propre signature numérique. Pour plus d'informations à propos des chiffrements, voir "Introduction à SSL."
      • La signature numérique de l'AC, obtenue par le hachage de toutes les données contenues dans le certificat et chiffrée avec la clef privée de l'AC.

    Voici les sections de données et de signature d'un certificat dans un format lisible par un être humain :

    Certificate:
    Data:
     Version: v3 (0x2)
     Serial Number: 3 (0x3)
     Signature Algorithm: PKCS #1 MD5 With RSA Encryption
     Issuer: OU=Ace Certificate Authority, O=Ace Industry, C=US
     Validity:
      Not Before: Fri Oct 17 18:36:25 1997
      Not  After: Sun Oct 17 18:36:25 1999
     Subject: CN=Jane Doe, OU=Finance, O=Ace Industry, C=US
     Subject Public Key Info:
      Algorithm: PKCS #1 RSA Encryption
      Public Key:
       Modulus:
        00:ca:fa:79:98:8f:19:f8:d7:de:e4:49:80:48:e6:2a:2a:86:
        ed:27:40:4d:86:b3:05:c0:01:bb:50:15:c9:de:dc:85:19:22:
        43:7d:45:6d:71:4e:17:3d:f0:36:4b:5b:7f:a8:51:a3:a1:00:
        98:ce:7f:47:50:2c:93:36:7c:01:6e:cb:89:06:41:72:b5:e9:
        73:49:38:76:ef:b6:8f:ac:49:bb:63:0f:9b:ff:16:2a:e3:0e:
        9d:3b:af:ce:9a:3e:48:65:de:96:61:d5:0a:11:2a:a2:80:b0:
        7d:d8:99:cb:0c:99:34:c9:ab:25:06:a8:31:ad:8c:4b:aa:54:
        91:f4:15
       Public Exponent: 65537 (0x10001)
      Extensions:
       Identifier: Certificate Type
        Critical: no
        Certified Usage:
         SSL Client
       Identifier: Authority Key Identifier
        Critical: no
        Key Identifier:
         f2:f2:06:59:90:18:47:51:f5:89:33:5a:31:7a:e6:5c:fb:36:
         26:c9
      Signature:
       Algorithm: PKCS #1 MD5 With RSA Encryption
       Signature:
        6d:23:af:f3:d3:b6:7a:df:90:df:cd:7e:18:6c:01:69:8e:54:65:fc:06:
        30:43:34:d1:63:1f:06:7d:c3:40:a8:2a:82:c1:a4:83:2a:fb:2e:8f:fb:
        f0:6d:ff:75:a3:78:f7:52:47:46:62:97:1d:d9:c6:11:0a:02:a2:e0:cc:
        2a:75:6c:8b:b6:9b:87:00:7d:7c:84:76:79:ba:f8:b4:d2:62:58:c3:c5:
        b6:c1:43:ac:63:44:42:fd:af:c8:0f:2f:38:85:6d:d6:59:e8:41:42:a5:
        4a:e5:26:38:ff:32:78:a1:38:f1:ed:dc:0d:31:d1:b0:6d:67:e9:46:a8:
        d:c4
    

    Voici le même certificat affiché au format d'encodage 64 bytes interprété par un logiciel :

     -----BEGIN CERTIFICATE-----
     MIICKzCCAZSgAwIBAgIBAzANBgkqhkiG9w0BAQQFADA3MQswCQYDVQQGEwJVUzER
     MA8GA1UEChMITmV0c2NhcGUxFTATBgNVBAsTDFN1cHJpeWEncyBDQTAeFw05NzEw
     MTgwMTM2MjVaFw05OTEwMTgwMTM2MjVaMEgxCzAJBgNVBAYTAlVTMREwDwYDVQQK
     EwhOZXRzY2FwZTENMAsGA1UECxMEUHViczEXMBUGA1UEAxMOU3Vwcml5YSBTaGV0
     dHkwgZ8wDQYJKoZIhvcNAQEFBQADgY0AMIGJAoGBAMr6eZiPGfjX3uRJgEjmKiqG
     7SdATYazBcABu1AVyd7chRkiQ31FbXFOGD3wNktbf6hRo6EAmM5/R1AskzZ8AW7L
     iQZBcrXpc0k4du+2Q6xJu2MPm/8WKuMOnTuvzpo+SGXelmHVChEqooCwfdiZywyZ
     NMmrJgaoMa2MS6pUkfQVAgMBAAGjNjA0MBEGCWCGSAGG+EIBAQQEAwIAgDAfBgNV
     HSMEGDAWgBTy8gZZkBhHUfWJM1oxeuZc+zYmyTANBgkqhkiG9w0BAQQFAAOBgQBt
     I6/z07Z635DfzX4XbAFpjlRl/AYwQzTSYx8GfcNAqCqCwaSDKvsuj/vwbf91o3j3
     UkdGYpcd2cYRCgKi4MwqdWyLtpuHAH18hHZ5uvi00mJYw8W2wUOsY0RC/a/IDy84
     hW3WWehBUqVK5SY4/zJ4oTjx7dwNMdGwbWfpRqjd1A==
     -----END CERTIFICATE-----
     
    

    Utiliser les certificats pour établir la confiance

    Les autorités de certification (AC) sont des entités qui valident l'identité et l'émission des certificats. Elles peuvent être des organismes indépendants ou des entreprises qui utilisent leur propre logiciel d'émission de certificats (tel que Red Hat Certificate System).

    Tout logiciel client ou serveur qui supporte les certificats maintient une liste des certificats d'AC de confiance. Ces certificats d'AC déterminent quels autres certificats le logiciel peut valider - en d'autres mots, dans quels émetteurs de certificats le logiciel peut avoir confiance. Dans le cas le plus simple, le logiciel ne peut valider que les certificats émis par une des AC pour lesquelles il possède le certificat. Il est également possible pour un certificat d'une AC de confiance de faire parti d'une chaîne de certificats d'AC, chacun émis par l'AC parente dans la hiérarchie de certificat.

    Les sections suivantes expliquent comment les hiérarchies et les chaînes de certificats déterminent les logiciels de confiance.

    Hiérarchies d'AC

    Dans les grandes organisations, il peut être judicieux de déléguer la responsabilité de l'émission des certificats à plusieurs autorités de certification. Par exemple, le nombre de certificats requis peut être trop important à maintenir par une seule AC ; les différents services de l'organisation peuvent avoir différentes politiques d'attribution des certificats ; ou il peut être important pour l'AC d'être physiquement localisée dans la même zone géographique que les personnes auxquelles elle délivre les certificats.

    Il est possible de déléguer la responsabilité de l'émission de certificats à des AC subordonnées. Le standard X.509 inclus un modèle de paramétrage d'une hiérarchie d'AC telle celle montrée à la Figure 6.

    Figure 6. Exemple de hiérarchie d'AC

    Dans ce modèle, l'AC racine est au sommet de la hiérarchie. Le certificat de l'AC racine est un « certificat auto-signé » : c'est-à-dire que le certificat est signé numériquement par la même entité — L'AC racine — que celle que le certificat identifie. Les AC directement subordonnées à l'AC racine on des certificats d'AC signés par l'AC racine. Les AC se trouvant sous les AC subordonnées dans la hiérarchie ont leurs certificats signés par les plus hautes AC subordonnées.

    Les organisations ont une grande flexibilité quant à l'établissement de leurs hiérarchies d'AC. La figure 6 ne montre qu'un exemple ; beaucoup d'autres hiérarchies sont possibles.

    Chaînes de certificat

    Les hiérarchie d'AC se reflètent dans les chaînes de certificats. Une chaîne de certificats est une série de certificats émis par des AC successives. La figure 7 montre une chaîne de certificats leading from a certificate that identifies some entity through two subordinate CA certificates to the CA certificate for the root CA (based on the CA hierarchy shown in Figure 6).

    Figure 7. Exemple de chaîne de certificat

    Une chaîne de certificats trace le chemin des certificats d'une branche de la hiérarchie jusqu'à la racine. Dans une chaîne de certificats, on a donc :

    • chaque certificat est suivi par le certificat de son émetteur.
    • chaque certificat contient le nom (DN) de l'émetteur du certificat, qui est identique à celui du nom du sujet du certificat suivant dans la chaîne.

    Dans la figure 7, Le certificat Engineering CA contient le DN de l'AC (qui est USA CA), qui a émis le certificat. Le DN de USA CA est également le nom du sujet du prochain certificat dans la chaîne.

    • Chaque certificat est signé avec la clef privée de son émetteur. La signature peut être vérifiée avec la clef publique du certificat de l'émetteur, qui est le prochain certificat dans la chaîne.

    Dans la figure 7, la clef publique dans le certificat de USA CA peut être utilisée pour vérifier que la signature numérique de USA CA dans le certificat de Engineering CA.

    Vérification d'une chaîne de certificat

    La vérification de la chaîne de certificats est le processus permettant de s'assurer que la chaîne de certificats donnée est bien formée, proprement signée et sécurisée. Les logiciels Red Hat utilisent la procédure suivante pour former et vérifier une chaîne de certificats, en commençant par le certificat présenté pour l'authentification :

    1. La période de validité du certificat est vérifiée par rapport à la date actuelle fournie par l'horloge système du vérificateur.
    2. Le certificat de l'émetteur est localisé. La source peut être une base de certificats locale du vérificateur (du client ou du serveur) ou une chaîne de certificats fournit par le sujet (par exemple, par une connexion SSL).
    3. La signature du certificat est vérifiée à l'aide de la clef publique du certificat de l'émetteur.
    4. Si le certificat de l'émetteur est présent dans les certificats de confiance du vérificateur, la vérification s'arrête avec succès à cette étape. Autrement, le certificat de l'émetteur est vérifié pour être certain qu'il contient les indications appropriées concernant les AC subordonnées dans l'extension du type de certificat de Red Hat, et la chaîne de vérification recommence depuis l'étape 1, mais avec le nouveau certificat. La figure 8 présente un exemple de ce processus.

    Figure 8. Vérification d'un chaîne de certificats complète, jusqu'à l'AC racine

    La figure 8 décrit ce qui se passe lorsque seule l'AC racine est incluse dans la base locale de certificats du vérificateur. Si un certificat d'une des AC intermédiaires présentes dans cette figure, telle que Engineering CA, est trouvé dans la base locale de certificats du vérificateur, la vérification s'arrête à ce certificat, comme décrit à la figure 9.

    Figure 9. Vérification d'une chaîne de certificats, jusqu'à une AC intermédiaire

    Des dates de validité expirées, une signature invalide ou l'absence d'un certificat pour l'AC émettrice à n'importe quelle étape de la chaîne de certificats provoquera un échec de l'authentification. Par exemple, la figure 10 montre l'échec d'une vérification si le certificat de l'AC racine ou celui d'une AC intermédiaire ne sont pas présent dans la base locale de certificats du vérificateur.

    Figure 10. Une chaîne de certificat qui ne peut pas être vérifiée

    Pour des informations générales sur le fonctionnement des signatures numériques, voir « Signatures numériques ». Pour une description plus détaillée sur le processus de vérification des signatures dans le contexte d'une authentification SSL client-serveur, voir « Introduction à SSL ».

    Interwiki Language Links

    Étiquettes et contributeurs liés au document

    Contributors to this page: Sheppy, Fredchat, BenoitL, nterray
    Dernière mise à jour par : nterray,