http://www.bidouilleit.com/wp-content/uploads/2014/06/dessin11-1024x471.png

AUTORITE DE CERTIFICATION – Windows Server 2016

Selon les Bests Pratices Microsoft

 

Contexte

Ce document vise à être une procédure de déploiement basic d’une autorité de certification sous Windows Serveur 2016 en sa version 1703. Disposé d’une autorité de certification au sein de son organisation est d’une importance cruciale en 2018.

En effet, une autorité de certification suppose la mise en place de différents mécanismes permettant la vérification et l’authentification d’une identité sous toutes ses formes. Cela peut être une identité d’ordinateur, d’utilisateur, ou encore de service.

Il s’agit donc de la mise en place d’un certificat SSL, écrit sous un chiffrement suffisamment fort afin d’éviter la casse et de s’assurer de la non répudiation de l’identité en question. La validité des informations étant aujourd’hui particulièrement importante, dans ce tuto nous reviendrons sur plusieurs petites notions, importantes qui permettront de vous proposer un contenu de qualité.

Ce tutoriel sera dans un premier temps réalisé graphiquement, pour de raison d’accessibilité, et sera ensuite décliné dans une seconde version orienté PowerShell pour des raisons d’efficacité et de fonctionnement international.

En effet, le PowerShell proposera une implantation rapide et identique peu importe le langage utilisé. Cependant, pour bien comprendre l’ensemble des mécanismes qui seront associés à la mise en place des services PKI (comprendre autorité de certification).

Objectifs de l’infrastructure

Au sein de ce tutoriel, nous tenterons de créer une autorité de certificat dite racine, qui sera hors domaine, et éteinte. Une autorité de certification secondaire sera également créée, ce qui nous permettra de garantir une sécurité accrue, et une répartition des rôles.

Ces deux services (autorité primaire, autorité secondaire), seront installés sur des machines différentes. Dans notre cas, il s’agit de machines virtuelles qui seront hébergées sous la portail Azure de Microsoft. Ceci n’est absolument pas obligatoire, et vous pouvez utiliser toutes sortes de plateforme d’Hypervision.

Nous disposerons donc :

  • Un domaine skyinfo.local (dont un contrôler de domaine DC1.skyinfo.local)
  • Un scope IP déterminé à l’avance (192.168.0.0 / 24 par exemple)

Voici à quoi ressemblera notre architecture finale :

Installation de l’autorité de certification racine

Comme expliqué plus haut, dans un premier temps nous allons devoir configurer notre autorité de certification racine.

Cette autorité de certification racine sera donc installée sur un serveur Windows 2016 en version 1703, qui sera hors domaine, et sera éteinte une fois que l’autorité secondaire sera installée.

Ce server, que l’on nommera « CA1 » sera donc capable de communiquer avec les machines du domaine.

Pour installer cette autorité racine, de base, veuillez ouvrir votre Gestionnaire de Serveur, et cliquez sur « Ajouter des rôles et des Fonctionnalités » :

On va maintenant choisir le type de services à installer, et on choisira içi l’installation basée sur un rôle ou une fonctionnalité :

On va ensuite choisir le serveur de destination, sur lequel sera installé. En effet, depuis Windows Server 2012 R2, nous avons la possibilité de déployer des services sur des serveurs autres ; tant qu’il sont dans le même domaine. Dans notre cas, nous n’aurons pas de choix particulier à faire, du fait que notre autorité racine ne sera pas dans le domaine :

Dans notre cas, nous aurons besoin de préciser les logins locaux de notre serveur. Dans mon cas, il s’agit d’un compte utilisateur avec des droits d’administration sur le serveur (puisque que notre serveur n’est pas dans le domaine).

Nous allons içi choisir « Certificat Standard », car il faut que notre serveur soit membre d’un domaine afin pouvoir utiliser les certificats d’entreprises. Un certificat d’entreprise sera cependant intéréssant car pourra être connecter à l’Active Directory de Microsoft, afin de publier des certificats à la volée par exemple.

Cependant, dans notre cas, nous resterons en WorkGroup afin de garantir authenticité et performance dans l’exploitation de notre autorité de certification.

On va maintenant choisir « Root  CA » (comprendre : autorité primaire, ou racine), car c’est de ce serveur que dépendra notre autorité dans le domaine, qui ne sera qu’une autorité secondaire :

On va maintenant sélection la création d’une nouvelle clé privée. Cela est nécessaire pour que notre autorité soit légitime, et fonctionne convenablement. Une clé privée est une clé uniquement détenue par le serveur Racine, qui lui donne autorité et légitimité pour fonctionner avec toutes autorité secondaire :

On va sélectionner les options de sécurité de cette clé, en sélectionnant RSA, et SHA265. Cette combinaison est particulièrement efficace, et semble être un choix idéal s’il n’y a pas de besoin particulier en matière de sécurité absolue :

On va maintenant rajouter les options nécessaire à l’identitication de notre autorité de certification. Ces options permettront d’identifier le domaine sans en faire parti, au moment de la publication du certificat.

On rajoutera donc seulement les données dans le champ « Suffixe du Nom Unique » :

On va maintenant choisir la période de validité du certificat. Par défaut cette valeur est à hauteur de 5 ans, ce qui nous va très bien :

On va maintenant choisir où seront stockés les fichiers de configurations de l’autorité de certification :

On valide nos données, et on configure :

On voit donc la progression de notre configuration :

Installation de l’autorité de certification secondaire