PKI – Module 1 : Vue Générale des Infrastructures de Clés Publiques

Dans ce module, nous vous introduirons dans l’univers des PKI, de la cryptographie, des autorités de certifications et des certificats.

Parler de PKI, c’est faire référence à la combinaison de technologies d’infrastructures pour sécuriser les communications et les transactions de l’entreprise, sur Internet ou en interne. Une PKI combine des certificats digitaux, la cryptographie de clés publics et l’utilisation d’autorités de certifications pour former l’architecture sécurité d’un réseau. On l’utilise en général pour :

  • Créer des certificats utilisateur, serveurs ou de services
  • Sécuriser les communications sur un réseau
  • Sécuriser les documents de l’entreprise
  • Sécuriser un site web ou un serveur de messagerie

Une PKI est aujourd’hui indispensable pour assurer la sécurité des applications et du réseau de l’entreprise.

Introduction à la PKI

Qu’est-ce qu’une PKI ?

Une PKI est la combinaison de logiciels, de technologies de cryptage, de processus, et services qui permettent à une organisation de garantir sa communication et ses transactions. Une infrastructure à clé publique repose sur l’échange de certificats numériques entre les utilisateurs authentifiés et les ressources fiables. Vous utilisez des certificats pour sécuriser les données et gérer l’identité des utilisateurs et des ordinateurs à la fois au sein et en dehors de votre organisation. Une solution de PKI peut répondre aux besoins en sécurité ou aux exigences techniques de votre organisation :

  • Confidentialité : vous utilisez une infrastructure à clé publique pour crypter les données stockées ou transmises.
  • Intégrité : une infrastructure à clé publique vous permet de signer numériquement des données. Une signature numérique permet de vérifier qu’aucun utilisateur ou processus n’a modifié les données.
  • Authenticité : une PKI fournit plusieurs mécanismes d’authenticité ; les données d’authentification passent par des algorithmes de hachage pour produire un résumé du message. L’empreinte du message est ensuite signée numériquement à l’aide de la clé privée de l’expéditeur, prouvant que le résumé du message a été produit par lui (la clé privée est unique).
  • Non-répudiation : lorsque les données sont signées numériquement, la signature numérique fournit une preuve de l’intégrité des données signées et une preuve de l’origine des données. Un tiers peut alors vérifier l’intégrité et l’origine des données à tout moment. Cette vérification ne peut pas être réfutée par le propriétaire du certificat qui a numériquement signé les données.
  • Disponibilité : vous pouvez installer plusieurs autorités de certification dans votre hiérarchie de CA pour émettre des certificats. Si une autorité de certification n’est pas disponible dans la hiérarchie de CA, un autre CA peut délivrer un certificat.

Les composants d’une PKI

Une infrastructure à clé publique se compose de plusieurs objets interconnectés, d’applications et de services. Ces composants fonctionnent ensemble pour distribuer et valider les certificats.

Une PKI comprend les éléments suivants :

  • Outils de gestion de certificat et de CA : fournit les interfaces graphiques (GUI) et les outils de ligne de commande pour gérer les certificats, publier les certificats pour les CAs et les CRLs, configurer les CAs, importer et exporter les certificats/clés et enfin récupérer les clés privées archivées.
  • Autorité de certification : délivre des certificats aux utilisateurs, ordinateurs et services et gère les certificats. Chaque certificat émis par une autorité de certification est signé avec le certificat numérique de cette autorité de certification.
  • Points de distribution CRL et Certificat : fournit des lieux de publication où les certificats et les CRLs sont accessibles au public, au sein ou hors d’une organisation. Les éditeurs peuvent utiliser n’importe quel genre de service d’annuaire, y compris X.500, Lightweight Directory Access Protocol (LDAP) ou des répertoires dans un système d’exploitation spécifique. Les Éditeurs peuvent également publier des certificats et des CRLs sur les serveurs Web.
  • Modèles de certificats : définit le contenu et l’objet d’un certificat numérique. Un modèle de certificat définit les conditions de délivrance et le rôle du certificat, les extensions implémentées (tel que la stratégie d’application ou l’étendue d’utilisation de la clé) et les autorisations d’inscription pour les certificats qu’une autorité de certification génère.
  • Certificats numériques : ils constituent le fondement d’une PKI. Les certificats numériques sont des informations d’identification électroniques qui sont associées avec une clé publique et une clé privée qu’une organisation utilise pour authentifier les utilisateurs.
  • Listes de révocation de certificats (CRL) : détient une liste des certificats qu’une autorité de certification a révoquée avant que le certificat n’ait atteint sa date d’expiration.
  • Services et applications utilisant des clés publiques : désigne les applications ou services qui supportent le chiffrement par clé publique et vous permettant d’implémenter une sécurité à base de clés publiques. Vous pouvez uniquement mettre en œuvre ces composants après avoir configuré votre PKI pour générer, publier et contrôler les certificats.

Outils pour la PKI

Avec l’avènement de PowerShell, il est de plus en plus courant d’utiliser des cmdlets pour manipuler les services installés dans un S.I. : les PKI ne font pas mesure d’exception

Vous retrouverez également les traditionnelles consoles d’administrations via la MMC (Microsoft Management Console).

  • La console certificats permet de gérer les certificats locaux de l’utilisateur, de la machine ou d’un service.
  • La console modèles de certificats permet de créer, modifier et gérer l’ensemble des modèles de certificats dans une forêt Active Directory.
  • La console autorité de certification permet de gérer l’autorité de certification (CA) ainsi que les certificats qu’elle a générés ; elle permet également de publier la CRL.

    Egalement, deux utilitaires historiques en ligne de commandes pour la gestion de certificats :

  • Certutil.exe : permet de scripter l’interaction avec une CA et les tâches de gestion de certificat y compris la gestion de la CA, la publication des certificats et de la liste de révocation (CRL), la révocation des certificats et la récupération des clés privées archivées.
  • Certreq.exe : permet de scripter les demandes de certificats auprès d’une autorité de certification et de générer des demandes de certificats d’autorité de Certification Croisée.

Introduction à la cryptographie

La cryptographie fournit un moyen de protéger les données en le convertissant sous une forme illisible pour protéger la transmission entre réseaux ou organisations, ou pour stocker des données en toute sécurité. La cryptographie est une technologie importante pour le commerce électronique, les intranets, les extranets et bien d’autres applications Web.

Il existe deux types de techniques de cryptographie : symétrique et asymétrique. Les clés symétriques et asymétriques sont utilisées pour fournir une variété de fonctions de sécurité pour sécuriser les réseaux et l’information.

Clés de chiffrement

Le chiffrement implique le chiffrement des données dans un format chiffré et le décryptage des données obtenues dans son format d’origine. Vous pouvez utiliser soit la même clé (chiffrement symétrique) soit deux clés distinctes mais connexes pour le chiffrement et le déchiffrement (chiffrement asymétrique).

Vous utilisez les types de clés suivants pour chiffrer et déchiffrer des données :

  • Clé symétrique : la même clé est utilisée pour le chiffrement et le déchiffrement. Lors du chiffrement des données, l’expéditeur utilise la clé symétrique pour s’assurer qu’une personne ou un processus non autorisée n’inspecte les données d’origine. Le destinataire utilise la même clé symétrique pour déchiffrer les données.

    Note : parce que la clé symétrique est utilisée pour le chiffrement et le déchiffrement des données, vous devez le protéger contre l’interception. Si la clé symétrique est interceptée, toutes les données chiffrées avec la clé sont déchiffrables.

  • Clé asymétrique : ce type de clé est une combinaison de deux algorithmes mathématiques, formé d’une clé publique et d’une clé privée, qui est souvent considérée comme une paire de clés. Les deux clés sont utilisées pour chiffrer et déchiffrer les données.
    • Si la clé publique crypte les données, la clé privée associée décrypte les données.
    • Si la clé privée crypte les données, la clé publique associée décrypte les données.

    La clé privée n’est jamais exposée aux utilisateurs du réseau. Elle est conservée dans sur un périphérique physique, comme une carte à puce, ou sur l’ordinateur. La clé publique, qui est un attribut du certificat, est largement diffusée dans des endroits tels que l’annuaire Active Directory, afin de s’assurer que d’autres utilisateurs puissent l’obtenir pour réaliser des opérations de chiffrement et signer numérique des données.

Comment fonctionne le chiffrement symétrique ?

Le chiffrement symétrique utilise la même clé pour le chiffrement et le déchiffrement. En raison de sa vitesse, on utilise généralement le cryptage symétrique pour crypter de grandes quantités de données. Le cryptage symétrique est également dénommé cryptage en bloc. Lorsque vous effectuez un chiffrement symétrique, l’expéditeur des données originales crypte les données à l’aide de la clé symétrique. Le résultat est un texte chiffré à partir du contenu original qui est transmis au destinataire. Lorsque le destinataire reçoit le texte chiffré, il déchiffre les données avec la même clé symétrique pour obtenir les données d’origine. Si la clé symétrique est compromise, les données chiffrées sont également compromises.

Comment fonctionne le chiffrement asymétrique ?

Lorsque vous implémentez le chiffrement asymétrique, la paire de clés du destinataire protège les données originales contre l’inspection en cryptant les données originales au cours de la transmission.

Les étapes suivantes expliquent le processus de chiffrement asymétrique :

  1. L’expéditeur extrait la clé publique du destinataire (par exemple, avec Active Directory, l’expéditeur extrait la clé publique en récupérant le certificat du destinataire dans l’annuaire puis récupère la clé publique depuis le certificat).
  2. L’expéditeur génère une clé symétrique et utilise cette clé pour chiffrer les données originales.
  3. La clé symétrique est chiffrée avec la clé publique du destinataire pour empêcher qu’elles soient interceptées au cours de la transmission.
  4. La clé symétrique chiffrée et les données chiffrées sont envoyées au destinataire.
  5. Le destinataire utilise sa clé privée pour déchiffrer la clé symétrique chiffrée.
  6. Les données chiffrées sont déchiffrées avec la clé symétrique, ce qui permet d’obtenir les données d’origine.

Rappel : dans un chiffrement asymétrique, la clé privée décode la clé publique et vice-versa. Il n’est donc pas possible de décoder le message pour retrouver la clé symétrique en réutilisant la clé publique du destinataire.

Comment fonctionne une signature numérique de clé publique ?

Lorsque vous implémentez la signature numérique, la paire de clés de l’expéditeur protège les données d’origine d’une modification grâce à la mise en œuvre d’une signature numérique pour les données originales. La signature numérique ne protège pas les données de l’inspection pendant la transmission.

Les étapes suivantes expliquent le processus d’une signature numérique appliquée aux données originales :

  1. Un algorithme de hachage est appliqué aux données d’origine. Un algorithme de hachage accepte toute forme de données et produit un résultat mathématique pour les données saisies. Le résultat qui en résulte est la valeur de hachage.

    Note : Un simple changement de caractère dans les données originales se traduira par un changement de valeur de plus de la moitié des chiffres dans le résultat de la valeur de hachage. Ce changement de valeur protège les données des modifications simples, tels que gonfler une valeur monétaire dans un contrat.

  2. La valeur de hachage qui en résulte est chiffrée à l’aide de la clé privée de l’expéditeur. Le cryptage protège la valeur de hachage d’une modification au cours de la transmission vers le destinataire.
  3. L’expéditeur envoie l’original du certificat et la valeur de hachage chiffrée avec les données au destinataire. Le certificat comporte la clé publique de l’expéditeur parmi ces attributs.
  4. Le destinataire extrait la clé publique de l’expéditeur du certificat reçu. Le destinataire utilise la clé publique pour déchiffrer la valeur de hachage chiffrée. La validation du certificat de l’expéditeur et le déchiffrement réussi prouve que les données proviennent de l’expéditeur.
  5. Le bénéficiaire transmet les données d’origine à travers le même algorithme de hachage. La valeur de hachage qui en résulte est comparée à la valeur de hachage reçue de l’expéditeur.

Si les deux valeurs de hachage sont identiques, les données d’origine n’ont pas été modifiées au cours de la transmission de l’expéditeur au récepteur.

Certificats et Autorités de Certification

Les certificats numériques et les autorités de certification (CA) sont les composants de base d’une infrastructure à clé publique. Les certificats numériques sont des informations d’identification électroniques permettant d’identifier les individus, les organisations et les ordinateurs. Les CAs délivrent et certifient les certificats. Un certificat non seulement identifie son propriétaire comme une entité sur le réseau mais il identifie également la CA qui l’a émis.

Qu’est-ce qu’un certificat numérique ?

Un certificat numérique fournit des informations sur le sujet du certificat, sa validité, les applications et les services que peut utiliser le certificat. Un certificat numérique fournit également un moyen d’identifier le titulaire du certificat. Les certificats utilisent des techniques cryptographiques pour résoudre le problème d’absence de contact physique entre les deux entités qui effectuent une transaction. Au lieu d’identifier le titulaire du certificat lors d’une réunion en face à face, une application ou un service vérifie chaque titulaire du certificat en vérifiant la validité du certificat que chaque titulaire présente.

Il est impossible pour un utilisateur ou un ordinateur d’emprunter l’identité de quelqu’un d’autre parce que les certificats sont signés numériquement par l’autorité de certification qui émet le certificat. Un attaquant ne pas modifier le certificat sans la compétence du CA. Un attaquant ne peut pas non plus endosser l’identité de l’utilisateur ou l’ordinateur répertorié dans le sujet du certificat sans avoir eu accès à la clé privée qui est associée à celui-ci.

Un certificat numérique contient les éléments suivants :

  • La clé de chiffrement publique de la paire de clés du sujet du certificat.
  • Les informations sur le sujet qui a demandé le certificat.
  • Les informations sur l’autorité de certification ayant émis le certificat.

Avant qu’une autorité de certification n’émette un certificat, l’autorité de certification vérifie l’identité du demandeur. Cette vérification peut inclure une vérification des antécédents manuelle du demandeur ou un examen de la liste de contrôle des accès discrétionnaire (DACL) du modèle de certificat demandé pour s’assurer que l’ordinateur ou l’utilisateur demandeur a les autorisations requises pour inscrire le certificat demandé.

Que sont les extensions de certificat ?

Les informations que contient un certificat numérique sont stockées dans le certificat sous forme d’attributs connus comme des extensions de certificat. Les champs d’extension de certificat donnent des informations supplémentaires sur le sujet du certificat. En sachant quels attributs sont disponibles dans un certificat, vous pouvez recueillir plus d’informations sur le titulaire du certificat et les applications qu’il peut utiliser avec ce certificat.

Le format initial d’un certificat numérique était connu sous la forme X.509 version 1. Ce format défini des champs de certificat qui décrivent les attributs de base de l’objet, l’émetteur et la validité du certificat.

X.509 version 1 comprend les champs suivants :

  • Objet : Fournit le nom de l’ordinateur, utilisateur, périphérique réseau ou service à qui l’autorité de certification à émis le certificat. Le nom du sujet est couramment représenté en utilisant un format X.500 ou LDAP.
  • Numéro de série : Fournit un identificateur unique pour chaque certificat qu’une autorité de certification émet.
  • Émetteur : Fournit un nom unique pour l’autorité de certification ayant émis le certificat. Le nom de l’émetteur est souvent représenté en utilisant le format X.500 ou LDAP.
  • Valide à partir du : Fournit la date et le moment où le certificat devient valide.
  • Valable jusqu’au : Fournit la date et l’heure lorsque le certificat n’est plus considéré comme valide.
  • Clé publique : Contient la clé publique de la paire de clés auquel est associée le certificat.

Note : La date à laquelle une application ou un service évalue le certificat doit être comprise entre les champs valide à partir du et valide jusqu’au du certificat pour qu’il puisse être considéré comme valide.

Le certificat X.509 version 3 est le format de certificat actuel dans un PKI Windows Server 2016. En plus des champs de la version 1, le certificat X.509 version 3 inclut des extensions qui fournissent des fonctionnalités et des caractéristiques supplémentaires au certificat. Ces extensions sont facultatives et ne sont pas nécessairement incluses dans chaque certificat par l’autorité de certification :

  • Autre nom du sujet : un sujet peut être présenté dans de nombreux formats différents. Par exemple, si le certificat doit inclure un nom de compte utilisateur sous la forme d’un nom unique LDAP, d’une adresse de messagerie et d’un UPN, vous pouvez inclure le nom de messagerie et l’UPN dans le certificat en ajoutant une extension autre nom du sujet comprenant ces formats de noms supplémentaires.
  • Points de distribution CRL (CDP) : lorsqu’un utilisateur, ordinateur ou service présente un certificat à une application ou un service, celui-ci doit déterminer si le certificat a été révoqué avant que sa période de validité n’ait expiré. L’extension CDP fournit une ou plusieurs URL où l’application ou le service peut récupérer le fichier de CRL.
  • Accès aux informations de l’autorité (AIA) : dès qu’une application ou un service valide un certificat, le certificat de l’autorité de certification ayant émis le certificat, appelée aussi le parent CA, doit être évalués également. L’extension de l’AIA fournit une ou plusieurs URL d’où une application ou un service peut récupérer le certificat d’autorité de certification émettrice.

    Utilisation de clé améliorée : cet attribut décrit quelles applications ou services pour lequel un certificat peut être utilisé en incluant un identificateur d’objet (OID) pour chaque prise en charge d’application ou service. L’OID est une séquence de nombres provenant d’un registre mondial qui est uniques dans le monde.

  • Stratégies d’application : décrit également quelles applications ou services pour lesquelles un certificat peut être utilisé en incluant un OID pour chacun pris en charge d’application ou de service. Le contenu du champ clé améliorée doit correspondre au contenu de l’extension des stratégies d’Application.
  • Politiques de certification : décrit quelles mesures une organisation prend pour valider l’identité d’un demandeur de certificat avant qu’un certificat ne soit délivré. Un OID représente le processus de validation et éventuellement d’une URL vers une stratégie de qualification qui décrit entièrement les mesures prises pour valider l’identité.

Qu’est-ce qu’une autorité de certification ?

Une autorité de certification dans un réseau Windows Server est un ordinateur avec le rôle Active Directory Certificate Services installé. Une autorité de certification est une partie importante d’une solution PKI Microsoft.

Une autorité de certification effectue les tâches suivantes de gestion de réseau dans un Réseau de Windows Server 2016 :

  • Vérifie l’identité d’un demandeur de certificat. Avant qu’une autorité de certification n’émette un certificat pour une demande utilisateur, ordinateur ou service, l’autorité de certification valide le demandeur pour s’assurer que les certificats sont délivrés uniquement aux utilisateurs ou ordinateurs approuvés. La méthode de validation du demandeur dépend du type de CA à qui l’utilisateur ou l’ordinateur envoie la demande de certificat. Par exemple, la politique de certification d’une autorité de certification peut exiger une vérification des antécédents avant qu’un certificat soit délivré. Ou encore, l’autorité de certification peut délivrer le certificat basé sur les informations d’identification qui sont présentées lors de la demande de certificat.
  • Délivre des certificats à la demande des utilisateurs, ordinateurs et services. Après que la CA ait validée l’identité de l’utilisateur, ordinateur ou service, l’autorité de certification émet le certificat demandé. Le type de certificat que l’utilisateur demande détermine le contenu du certificat émis. Par exemple, un certificat IPSec inclut des stratégies d’application qui permettent seulement l’utilisation d’Internet Authentification Protocol Security (IPSec) avec ce certificat.
  • Gère la révocation des certificats. L’autorité de certification publie une liste de révocation à intervalles réguliers. Le CRL est constitué d’une liste de numéros de série des certificats que la CA déclare ne plus être fiables. Dans la liste CRL publiée, le CA indique le numéro de série du certificat et la raison pour laquelle le certificat a été révoqué.

Hiérarchie d’autorité de certification

Vous pouvez déployer l’un des deux modèles de CA : une hiérarchie de racine ou une hiérarchie de certification croisée. Les réseaux Windows Server reconnaissent et soutiennent les deux modèles.

Dans une hiérarchie de CA de racine, toutes sont des autorités de certification appartenant à une CA parente et sont chaînées à une autorité de certification de racine commune. Dans une hiérarchie de certification croisée, une autorité de certification dans une racine de l’organisation délivre un certificat d’autorité de certification subordonné à une autorité de certification dans une autre organisation.

Note : Les hiérarchies de racine sont préférées aux hiérarchies de certification croisées car elles sont plus faciles à déployer, maintenir et dépanner.

Une hiérarchie de CA racine :

  • Améliore la sécurité et l’évolutivité. Il protège les couches supérieures de la hiérarchie de CA des attaques réseau en supprimant les couches supérieures de la CA du réseau (CA root arrêté).
  • Offre une administration flexible de la hiérarchie de CA. Vous pouvez utiliser la séparation de rôle pour déléguer la gestion des CA et séparer les groupes d’administration au sein d’une organisation.
  • Prend en charge les CAs commercial. Toute les PKI commerciales, telle que VeriSign, GTE, Thawte et RSA, sont intégrées dans les hiérarchies de racine de confiance de la CA.
  • Prend en charge la plupart des applications. Les applications telles que Microsoft Internet Explorer et Exchange prennent en charge les hiérarchies de certificats de confiance racines.

Une hiérarchie de certification croisée :

  • Fournit une interopérabilité entre entreprises et entre les produits. Quand une hiérarchie de certification croisée est implémentée, les certificats sont chaînés logiquement à la racine de confiance CA de l’organisation qui évalue les certificats présentés.
  • Associe les domaines disparates de PKI. Vous pouvez émettre une autorité de Certification croisée à partir de n’importe quel CA dans votre hiérarchie d’organisation vers n’importe qu’elle CA chez une une organisation partenaire ayant une hiérarchie de CA.
  • Suppose une confiance totale à une hiérarchie de CA étrangère. Les certifications croisées n’impliquent pas l’application de toutes les contraintes sur les certificats qu’une organisation partenaire émets. Vous devez implémenter une contrainte de subordination pour mettre en œuvre les contraintes sur ces certificats.

Les rôles dans une hiérarchie d’autorité de certification

Chaque autorité de certification dans une hiérarchie de CA ce voit attribuer un rôle, qui est déterminé par l’emplacement du CA dans la hiérarchie. Les rôles communs dans une hiérarchie de CA incluent une racine CA, une politique de CA et une autorité de certification émettrice.

Une autorité de certification racine est le plus haut CA dans une hiérarchie de CA et est le point de confiance pour tous les certificats qui sont émis par l’AC dans la hiérarchie d’AC. Si un utilisateur, un ordinateur, ou service fait confiance à une autorité de certification racine, ils ont implicitement confiance tous les certificats émis par toutes les autres autorités de certification dans la hiérarchie d’AC.

Une autorité de certification racine est différente de tous les autres CAs, en ce qu’elle émet son propre certificat. Cela signifie que les champs metteur et le sujet du certificat contient le même nom unique. Une autorité de certification racine délivre seulement des certificats à d’autres autorités de certification qui lui sont directement subordonnés.

Une CA de stratégie se trouve généralement sur le deuxième niveau d’une hiérarchie de CA, directement sous l’autorité de certification racine. Dans ce scénario, l’autorité de certification racine est souvent appelée un CA parent, parce que l’autorité de certification racine a délivré un certificat d’autorité de Certification Subordonnée à la CA de stratégies. En fait, tout CA, qui délivre un certificat à une autre Autorité de certification est désignée comme une autorité de certification parente. L’autorité de certification qui reçoit le certificat d’une autorité de certification parente est connu comme une autorité de certification subordonnée.

Le rôle d’une CA de stratégie est de décrire les politiques et les procédures qu’une organisation implémentent pour garantir son infrastructure à clé publique, les processus qui valident l’identité des détenteurs de certificats et les processus qui appliquent les procédures qui les certificats gérés. Une CA de stratégie émet des certificats seulement à d’autres CAs. Les CAs qui reçoivent ces certificats doivent respecter et appliquer les stratégies que la CA de stratégie a défini.

Si les différentes divisions, secteurs ou sites d’une organisation exigent différentes stratégies d’émission et des procédures, vous devez ajouter autant de stratégie de CAs à la hiérarchie que vous devez définir de politique unique. Par exemple, une organisation peut mettre en œuvre une CA de stratégies pour tous les certificats qu’elle émet en interne aux employés, et une autre pour tous les certificats qu’elle émet aux prestataires.

Une autorité de certification émettrice est généralement située sur le troisième niveau (ou le plus bas) dans une hiérarchie de CA. Une autorité de certification émettrice émet des certificats aux autres ordinateurs, utilisateurs, périphériques réseau, services, ou autres autorités de certification émettrices. Une autorité de certification émettrice est toujours en ligne.

L’autorité de certification parente pour une autorité de certification émettrice peut être une CA de stratégie ou une autre autorité de certification émettrice. L’autorité de certification émettrice doit faire appliquer les politiques et procédures qui sont décrites dans la politique de la CA au-dessus de l’autorité de certification émettrice dans la hiérarchie d’AC.

Note : nous supposons ici qu’une solution 3 tiers est mise en œuvre pour la hiérarchie de certification.

Que sont les certificats racine de confiance ?

Un certificat racine est auto-signé et fournit la plus haute instance de confiance dans une Hiérarchie de CA. L’autorité de certification qui émet le certificat racine est également récipiendaire du certificat. Vous devez ajouter les certificats de CA racine dans un magasin racine de confiance afin de désigner les certificats racine qui sont des autorités de certification de racine approuvées. Les certificats de la chaîne soumise à une autorité de certification de racine approuvée sont approuvés par tous les utilisateurs et les ordinateurs de votre organisation.

Quand un utilisateur, un ordinateur ou un service présente un certificat à une application, l’application détermine si le certificat est délivré par une chaînes de CA de l’un des certificats présents dans le magasin de certificat de confiance racine. Un ordinateur client approuve implicitement l’autorité de certification si elle en chaîne avec un certificat d’une racine de confiance de son magasin.

Il existe plusieurs façons de désigner un certificat racine comme une racine de confiance. Vous pouvez désigner des certificats racine de confiance de la manière suivante :

  • Participer au programme de certificat racine Microsoft. Microsoft inclut un ensemble de certificats racine dans le magasin racine de confiance. Ces certificats racines incluent les certificats racine de société commerciales telle que VeriSign, GTE, Thawte et RSA. Si Microsoft approuve les certificats racine supplémentaires, vous pouvez les télécharger automatiquement.

    Note : il n’est pas nécessaire de garder tous les certificats racine. Microsoft exige seulement cinq certificats racine pour toute signature de code de confiance et opérations de confiance certificat requises pour Windows 2000 ou supérieur. Pour une liste complète des certificats racine de confiance requis, consultez l’Article de la Base de connaissances 293781.

  • Un administrateur local peut ajouter un certificat racine à l’ordinateur local au magasin de racine approuvé en utilisant la console de gestion des certificats. Tous les certificats présents sur l’ordinateur local dans le magasin racine sont approuvés par tous les utilisateurs de cet ordinateur.
  • Un utilisateur peut ajouter un certificat racine à son magasin racine de confiance à l’aide de la console de gestion de certificats. Tous les certificats compris dans la racine de confiance de l’utilisateur sont approuvés uniquement par cet utilisateur.
  • Un administrateur de domaine ou un utilisateur disposant de l’autorisation de modifier la stratégie de groupe peut désigner des certificats racine de confiance pour tous les ordinateurs du site, domaine, ou unité d’organisation où l’objet de stratégie de groupe s’applique.
  • Un administrateur d’entreprise peut publier les certificats racine dans le magasin NTAuth dans le schéma de contexte de configuration d’appellation (Configuration Naming Context). Un membre du Groupe administrateurs de l’entreprise peut publier des certificats d’autorité de certification racine de confiance dans Configuration Naming Context via le conteneur CN = NTAuthCertificates, CN = Public Key Services, CN = Services, CN = Configuration, DC = DomaineRacineForêt à l’aide de la commande certutil.exe.
  • Publier les certificats racine dans le conteneur d’AIA de Configuration Naming Context. Un membre du groupe administrateurs de l’entreprise peut publier dans la racine de confiance Configuration Naming Context via le conteneur CN = AIA, CN = Public Key Services, CN = Services, CN = Configuration,DC = DomaineRacineForêt à l’aide de la commande certutil.exe.

Voilà qui conclut ce premier module. N’hésitez pas à me contacter si vous avez besoin d’éclaircissement !

Lien Permanent pour cet article : https://ms-sec.fr/?p=966

(2 commentaires)

    • Babelew on 8 avril 2017 at 15 h 23 min
    • Répondre

    Merci beaucoup pour cet article. J’ai beaucoup apprécié et j’attends les prochains avec impatience. Tu me donnes envie de me lancer dans la rédaction d’articles dans mon domaines de compétences.

    1. Bonjour,

      Merci beaucoup. Malheureusement, je suis très pris actuellement et je ne peux plus avancer autant que je veux mais je vous encourage vivement à vous lancer dans l’aventure!

      Cdt,
      Loïc.

Laisser un commentaire

Your email address will not be published.

Ce site utilise Akismet pour réduire les indésirables. En savoir plus sur comment les données de vos commentaires sont utilisées.