PKI – Autorité de certification Windows Server 2016 – Meilleures pratiques MS | pirater – Serveur d’impression

AUTORITÉ DE CERTIFICATION – Windows Server 2016

Selon Microsoft Practice Bests

Ce document est destiné à être une procédure de déploiement de base pour une autorité de certification Windows Server 2016 dans sa version 1703. Avoir une autorité de certification au sein de son organisation est de la plus haute importance en 2018.

En effet, une autorité de certification suppose la mise en place de divers mécanismes permettant de vérifier et d’authentifier une identité sous toutes ses formes. Cela peut être une identité d'ordinateur, une identité d'utilisateur ou même une identité de service.

Il s’agit donc de la mise en œuvre d’un certificat SSL, écrit sous un cryptage suffisamment fort pour éviter les ruptures et assurer la non répudiation de l’identité en question. La validité de l’information étant particulièrement importante aujourd’hui, nous allons revenir dans ce didacticiel sur plusieurs notions importantes qui vous permettront de proposer un contenu de qualité.

Ce didacticiel sera initialement effectué sous forme graphique, pour des raisons d'accessibilité, puis sera décliné dans une deuxième version orientée PowerShell pour des raisons d'efficacité et de fonctionnement international.

En effet, le PowerShell proposera une implantation rapide et identique quelle que soit la langue utilisée. Cependant, pour bien comprendre tous les mécanismes qui seront associés à la mise en place de services PKI (comprendre l’autorité de certification).

Dans ce didacticiel, nous allons essayer de créer une autorité de certification appelée racine, qui sera hors du domaine et désactivée. Une autorité de certification secondaire sera également créée, ce qui nous permettra d’assurer une sécurité accrue et une répartition des rôles.

Ces deux services (autorité principale, autorité secondaire) seront installés sur des machines différentes. Dans notre cas, ce sont des machines virtuelles qui seront hébergées sous le portail Azure de Microsoft. Ce n'est absolument pas obligatoire et vous pouvez utiliser toutes sortes de plateformes Hypervision.

Nous aurons:

• Un domaine skyinfo.local (y compris un contrôleur de domaine DC1.skyinfo.local)
• Une étendue IP déterminée à l'avance (192.168.0.0 / 24 par exemple)

Voici à quoi ressemblera notre architecture finale:

Comme expliqué ci-dessus, nous devrons d’abord configurer notre autorité de certification racine.

Cette autorité de certification racine sera donc installée sur un serveur Windows 2016 version 1703, qui sera hors du domaine, et sera arrêté une fois l'autorité secondaire installée.

Ce serveur, que nous appellerons "CA1", pourra communiquer avec les machines du domaine.

Pour installer cette racine, autorité de base, ouvrez votre gestionnaire de serveur, puis cliquez sur "Ajouter des rôles et des fonctionnalités":

Nous allons maintenant choisir le type de services à installer, et nous choisirons ici l'installation en fonction d'un rôle ou d'une fonctionnalité:

Nous choisirons ensuite le serveur de destination sur lequel sera installé. Depuis Windows Server 2012 R2, nous avons la possibilité de déployer des services sur d'autres serveurs. tant qu'ils sont dans le même domaine. Dans notre cas, nous n'aurons pas de choix particulier à faire, car notre autorité racine ne sera pas dans le domaine:

Dans notre cas, nous devrons spécifier les identifiants locaux de notre serveur. Dans mon cas, il s’agit d’un compte utilisateur doté de droits d’administration sur le serveur (notre serveur n’appartenant pas au domaine).

Nous choisirons "Certificat standard" car notre serveur doit être membre d'un domaine pour pouvoir utiliser des certificats commerciaux. Toutefois, un certificat commercial sera intéressant car il peut être connecté à Microsoft Active Directory, par exemple pour publier des certificats à la volée.

Cependant, dans notre cas, nous resterons dans le groupe de travail pour assurer l’authenticité et la performance du fonctionnement de notre autorité de certification.

Nous allons maintenant choisir "Root CA" (comprendre: autorité principale ou racine), car c’est ce serveur qui dépendra de notre autorité sur le terrain, qui sera une autorité secondaire:

Nous allons maintenant sélectionner la création d'une nouvelle clé privée. Cela est nécessaire pour que notre autorité soit légitime et fonctionne correctement. Une clé privée est une clé uniquement détenue par le serveur Racine, ce qui lui donne autorité et légitimité pour travailler avec toute autorité secondaire:

Nous allons sélectionner les options de sécurité pour cette clé en sélectionnant RSA et SHA265. Cette combinaison est particulièrement efficace et semble constituer un choix idéal s’il n’ya pas de besoin particulier de sécurité absolue:

Nous allons maintenant ajouter les options nécessaires à l'identité de notre autorité de certification. Ces options identifieront le domaine sans en faire partie au moment de la délivrance du certificat.

Nous ajouterons uniquement les données dans le champ "Suffixe du nom unique":

Nous allons maintenant choisir la période de validité du certificat. Par défaut cette valeur va jusqu'à 5 ans, ce qui nous convient très bien:

Nous allons maintenant choisir où seront stockés les fichiers de configuration de l'autorité de certification:

Nous validons nos données et configurons:

Nous voyons la progression de notre configuration: