ADCS : Comment créer une autorité de certification racine d’entreprise sous Windows Server ?

I. Présentation

Ce tutoriel a pour objectif de vous guider pas à pas dans la mise en place d’une autorité de certification d’entreprise sous Windows Server 2025. Cette procédure s’applique à l’identique sur Windows Server 2022 et d’autres versions antérieures. Avant de commencer la mise en œuvre, nous évoquerons le principe d’une autorité de certification privée et les différentes architectures envisageables.

Grâce à votre autorité de certification privée (que l’on appellera « CA »), vous pourrez gérer vos certificats numériques, de la délivrance d’un certificat à sa révocation. Vous avez aussi la main sur la création et la personnalisation de modèles de certificats. Ensuite, ces certificats pourront être délivrés dans différents scénarios :

• Sécuriser les connexions à un site Intranet en HTTPS, via un certificat TLS
• Passer du LDAP au LDAPS pour les connexions Active Directory
• Réaliser l’authentification VPN
• Mettre en place un serveur NPS (Network Policy Server) avec l’authentification par certificat pour le 802.1X
• Mettre en place des flux sécurisés et chiffrés pour votre serveur WSUS
• Signer des scripts PowerShell
• Etc.

Ceci est possible grâce à l’utilisation à la fois de certificats, mais aussi de clés. C’est pour cela que l’on parle souvent de PKI : Public Key Infrastructure (Infrastructure à clés publiques).

II. Le rôle ADCS de Windows Server

Sous Windows Server, la mise en œuvre d’une autorité de certification s’effectue par l’intermédiaire du rôle ADCS : Active Directory Certificate Services. Il existe des outils open source pour mettre en place une CA sous Unix/Linux. L’autorité de certification est un vaste sujet, relativement complexe, et l’infrastructure cible peut être constituée d’un ou plusieurs serveurs.

Ici, nous allons apprendre à déployer une autorité de certification d’entreprise (intégrée à l’Active Directory) à partir d’un seul serveur. Ce serveur sera toujours en ligne puisqu’il assure l’ensemble des fonctions pour délivrer et révoquer les certificats. S’il est compromis, tous les certificats de l’entreprise seront compromis. C’est un point à considérer.

Cela ne veut pas dire qu’il est impossible de mettre en place une autorité de certification d’entreprise sécurisée à partir d’un seul serveur. Tout est une question de configuration, notamment de permissions pour l’accès aux modèles. Pour respecter les bonnes pratiques de Microsoft, il est recommandé d’avoir au moins deux serveurs, afin de mettre en place la hiérarchie suivante :

• Une autorité de certification racine, créée sur un serveur autonome (en Workgroup) et qui sera éteint à la fin de la configuration (il conviendra de l’allumer seulement « de temps en temps » pour les mises à jour et l’actualisation de la liste de révocation).
• Une autorité de certification intermédiaire, créée sur un serveur intégré au domaine Active Directory, et qui sera constamment allumé. En cas de compromission ou d’indisponibilité, il sera facile de supprimer et de remplacer ce serveur. Elle est utilisée pour délivrer les certificats utilisateurs et ordinateurs.

La première autorité de certification (racine) peut être autonome ou d’entreprise. Nous allons créer une autorité de certification d’entreprise pour bénéficier de son intégration à l’AD, ce qui simplifie la gestion. L’autre avantage, c’est de bénéficier de la prise en charge des modèles de certificats (différentes configurations de certificats avec chacune leurs paramètres).

III. Installer le rôle ADCS

Dans ce tutoriel sous Windows Server 2025, nous allons créer et installer l’autorité de certification racine, sur le serveur « SRV-CA-ROOT », intégré au domaine Active Directory. Le domaine Active Directory « it-connect.local » est associé à deux contrôleurs de domaine (« SRV-ADDS-01 » et « SRV-ADDS-02« ). Il s’agit du modèle de déploiement « le plus simple » basé sur un seul serveur.

La première étape consiste à installer le rôle ADCS sur le serveur « SRV-CA-ROOT« . Pour cela, ouvrez le Gestionnaire de serveur et ajoutez un rôle à partir de l’assistant habituel…

Avancez jusqu’à l’étape « Rôles de serveurs » afin de cocher l’option « Services de certificats Active Directory« .

Puis, avancez jusqu’à l’étape « Services de rôle » où vous n’aurez qu’à cocher « Autorité de certification« .

Avancez jusqu’à la fin et lancez l’installation. Quand c’est terminé, cliquez sur le bouton « Fermer« .

Sachez qu’à ce moment précis, vous pouvez créer un fichier nommé « CAPolicy.inf » (dans « C:\Windows« ) sur votre serveur ADCS. Vous pouvez éditer le fichier avec le Bloc-notes. Ce fichier sert à préconfigurer certaines options de l’autorité de certification que nous allons créer.

• Voici un exemple, à titre purement indicatif

Poursuivez la configuration via le lien « Configurer les services de certificats Active Directory » visible dans le Gestionnaire de serveur.

La partie installation du rôle s’arrête ici, ensuite, nous allons créer l’autorité de certification racine.

IV. Créer l’autorité de certification racine

Cliquez directement sur le bouton « Suivant » si vous êtes connecté avec un compte administrateur. Sinon, cliquez sur le bouton « Modifier » pour sélectionner un compte.

Plusieurs rôles sont proposés, sélectionnez uniquement « Autorité de certification« .

Sélectionnez ensuite « Autorité de certification d’entreprise » et poursuivez. Ce choix est fait, car nous sommes en environnement Active Directory et que nous utilisons qu’un seul serveur. Dans le cas où une hiérarchie de CA est mise en place, cette première autorité de certification sera configurée en tant que CA autonome, puis la CA intermédiaire déployée sur un second serveur, serait une autorité de certification d’entreprise.

Comme il s’agit de la première Autorité de certification de notre infrastructure, sélectionnez l’option « Autorité de certification racine« .

Nous allons créer une nouvelle clé privée, car nous partons de zéro.

Pour sécuriser notre clé privée avec un algorithme de hachage suffisamment robuste, sélectionnez « SHA512 » et utilisez « 4096 » comme longueur de clé. Ce sont des valeurs adéquates pour l’autorité de certification racine. Dans tous les cas, sachez que le SHA1 est déprécié par Microsoft depuis janvier 2017, il convient donc de l’éviter.

Indiquez un nom pour votre autorité de certification, il s’agit d’un nom qui sera indiqué dans les différents certificats que vous allez émettre avec votre CA. Prenez le temps de remplir correctement ces informations.

Spécifiez la durée de validité du certificat généré pour votre CA, par défaut la valeur est de 5 années. Vous pouvez indiquer « 10 » au lieu de « 5« .

Laissez par défaut les chemins indiqués pour stocker la base de données des certificats et les logs associés. Poursuivez directement.

Il ne vous reste plus qu’à valider et après quelques minutes, vous devriez obtenir un message de succès avec le texte « Configuration réussie« .

La console « Autorité de certification » disponible dans le menu « Outils » du Gestionnaire de serveur, vous permettra de gérer votre autorité de certification. PowerShell est également votre allié, comme l’outil en ligne de commande « certutil.exe« .

Effectuez un clic droit sur le nom de la CA, à savoir « IT-Connect-CA-Root » puis cliquez sur « Propriétés« . Ensuite, cliquez sur le bouton « Afficher le certificat« . Ici, vous pouvez constater que le certificat racine de la CA est bien valide 10 ans.

V. L’autorité de certification est-elle inscrite dans l’AD ?

Puisque nous avons choisi de créer une autorité de certification d’entreprise, la CA est automatiquement inscrite dans l’AD lors de sa création. À l’inverse, ceci n’est pas le cas avec une CA autonome.

Dans l’Active Directory, vous pouvez voir que le compte ordinateur de la machine « SRV-CA-ROOT » est désormais membre du groupe de sécurité « Éditeurs de certificats » (« Cert Publishers« , en anglais). Vous pouvez en profiter pour supprimer le compte ordinateur de ce groupe, car cette permission est utile uniquement le temps de l’installation.

La CA est aussi inscrite dans l’annuaire au sein d’un conteneur nommé « Certification Authorities« . Ouvrez la console « Modification ADSI » (adsiedit.msc) avec le contexte « Configuration« , puis parcourez l’arborescence comme ceci : Configuration > Services > Public Key Services > Certification Authorities. Ici, notre CA apparaît bien :

Remarque : dans l’Active Directory, « CDP » est le container avec les informations de la liste de révocation de certificats, tandis que « Enrollment Services » fournit les informations aux clients pour contacter l’autorité afin de faire une demande.

VI. Faut-il déployer le certificat de l’autorité racine sur les machines ?

Nous avons créé une autorité de certification racine d’entreprise inscrit dans l’Active Directory. De ce fait, le certificat de la CA sera automatiquement distribué aux postes de travail et aux serveurs membres du domaine AD. Nous pouvons le vérifier assez rapidement…

Ouvrez la console « certmgr.msc » sur une machine du domaine. Vous verrez ainsi que le certificat de votre CA est placé dans le magasin nommé « Autorités de certification racines de confiance« . Regardez :

Il n’est donc pas nécessaire d’exporter ce certificat afin de le déployer par GPO.

VII. La publication de la liste de révocation

Chaque certificat a une durée de vie limitée et un certificat peut être révoqué à tout moment (suite à l’action d’un administrateur, par exemple). De ce fait, au-delà d’émettre des certificats, l’autorité de certification doit aussi mettre à disposition des machines la liste des certificats révoquées. Cette liste est appelée CRL : Certificate Revocation List. Les emplacements où est stockée la CRL sont appelés CDP : CRL Distribution Point. À cela s’ajoute les emplacements des certificats d’autorité de certification, que l’on appelle AIA : Authority Information Access, soit l’Accès aux informations de l’autorité.

Par défaut, les informations sont publiées dans l’Active Directory et le chemin LDAP est précisé dans les certificats délivrés par la CA. De ce fait, les machines du domaine AD pourront accéder à cette liste. En revanche, elle ne sera pas accessible aux machines qui ne sont pas membres du domaine. Ceci peut nécessiter la mise en œuvre d’un serveur IIS (de préférence différent du serveur ADCS) afin de publier la CRL et la rendre accessible via le protocole HTTP.

La configuration s’effectue via les propriétés de la CA, à partir de l’onglet « Extensions« .

• Points de distribution de liste de révocation des certificats (CDP) – Configuration par défaut

• Accès aux informations de l’autorité (AIA) – Configuration par défaut

En plus d’une publication dans l’AD, la CRL est aussi publiée sur le disque local de l’autorité de certification.

VIII. Conclusion

Mission accomplie ! L’autorité de certification racine d’entreprise est désormais installée ! Désormais, vous êtes en mesure d’installer le rôle ADCS sur Windows Server. La prochaine étape sera la configuration de la CA et le déploiement de vos premiers certificats, à partir d’un modèle existant ou d’un nouveau modèle personnalisé. Prêtez une attention particulière aux permissions sur les modèles, car ils peuvent exposer la CA à des risques de compromission.

Prochainement, nous vous proposerons plus de contenus sur l’installation et la configuration d’ADCS en respectant les bonnes pratiques de sécurité.