Concevoir et implémenter AD CS

Il est essentiel de s’assurer que vous concevez votre autorité de certification interne de façon optimale. Votre conception aura des implications significatives sur la sécurité et les aspects opérationnels de votre environnement d’infrastructure à clé publique.

Conception d’une hiérarchie basée sur AD CS

Avant d’implémenter AD CS, vous devez d’abord concevoir votre hiérarchie d’autorités de certification. Dans le cadre de votre conception, vous devez déterminer le nombre de niveaux d’autorité de certification dont vous avez besoin et quel sera le rôle de l’autorité de certification dans chaque niveau. Nous vous déconseillons de générer une hiérarchie d’autorités de certification de plus de trois niveaux, sauf si elle se trouve dans un environnement complexe, hautement sécurisé ou distribué. La plupart du temps, les hiérarchies d’autorités de certification ont deux niveaux, avec l’autorité de certification racine au niveau supérieur et une autorité de certification émettrice secondaire au deuxième niveau. En règle générale, vous utilisez l’autorité de certification racine pour générer la hiérarchie d’autorités de certification. Dans ce cas, l’autorité de certification racine reste hors connexion lorsque vous vous appuyez sur l’autorité de certification secondaire pour émettre et gérer des certificats.

Voici quelques conceptions d’autorité de certification plus complexes :

• Hiérarchies d’autorités de certification avec une autorité de certification de stratégie. Les autorités de certification de stratégie sont des autorités de certification secondaires se trouvant directement sous l’autorité de certification racine et au-dessus des autres autorités de certification secondaires dans une hiérarchie d’autorités de certification. Vous utilisez des autorités de certification de stratégie pour émettre des certificats d’autorité de certification pour leurs autorités de certification secondaires. Les certificats d’autorité de certification reflètent les stratégies et les procédures qu’une organisation implémente pour sécuriser son infrastructure à clé publique, les processus qui valident l’identité des détenteurs de certificats et les processus qui appliquent les procédures de gestion des certificats. Une autorité de certification de stratégie émet un certificat uniquement vers d’autres autorités de certification. Les autorités de certification qui reçoivent ces certificats doivent respecter et appliquer les stratégies définies par l’autorité de certification de stratégie. L’utilisation d’autorités de certification de stratégie n’est pas obligatoire, à moins que des divisions, des secteurs ou des emplacements différents de votre organisation ne nécessitent des stratégies et des procédures d’émission différentes. Par exemple, une organisation peut implémenter une autorité de certification de stratégie pour tous les certificats qu’elle émet en interne pour les employés et une autre autorité de certification de stratégie pour tous les certificats qu’elle émet pour les sous-traitants.
• Hiérarchies d’autorités de certification avec certification croisée de confiance. Dans ce scénario, deux hiérarchies d’autorités de certification indépendantes interopèrent lorsqu’une autorité de certification dans une hiérarchie émet un certificat d’autorité de certification croisée pour une autorité de certification dans une autre hiérarchie. Dans ce cas, vous établissez une confiance mutuelle entre des hiérarchies d’autorités de certification différentes.

Autorités de certification autonomes et d’entreprise

Lorsque vous utilisez AD CS, vous pouvez déployer deux types d’autorités de certification : autonome et entreprise. Ces types d’autorités de certification ne concernent pas la hiérarchie, mais plutôt des fonctionnalités et de l’intégration avec AD DS. Une autorité de certification autonome ne dépend pas d’AD DS. Une autorité de certification d’entreprise requiert AD DS pour fournir des fonctionnalités supplémentaires, telles que l’inscription automatique. L’inscription automatique permet aux utilisateurs du domaine et aux appareils joints à un domaine de s’inscrire automatiquement pour les certificats une fois que vous avez activé l’inscription automatique des certificats via la stratégie de groupe.

Le tableau suivant détaille les différences les plus importantes entre les autorités de certification autonomes et d’entreprise.

Une autorité de certification racine d’entreprise est le choix le plus courant lors du déploiement d’une autorité de certification unique dans un environnement AD DS. Si vous déployez une hiérarchie à deux niveaux avec une autorité de certification secondaire dans un environnement AD DS, vous devez envisager d’utiliser une autorité de certification racine autonome en tant qu’autorité de certification racine. Cela vous permet de la mettre hors connexion sans affecter le processus de gestion des certificats pour les utilisateurs de domaine et les appareils joints à un domaine.

Un autre point à prendre en compte est le type d’installation du système d’exploitation. L’Expérience utilisateur et les scénarios d’installation Server Core prennent en charge AD CS. Server Core minimise la surface potentielle du pirate et la surcharge de maintenance du système d’exploitation, ce qui en fait le choix optimal pour AD CS dans un environnement d’entreprise.

De plus, vous devez garder à l’esprit que vous ne pouvez pas modifier les noms d’ordinateur, le nom de domaine ou l’appartenance à un domaine d’ordinateur après avoir déployé une autorité de certification de n’importe quel type sur cet ordinateur. Par conséquent, il est important de configurer ces paramètres avant le déploiement.

Certaines considérations spécifiques au déploiement d’une autorité de certification racine autonome hors connexion sont également disponibles :

• Avant d’émettre un certificat secondaire à partir de l’autorité de certification racine, assurez-vous de fournir au moins un point de distribution de liste de révocation de certificats (CDP) et un emplacement AIA qui seront disponibles pour tous les clients. Cela est dû au fait que, par défaut, le CDP et l’AIA se trouvent sur une autorité de certification racine autonome elle-même. Par conséquent, lorsque vous déconnectez l’autorité de certification racine du réseau, une vérification de la révocation échoue, car le CDP et les emplacements AIA ne sont pas accessibles. Lorsque vous définissez ces emplacements, vous devez copier manuellement les informations de liste de révocation de certificats et d’AIA à cet emplacement.
• Définissez une période de validité pour les listes de révocation de certificats que l’autorité de certification racine publie sur une longue période de temps, un an par exemple. Cela signifie que vous devrez activer l’autorité de certification racine une fois par an pour publier une nouvelle liste de révocation de certificats, puis que vous devrez la copier dans un emplacement disponible pour les clients. Si vous ne le faites pas, après l’expiration de la liste de révocation de certificats de l’autorité de certification racine, les vérifications de révocation de tous les certificats échoueront également.
• Utilisez Stratégie de groupe pour publier le certificat d’autorité de certification racine dans un magasin d’autorités de certification racine approuvé sur tous les ordinateurs serveurs et clients. Vous devez le faire manuellement, car une autorité de certification autonome ne peut pas le faire automatiquement, contrairement à une autorité de certification d’entreprise. Vous pouvez également publier le certificat d’autorité de certification racine sur AD DS à l’aide de l’outil en ligne de commande certutil.

Démonstration

La vidéo suivante montre comment :

• Configurer les composants requis pour une autorité de certification racine d’entreprise.
• Déployer une autorité de certification racine d’entreprise.

Les principales étapes du processus sont les suivantes :

1. Créer un environnement AD DS. Créer une forêt AD DS à un domaine.
2. Configurer les composants requis pour une autorité de certification racine d’entreprise. Installer le rôle serveur et les services de rôle serveur requis.
3. Déployer une autorité de certification racine d’entreprise. Configurer les paramètres de l’autorité de certification racine d’entreprise.