Configuration d'une infrastructure à clés publiques à 2 niveaux sous Windows 2008 (R2)

Michaël Todorovic

Ce document va vous permettre de mettre en place une infrastructure à clés publiques (aussi nommée PKI) à deux niveaux grâce à Microsoft Windows 2008. Cette PKI pourra vous être utile dans beaucoup de cas : serveur web sécurisé, serveur de messagerie sécurisé, distribution automatisée de certificats aux utilisateurs de l'Active Directory, etc
Commentez

- Titre : Configuration d'une infrastructure à clés publiques à 2 niveaux sous Windows 2008 (R2)

- Auteur : Michaël Todorovic

- Parution : 18 novembre 2009

- Mise à jour : 15 juin 2010

- Licence : Copyright ® 2009 Michaël Todorovic. Aucune reproduction, même partielle, ne peut être faite de ce site et de l'ensemble de son contenu : textes, documents, images, etc. sans l'autorisation expresse de l'auteur. Sinon vous encourez selon la loi jusqu'à trois ans de prison et jusqu'à 300 000 € de dommages et intérêts.

Sommaire

- I. Introduction

- II. Architecture

- II-A. Autorité autonome ou entreprise ?

- II-A-1. Autonome

- II-A-2. Entreprise

- II-A-3. Recommandations de Microsoft

- II-B. DNS : Point crucial de votre infrastructure

- II-B-1. Nommage des serveurs

- II-B-2. Nom de domaine privé/public ?

- II-B-3. Utilisation du split-dns

- II-C. Architecture suggérée

- II-C-1. Schéma

- II-C-2. Fonctionnement

- III. Mise en place

- III-A. Autorité autonome racine (offline)

- III-A-1. Création du fichier CAPolicy.inf

- III-A-2. Installation de l'autorité

- III-A-3. Configuration post-installation

- III-A-4. Publication

- III-B. Autorité secondaire d'entreprise

- III-B-1. Création du fichier CAPolicy.inf

- III-B-2. Installation de l'autorité

- III-B-3. Certification de l'autorité secondaire par l'autorité racine

- III-B-4. Activation de l'autorité

- III-B-5. Configuration après le premier démarrage

- III-B-6. Activation des attributs SAN

- IV. Renouvellement des autorités de certification

- V. Conclusion

- VI. Remerciements

I - Introduction

Dans cet article, je ne parlerai pas dans le détail du principe de la PKI (Public Key Infrastructure). En deux mots et pour les très pressés, une PKI sert à générer des certificats de toute sorte utilisables dans votre réseau d'entreprise à n'importe quel niveau (réseau ou applicatif). La PKI deviendra ou est devenue un composant important au sein des réseaux : des produits tels que Exchange ou Office Communication Server requièrent des certificats. Une autorité de certification est gérable à la main pour quelques certificats mais cela devient plus compliqué avec un nombre de certificats grandissant. Nous allons voir comment mettre en place l'autorité de certification disponible dans Windows Server. Je vais me placer dans un réseau disposant d'un contrôleur de domaine Active Directory. Les serveurs fonctionnent avec Windows Server 2008 R2 Standard. L'installation et la configuration sont identiques sous Windows 2008. Le principe reste identique sous Windows 2003, seul l'agencement des fenêtres de configuration diffère.

On ne fait pas de PKI pour la beauté du geste ! Il est important de penser à l'utilisation que vous souhaitez en faire et aux évolutions potentielles de votre réseau. Avant de commencer à monter votre PKI, essayez de savoir s'il est prévu de fournir des services sécurisés sur Internet à des partenaires ou des clients. Si oui, cela va profondément changer votre PKI. Je parlerai de ce cas afin que l'article soit le plus complet possible. L'adaptation pour une PKI ne fournissant pas de certificats publics est très simple : il vous suffira de changer le nom de domaine public utilisé en nom de domaine privé.

II - Architecture

Tous les FQDN et noms de domaines utilisés ne sont pas réels et sont pris à titre d'exemple seulement.

Une PKI à deux niveaux requiert deux serveurs de certification. Le premier serveur sera la racine de notre infrastructure : il va s'auto-certifier. On parle de racine puisque les certificats sont gérés sous forme d'arbre. Le deuxième serveur, approuvé par la racine, va délivrer des certificats au réseau. L'autorité racine est complètement indépendante du réseau et du domaine Active Directory. Cette autorité doit être éteinte et placée en sécurité pour éviter tout vol de sa clé privée. Si cette autorité est compromise alors toutes les autorités inférieures ainsi que tous les certificats peuvent être compromis. Il faudra alors tout révoquer pour régénérer de nouveaux certificats.
La deuxième autorité de certification est intégrée au domaine Active Directory. Cela va lui permettre de délivrer des certificats aux utilisateurs ou serveurs connus dans l'Active Directory. Pour des raisons de sécurité, il est conseillé de placer l'autorité de certification sur un serveur indépendant. Bien qu'il soit possible d'installer l'autorité sur un contrôleur de domaine, ce n'est pas conseillé. Nous aurons donc trois serveurs : une autorité racine totalement indépendante et éteinte, un contrôleur de domaine et une autorité de délivrance intégrée au domaine Active Directory.

Architecture de la PKI 2 niveaux

Windows 2008 est utilisé pour le contrôleur de domaine. Le niveau fonctionnel du domaine n'a pas d'influence sur le fonctionnement de la PKI. Vous pouvez également utiliser Windows 2003, la méthode d'installation et de configuration est quasiment identique : seules les fenêtres de configuration ne sont pas identiques. Il n'y a que peu de différences avec Windows 2008 R2. Vous aurez également besoin d'un DNS fonctionnel. Afin de rendre vos certificat racine et liste de révocation disponibles sur votre réseau, vous devrez mettre en place un serveur web hébergeant ces fichiers. Il est nécessaire de fixer les chemins d'accès à ces fichiers au préalable et de s'y conformer. Si les fichiers ne sont pas accessibles via les chemins déterminés, votre PKI fonctionnera mal. Lorsque vous commencerez à installer la PKI, vous aurez le choix entre deux types d'autorité.

II-A - Autorité autonome ou entreprise ?

Le choix doit être réfléchi puisque vous n'aurez pas la possibilité de changer simplement le type de votre autorité. Si vous décidez de changer, vous devrez supprimer votre autorité pour la réinstaller. Cela n'est pas sans risque, notamment au niveau de la conservation des clés.

II-A-1 - Autonome

Voici les scénarios d'utilisation d'une autorité autonome (standalone) :

- Utilisable pour une autorité éteinte racine ou intermédiaire

- Pas besoin de personnaliser les modèles de certificats

- Besoin d'une forte sécurité et politique d'approbation

- Peu de certificats à approuver et le travail requis pour l'approbation est acceptable

- Clients hétérogènes et ne pouvant pas bénéficier d'un accès à Active Directory

- Certification à travers le protocole SCEP pour les routeurs

Si votre PKI doit délivrer des certificats pour un nombre limité de clients (quelque soit leur type) et que vous souhaitez une approbation manuelle, l'autorité autonome sera sans doute le meilleur choix. Attention cependant à l'évolutivité de votre réseau. Si à plus ou moins long terme vous souhaitez augmenter le nombre de clients (serveurs, utilisateurs, routeurs), il sera sans doute plus intéressant de commencer dès maintenant avec une autorité entreprise.

II-A-2 - Entreprise

Voici les scénarios d'utilisation d'une autorité entreprise :

- Un grand nombre de certificats devra être approuvé automatiquement

- La disponibilité et la redondance sont requises

- Les clients utilisent Active Directory

- L'approbation automatique doit être modifiée

- Les modèles de certificats doivent être modifiés, dupliqués ou créés

- L'archivage et la restauration des clés dans un dépôt spécifique

Si votre PKI doit délivrer un nombre important de certificats et que vous souhaitez avoir le choix entre une délivrance manuelle ou automatique des certificats, vous choisirez une autorité entreprise. Cette dernière s'intègre dans Active Directory ce qui permet de gérer des droits d'accès basés sur les objets Active Directory.

II-A-3 - Recommandations de Microsoft

Voici un tableau résumant les recommandations de Microsoft quant au type d'autorité à utiliser selon le type de l'autorité (racine, intermédiaire, délivrance).

Type de l'autorité

3 niveaux

2 niveaux

1 niveau

Racine offline

Standalone

Standalone

Entreprise

Intermédiaire offline

Standalone

Délivrance online

Entreprise

Entreprise

II-B - DNS : Point crucial de votre infrastructure

II-B-1 - Nommage des serveurs

Le serveur rootca est totalement indépendant et ne devra pas être connecté au réseau. Il faudra cependant un média pour récupérer le certificat racine ainsi que la liste de révocation associée. Ce média servira également à transférer le certificat permettant l'activation de l'autorité de distribution. Nous avons trois serveurs : contrôleur de domaine, serveur web et autorité de certification. Le serveur web est un composant essentiel dans une PKI puisqu'il va permettre aux clients de récupérer les listes de révocation ainsi que le certificat racine permettant d'établir une confiance envers les serveurs de l'entreprise. Nous utiliserons les noms suivants pour les serveurs :

- Contrôleur de domaine : domain-controller.developpez.adds

- Autorité de certification : ca.developpez.adds

- Serveur web : services.developpez.com

II-B-2 - Nom de domaine privé/public ?

Pourquoi utiliser developpez.adds et developpez.com ? developpez.adds est le nom de domaine Active Directory et n'est donc pas accessible sur Internet. developpez.com est un nom de domaine public donc accessible sur Internet. Une PKI peut être utile pour proposer des services sécurisés à des clients qui connaissent votre société. Il suffira que les clients téléchargent le certificat racine pour faire confiance à vos services sécurisés. Cela va s'avérer utile pour des solutions de portails client (basés sur Sharepoint par exemple) ou pour faire des téléconférences grâce à Office Communication Server. Il est donc conseillé de placer les certificats et les listes de révocation de votre autorité racine et de distribution sur un serveur accessible portant un nom public. Ce serveur pourra être publié ou non sur Internet selon votre utilisation. Il sera plus confortable d'utiliser dès le début un nom public pour ce serveur : vous n'aurez pas à modifier vos autorités de manière conséquente en cas de changement. Notre serveur web qui met à disposition les certificats des autorités et les listes de révocation devra être accessible depuis votre réseau interne comme depuis Internet. Afin d'éviter à vos postes internes d'aller sur Internet pour aller chercher un certificat racine ou la liste de révocation, nous utiliserons un "split-DNS".

II-B-3 - Utilisation du split-dns

Le split-dns consiste en l'utilisation de deux serveurs DNS au lieu d'un pour desservir une zone particulière. Dans notre cas, nous allons utiliser deux serveurs DNS pour la zone developpez.com. Un des serveurs DNS sera utilisé pour les clients de votre réseau interne et le deuxième serveur sera utilisé pour les clients venant d'Internet. Typiquement, nous allons ajouter la zone developpez.com dans le DNS de l'Active Directory. Ce DNS étant connu uniquement des postes internes, les postes Internet n'y auront pas accès et utiliseront le DNS public. Votre DNS de l'Active Directory contiendra la zone publique developpez.com et contiendra des enregistrements pointant vers vos serveurs internes (avec des IP privées). Votre DNS étant inaccessible depuis Internet, les postes Internet ne sauront pas que votre serveur de publication de liste de révocation sera en 10.0.0.1 par exemple. Mais comment font les postes internes ? Vos postes internes sont configurés avec le DNS de l'Active Directory. Ce dernier étant autoritaire sur la zone developpez.com (interne), vos postes vont récupérer les IP privées. Nous allons créer les mêmes enregistrements dans la zone privée et la zone publique. Ces derniers porteront les mêmes noms mais pas les mêmes valeurs. D'une manière logique, la zone hébergée par Active Directory contiendra des enregistrements à IP privée alors que la zone publique (qu'elle soit gérée par vous ou votre fournisseur de domaine) contiendra les IP publiques de vos serveurs publiés.

II-C - Architecture suggérée

II-C-1 - Schéma

L'architecture réseau est classique avec une DMZ et un LAN. Dans la DMZ, nous mettons le serveur web qui distribuera les listes de révocation et le certificat racine afin que les clients externes à notre entreprise puissent faire confiance à nos services sécurisés. Je n'ai pas inclus dans cet exemple de solution de type reverse-proxy mais le fonctionnement reste identique. Si votre entreprise a choisi d'héberger elle-même le DNS public gérant votre domaine, il se trouvera en DMZ. L'Active Directory, le DNS interne et votre serveur de certificats seront dans le LAN.

II-C-2 - Fonctionnement

Pour valider les certificats émis par votre PKI, les clients internes vont utiliser le certificat racine stocké dans leur magasin de certificats d'autorités de certification racines de confiance. Le certificat racine de votre PKI sera distribué par Active Directory. Pour finaliser la validation des certificats émis par votre PKI, les clients internes iront demander l'IP du serveur de listes de révocation auprès du DNS hébergé sur l'Active Directory. Ce dernier va renvoyer l'IP privée du serveur web hébergé en DMZ. Les clients iront alors télécharger les listes de révocation sur ce serveur.

Pensez à contrôler que vos postes clients sont autorisés à communiquer avec la DMZ au niveau du firewall en HTTP ou HTTPS selon la configuration de votre serveur web.

Votre architecture Active Directory n'est pas disponible sur Internet. Qui plus est, les clients Internet ne seraient pas autorisés sur l'Active Directory. Les clients ne pourront pas récupérer automatiquement le certificat racine de votre PKI. Il faut donc mettre ce dernier à disposition sur votre serveur web pour que les clients puissent authentifier vos différents services web publics. Les clients demanderont alors la résolution de noms auprès de votre DNS public. Ils pourront alors télécharger et installer votre certificat racine et récupérer les listes de révocation afin de valider la confiance envers vos serveurs.

III - Mise en place

III-A - Autorité autonome racine (offline)

III-A-1 - Création du fichier CAPolicy.inf

Avant de lancer l'installation de l'autorité racine, il faut créer un fichier de configuration nommé CAPolicy.inf. Vous devez créer ce fichier dans le répertoire %windir% (habituellement C:\Windows). Ce fichier va permettre de personnaliser le comportement de votre autorité. Il est très important que ce fichier soit correctement renseigné sinon votre PKI risque de ne pas fonctionner normalement. Je vais utiliser ici les recommandations Microsoft en terme de longueur et durée de vie de la clé de votre autorité. Libre à vous de changer mais gardez à l'esprit que cette longueur est une puissance de deux. Il sera également indiqué l'emplacement de votre politique de certification. Prenez bien garde à la rédaction puisque c'est ce texte qui va dire aux utilisateurs de votre autorité quel est le processus de certification (entre autres).

La première section du fichier de configuration est standard et ne doit pas être changée. Elle est obligatoirement présente dans votre fichier. Même si la tentation est forte, ne modifiez pas "Windows NT" en "Windows 2008" ou autre.

[version]
Signature="$Windows NT$"

On peut ensuite commencer à préciser la configuration de l'autorité. Lorsqu'il va falloir renouveler la clé, il faut connaitre la longueur de cette clé ainsi que sa nouvelle durée de vie. Par défaut, on créera une clé de 4096 bits et d'une durée de vie de 20 ans. Cette durée peut paraître énorme mais cette autorité est destinée à rester éteinte et stockée en lieu sûr. Elle ne va certifier que des autorités lors de la création de votre PKI donc cette durée de vie peut-être longue.

[Certsrv_server]
RenewalKeyLength=4096
RenewalValidityPeriod=Years
RenewalValidityPeriodUnits=20

Les valeurs Period peuvent être Days, Weeks, Months ou Years. Les PeriodUnits sont obligatoirement des entiers. Vous ne pouvez pas mettre 0,5 Years pour dire 6 mois. Il faudra utiliser 6 Months.

Nous devons maintenant contrôler la durée de vie des listes de révocation et des listes de révocation différentielles. Une liste de révocation a une durée de vie obligatoirement plus importante que celle d'une liste de révocation différentielle. Il est possible d'utiliser une durée de vie égale à celle de la clé de l'autorité. Je préfère limiter cette durée à 15 ans. La liste de révocation différentielle a une durée de vie de 10 ans.

CRLPeriod=Years
CRLPeriodUnits=15
CRLDeltaPeriod=Years
CRLDeltaPeriodUnits=10

Nous allons ensuite déclarer notre politique de certification. Notez que la valeur de Policies est le nom de la section suivante. Vous pouvez donc donner n'importe quelle valeur à Policies tant que la section du même nom existe. Il faut également indiquer l'adresse où le texte correspondant à la politique de certification peut être trouvé. L'OID correspond au modèle de certificat délivré par l'autorité. Ici, il s'agit de tous les modèles disponibles.

[PolicyStatementExtension]
Policies=AllIssuancePolicy
Critical=FALSE

[AllIssuancePolicy]
OID=2.5.29.32.0
URL=http://services.developpez.com/pki

Au final, le fichier CAPolicy.inf ressemble à ceci :

%windir%\CAPolicy.inf

[version]
Signature="$Windows NT$"

[Certsrv_server]
RenewalKeyLength=4096
RenewalValidityPeriod=Years
RenewalValidityPeriodUnits=20

CRLPeriod=Years
CRLPeriodUnits=15
CRLDeltaPeriod=Years
CDLDeltaPeriodUnits=10

[PolicyStatementExtension]
Policies=AllIssuancePolicy
Critical=FALSE

[AllIssuancePolicy]
OID=2.5.29.32.0
URL=http://services.developpez.com/pki

Maintenant que ce fichier est créé, l'autorité est installable.

III-A-2 - Installation de l'autorité

Commençons par ajouter un rôle au serveur. Cliquer sur Suivant.

Sélection des services de certificats Active Directory

Un petit résumé du rôle apparaît, cliquer sur Suivant.

Résumé du rôle

Il faut maintenant sélectionner les services de rôle. Pour cette autorité racine, seule l'autorité de certification est nécessaire. Nous n'avons pas besoin des autres services puisque seules les autorités secondaires se feront certifier et que ce nombre est très limité.

Sélection des services de rôle

L'assistant a détecté que l'autorité n'était pas dans un domaine Active Directory et a donc automatiquement grisé le choix d'autorité d'entreprise. Il faut donc cliquer sur suivant pour valider le choix de l'autorité autonome.

Sélection du type d'installation

L'assistant ne peut pas savoir quel type d'autorité nous voulons installer donc il faut préciser le choix. Naturellement, nous allons choisir l'autorité de certification racine.

Sélection du type d'autorité

Il se peut que vous ayez déjà une clé privée. Vous pourrez alors choisir d'utiliser cette clé. Dans 99% des cas, vous choisirez de créer une nouvelle clé privée. Je vais donc traiter ce cas.

Création ou sélection d'une clé privée

Il faut ensuite paramétrer la génération de clé. Cette génération est indépendante du fichier CAPolicy.inf. Cependant, pour éviter des surprises lors de la régénération de la clé, il est préférable d'utiliser les mêmes paramètres que dans le fichier CAPolicy.inf. Nous allons donc choisir une longueur de 4096 bits avec un hachage en SHA1. Pourquoi ne pas prendre SHA256 ou SHA512 ? Simplement pour des problèmes de compatibilité avec les anciens clients tels que Windows 2003 ou Windows XP. Les fonctions de hachage supérieures à SHA1 sont prises en charge à partir de Windows Vista et Windows 2008 (et donc Windows 7 et 2008 R2). Beaucoup de monde utilise encore Windows XP donc il faudra sans doute vous contenter de SHA1 à moins que tous vos clients potentiels soient sous Vista.

Paramètres de génération de la clé privée

Nommons correctement notre autorité : c'est le nom que verront les clients s'ils analysent le certificat racine de votre PKI. Donnez un nom significatif afin que chacun s'y retrouve.

Comme précédemment, il faut mettre les mêmes informations que dans le fichier CAPolicy.inf. Ici, on règle la durée de vie de la clé privée générée.

Durée de vie de la clé privée

Nous avons la possibilité de choisir l'emplacement de la base de certificats. Pour cette autorité racine (offline), nous allons nous contenter de l'emplacement par défaut à savoir le disque système. Cette autorité sera créée typiquement dans une machine virtuelle pour pouvoir la laisser offline sans occuper un serveur physique. Cela n'est donc pas trop grave. Attention, ce n'est pas grave dans ce contexte ! Votre autorité secondaire devra être installée sur un disque de données.

Emplacement de la base de certificats

L'assistant nous affiche maintenant un résumé de l'installation à effectuer. Profitez-en pour vérifier les différents points affichés. Cliquez ensuite sur Installer.

Résumé de la future installation

Normalement, tout doit bien se passer. Contrairement à ce screenshot, je vous conseille de mettre complètement votre serveur à jour.

Installation finie : il reste la configuration post-installation !

III-A-3 - Configuration post-installation

L'autorité est installée et partiellement configurée. Il faut finaliser la configuration : ouvrez le gestionnaire de serveur et développez l'arborescence jusqu'à voir le nom de votre autorité racine. Faites un clic droit pour accéder aux propriétés.

Propriétés de l'autorité racine

Le certificat racine étant distribuable sur Internet pour que les clients de votre entreprise fassent confiance à vos serveurs, il faut supprimer toutes les références à votre serveur. De plus, ces clients ne devant pas accéder à votre annuaire (pour des raisons de sécurité évidentes), il faut d'autant plus supprimer l'entrée qui annonce la disponibilité du certificat racine dans l'annuaire. Allez dans le panneau des extensions. Nous allons d'abord personnaliser les entrées annonçant les points de distribution des listes de révocation. Supprimez tout sauf la première ligne commençant par C:\Windows\System32.

Extensions des certificats

Ajouter ensuite une ligne pour déclarer un emplacement de téléchargement des listes de révocation. Cette URL doit être accessible depuis Internet si vous prévoyez de publier des services sécurisés sur Internet.

Ajout de l'emplacement de la CRL

Il faut ensuite inclure cette extension dans les futurs certificats émis par cette autorité. Cliquez sur Inclure dans l'extension CDP des certificats émis.

Ajout dans l'extension CDP

Il faut ensuite faire de même pour l'emplacement du certificat racine. Sélectionnez l'extension Accès aux informations de l'autorité (AIA). Supprimez toutes les lignes sauf celle commençant par C:\Windows\System32. Ajoutez l'emplacement du certificat racine : on le place généralement au même endroit que la liste de révocation. Cliquez ensuite sur Inclure dans l'extension AIA des certificats émis.

Ajout de l'emplacement du certificat racine

Pour finir la configuration, cliquez sur OK pour appliquer les nouveaux paramètres et redémarrer les services de certificats.

Application des nouveaux paramètres

Nous allons maintenant générer une nouvelle liste de révocation qui prendra en compte les nouveaux paramètres. Rendez-vous sur votre autorité, faites un clic droit sur Certificats révoqués puis Toutes les tâches, Publier.

Publication d'une nouvelle CRL

Sur la fenêtre qui va s'ouvrir, il faut sélectionner Nouvelle liste de révocation des certificats et cliquer sur OK. La nouvelle liste de révocation sera créée dans C:\Windows\System32\Certsrv\CertEnroll.

Création de la nouvelle CRL

Votre autorité de certification racine est configurée. Ne l'éteignez pas tout de suite : il va falloir certifier votre autorité de distribution (autorité secondaire d'entreprise).

Copiez les fichiers .crt et .crl situés dans C:\Windows\System32\Certsrv\CertEnroll sur une clé usb ou autre afin de les transférer vers le serveur web qui hébergera le site services.developpez.com.

III-A-4 - Publication

Lors de l'installation de l'autorité, nous avons configuré des emplacements pour télécharger la liste de révocation et le certificat racine. Il faut rendre ces emplacements disponibles en créant un serveur web. Vous devrez créer un enregistrement "A" dans votre DNS interne dans la zone publique developpez.com. Vous devez donc avoir deux zones :

- developpez.adds correspondant à votre nom de domaine Active Directory

- developpez.com correspondant à votre nom de domaine public

L'enregistrement à créer se nomme services.developpez.com et doit pointer vers le serveur web qui va accueillir les fichiers.

Le serveur web doit répondre pour le site services.developpez.com. Ce site doit contenir un répertoire nommé "pki". Copiez les fichiers .crt et .crl dans ce répertoire et renommez-les respectivement rootca.crt et rootca.crl.

Il faut maintenant valider le bon fonctionnement du serveur web. Essayez de télécharger les fichiers :

- http://services.developpez.com/pki/rootca.crl

- http://services.developpez.com/pki/rootca.crt

Si vous n'arrivez pas à télécharger ces fichiers depuis votre réseau interne, il est inutile de continuer. Il est obligatoire de pouvoir télécharger ces deux fichiers depuis votre réseau interne. Vous devrez résoudre ce problème de téléchargement avant d'aller plus loin.

Si le téléchargement des deux fichiers se passe correctement alors vous pouvez installer l'autorité secondaire.

III-B - Autorité secondaire d'entreprise

Pour des raisons matérielles, mon autorité secondaire est installée sur mon contrôleur de domaine. Je rappelle que ceci n'est pas conseillé. Dans un environnement réel, l'autorité secondaire ne doit pas être installée sur le contrôleur de domaine mais sur un serveur membre du domaine.

III-B-1 - Création du fichier CAPolicy.inf

Comme pour l'autorité racine, il faut créer le fichier de configuration dans %windir%\CAPolicy.inf. Il est structuré de la même façon mais possède un contenu différent. Le début du fichier comporte les mêmes instructions que pour l'autorité racine, seules les valeurs changent. La liste de révocation devra être recréée toutes les années. Les listes de révocation delta (ou différentielles) seront publiées tous les trois mois. Ajustez ces valeurs selon le nombre de certificats qui seront délivrés. Si vous délivrez un grand nombre de certificats, il est probable que vous deviez en révoquer un certain nombre. Afin de tenir les listes de révocations des postes clients à jour, il est souhaitable de publier des listes fréquemment.

[version]
Signature="$Windows NT$"

[Certsrv_Server]
RenewalKeyLength=2048
RenewalValidityPeriod=Years
RenewalValidityPeriodUnits=10

CRLPeriod=Years
CRLPeriodUnits=1

CRLDeltaPeriod=Months
CRLDeltaPeriodUnits=3

Nous allons maintenant ajouter les informations pour permettre aux clients de trouver le certificat de l'autorité racine ainsi que sa liste de révocation. Cela permettra aux clients de valider les certificats qui leur sont présentés. Ces informations sont les emplacements depuis lesquels le certificat racine et la liste de révocation sont téléchargeables. Pour être le plus interopérable possible, je choisis d'utiliser un emplacement sur un serveur web. On pourrait tout à fait utiliser un serveur LDAP (Active Directory) mais cela risquerait d'éliminer tous les clients non Windows.

[CRLDistributionPoint]
URL=http://services.developpez.com/pki/rootca.crl

[AuthorityInformationAccess]
URL=http://services.developpez.com/pki/rootca.crt

Cette configuration va nous imposer de mettre au moins un serveur web dans notre réseau. Si des clients externes utilisent des services sécurisés par des certificats issus de votre PKI, il faudra mettre un serveur web sur Internet. Les serveurs web public et interne peuvent être en fait le même serveur. Il faudra que vous preniez des dispositions (reverse-proxy par exemple) pour assurer la publication du serveur web. Attention à la sécurité de votre serveur ! Les adresses indiquées ont été rentrées précédemment dans la configuration de l'autorité racine.

Au final, nous obtenons donc le fichier CAPolicy.inf suivant

%windir%\CAPolicy.inf

[version]
Signature="$Windows NT$"

[Certsrv_Server]
RenewalKeyLength=2048
RenewalValidityPeriod=Years
RenewalValidityPeriodUnits=10

CRLPeriod=Years
CRLPeriodUnits=1

CRLDeltaPeriod=Months
CRLDeltaPeriodUnits=3

[CRLDistributionPoint]
URL=http://services.developpez.com/pki/rootca.crl

[AuthorityInformationAccess]
URL=http://services.developpez.com/pki/rootca.crt

III-B-2 - Installation de l'autorité

L'installation de cette autorité ressemble beaucoup à celle de l'autorité racine. Il faut ajouter le rôle Services de certificats Active Directory.

Sélection des services de certificats Active Directory

Il faut ensuite sélectionner des services de rôle. Si vous le souhaitez, vous pouvez ajouter l'inscription de l'autorité de certification via le Web afin de permettre aux clients de créer des certificats depuis une interface web.

Sélection des services de rôle

Cette fois-ci, nous allons installer une autorité d'entreprise. L'assistant a détecté que nous étions dans un environnement Active Directory et nous laisse donc ce choix.

Sélection du type d'installation

Nous avons déjà installé une autorité racine, il est inutile d'ajouter une deuxième autorité racine d'autant que ce n'est pas ce que nous souhaitons faire. Il faut donc choisir une autorité de certification secondaire.

Sélection du type d'autorité

Nous n'avons pas de clé privée existante donc nous allons en générer une nouvelle.

Création d'une nouvelle clé privée

La clé générée aura une longueur de 2048 bits et sera hashée en SHA1. Comme nous l'avons vu précédemment, SHA1 est choisi pour des raisons de compatibilité avec des clients comme Windows XP ou 2003.

Paramètres de génération de la clé privée

Nommons correctement notre autorité : c'est le nom que verront les clients s'ils analysent le certificat intermédiaire de votre PKI. Donnez un nom significatif afin que chacun s'y retrouve.

L'autorité que nous sommes en train d'installer doit être certifiée par une autorité parente. Dans notre cas, il s'agit de l'autorité racine. Afin d'être certifiée, il faut que l'autorité soumette une requête à l'autorité racine. L'assistant va pouvoir générer une requête de certificat avec les informations recueillies.

Le principe même d'une autorité racine offline est d'être éteinte et donc de ne pas être disponible sur le réseau. Mon autorité racine n'a aucune interface réseau configurée. L'autorité de distribution ne pourra donc pas soumettre sa requête. Il va falloir enregistrer la requête dans un fichier, transférer ce fichier via clé usb (par exemple) sur l'autorité racine pour le soumettre.

Enregistrement de la requête dans un fichier

Pour finir, il faut sélectionner les emplacements de la base de données de certificats et de son journal. Il est préférable de placer ces éléments sur un disque de données (tout disque non système). Cela fait partie des best practices de la PKI.

Emplacement de la base de données de certificats

L'assistant nous propose finalement un résumé de l'installation à effectuer. A partir du moment où vous confirmerez ces paramètres, l'installation sera lancée.

Résumé de l'installation à effectuer

L'installation se passe normalement sans soucis. Un message nous prévient que pour finir l'installation, il faut soumettre la requête enregistrée à l'autorité parente. C'est ce que nous allons voir maintenant.

Autorité secondaire installée !

III-B-3 - Certification de l'autorité secondaire par l'autorité racine

Nous allons prendre le fichier C:\ca.developpez.adds_Developpez Certification Authority.req et le copier sur l'autorité racine. Ouvrez la console des services de certificats Active Directory puis faites un clic droit sur votre autorité racine, Toutes les tâches, Soumettre une nouvelle demande.

Soumission d'une nouvelle demande

Sélectionnez la requête fraichement transférée.

Sélection du fichier de requête

Vous pouvez ensuite délivrer le certificat en allant dans Demandes en attente. Faites un clic droit sur la demande, Toutes les tâches, Délivrer.

Normalement, il ne doit pas y avoir de problèmes particuliers dans le traitement de la requête. Vous pouvez donc retrouver votre certificat dans les certificats délivrés.

Sélection du certificat délivré

Double-cliquez sur le certificat afin de l'ouvrir. Vous pouvez contrôler que le certificat est délivré à votre autorité secondaire par votre autorité racine.

Allez dans l'onglet Détails. Vous pouvez contrôler que l'emplacement de la liste de révocation racine est correct en regardant le champ Point de distribution de la liste de révocation des certificats.

Emplacement de la liste de révocation

Vous pouvez également contrôler l'emplacement du certificat racine en regardant le champ d'accès aux informations de l'autorité. Une fois ces contrôles effectués, vous pouvez copier le certificat dans un fichier.

Emplacement du certificat racine

Je passe volontairement quelques étapes de l'assistant suivant. Ces dernières ne sont pas importantes (informations diverses sur l'exportation).

Il est nécessaire d'exporter dans un format p7b en incluant tous les certificats dans le chemin d'accès.

Exportation en PKCS #7

Indiquez l'emplacement d'exportation du fichier. Vous devrez copier ce fichier sur votre autorité secondaire (par clé usb par exemple). L'exportation ne doit pas présenter de problème particulier.

Emplacement du fichier exporté

Vous pouvez maintenant éteindre votre autorité racine. Ne la supprimez sous aucun prétexte ! Elle vous sera utile pour générer une nouvelle liste de révocation quand la première sera arrivée en fin de vie. Vous devrez recréer cette liste de révocation et la remplacer sur votre serveur web afin que votre PKI continue de fonctionner sans interruption. Si vous perdez votre autorité racine, vous devrez recréer intégralement toute votre PKI. Conservez là dans un endroit sécurisé et n'oubliez pas le mot de passe pour vous connecter sur le serveur. Revenons maintenant sur l'autorité secondaire. Vous allez pouvoir l'activer puis la configurer.

III-B-4 - Activation de l'autorité

Nous allons maintenant activer notre autorité secondaire. Actuellement, cette autorité n'a que sa clé privée. Il lui manque sa clé publique. L'importation du fichier P7B créé sur l'autorité racine permet d'associer la clé privée à la clé publique de l'autorité secondaire. Il faut commencer par ajouter le certificat racine dans le magasin Autorités de certification racines de confiance afin que le serveur puisse faire confiance au fichier P7B que l'on va importer.

Ajout du certificat racine dans le compte ordinateur et le compte utilisateur

certutil -addstore root rootca.crt

Le fichier rootca.crt est normalement téléchargeable sur votre serveur web. Si ce n'est pas le cas, vous devez régler ce problème avant de continuer. Vérifiez également que le fichier rootca.crl est téléchargeable.

Cette commande va ajouter le certificat dans le magasin voulu. Un ordinateur a cependant deux magasins d'autorités racines. Il existe en effet un magasin par compte (utilisateur et ordinateur). La commande précédente ajoute le certificat racine dans les deux comptes.

Deux comptes différents pour les certificats

Nous pouvons maintenant installer le certificat délivré par l'autorité racine. Dans la console Autorité de certification, faites un clic droit sur votre autorité de certification, Toutes les tâches, Installer un certificat d'autorité de certification.

Installation du certificat d'autorité de certification

Sélectionnez le fichier P7B exporté depuis votre autorité de certification racine.

Sélection du certificat d'autorité de certification racine

La console semble alors se figer. Si vous n'avez pas eu de message d'erreur et que votre console est de nouveau réactive, vous pouvez vous réjouir ! Cela veut dire que votre autorité peut démarrer.

En revanche, si vous avez un message d'erreur, lisez bien ce dernier.

- S'il parle d'un problème de liste de révocation, contrôlez que le fichier rootca.crl est téléchargeable depuis votre autorité secondaire. Si cela fonctionne, regardez la date d'expiration de la liste de révocation. Contrôlez l'heure et la date de votre serveur. Si elle est dépassée, recréez la sur votre autorité de certification racine : cela n'est pas normal et ne devrait pas se produire. Si elle n'est pas dépassée, redémarrez simplement votre serveur : il s'agit du cache CRL. Le seul moyen que j'ai trouvé pour le moment pour vider ce cache est de redémarrer le serveur.

- S'il parle d'un problème de confiance dans la chaine de certification, contrôlez que votre certificat racine est bien dans le magasin Autorités de certification racines de confiance du compte ordinateur. Pour cela, ouvrez une mmc, ajoutez le composant enfichable Certificats en sélectionnant le compte ordinateur. S'il n'est pas présent, importez-le manuellement.

Si vous avez un message d'erreur, ne cliquez pas sur OK. Cliquez toujours sur Annuler, cela vous permettra de ré-essayer l'importation du certificat.

Si vous n'avez pas eu de problèmes lors de l'importation du certificat, vous pouvez démarrer votre autorité en cliquant sur Démarrer.

Démarrage de l'autorité

Un petit cercle vert atteste du bon démarrage et de la bonne santé de votre autorité secondaire.

Autorité secondaire démarrée !

Le travail n'est pas encore fini, il reste encore la configuration de l'autorité à finaliser.

III-B-5 - Configuration après le premier démarrage

Dans la console de l'autorité de certification, faites un clic droit sur votre autorité afin de modifier ses propriétés. Sélectionnez ensuite l'onglet Extensions. Par défaut, l'extension sélectionnée devrait être Points de distribution de liste de révocation des certificats (CDP).

Supprimez toutes les lignes sauf celle commençant par C:\Windows\System32 puis cliquez sur Ajouter.

Points de distribution de listes de révocation des certificats (CDP)

Ajoutez ensuite l'adresse à laquelle les clients pourront trouver la liste de révocation de votre autorité secondaire. De manière logique, elle devrait être placée au même endroit que la liste de révocation de votre autorité racine.

Ajout de l'emplacement de la liste de révocation

Vous devrez ensuite sélectionner d'inclure ce nouvel emplacement dans l'extension CDP des certificats émis.

Inclusion du nouvel emplacement dans l'extension CDP des certificats émis

Nous avons configuré tout à l'heure les listes de révocations différentielles dans le fichier CAPolicy.inf. Nous devons maintenant indiquer l'emplacement de ces listes de révocation différentielles.

Ajout de l'emplacement de la liste de révocation différentielle

Vous devrez ensuite inclure cet emplacement dans les listes de révocation afin de pouvoir rechercher les listes de révocation des certificats delta. Cela permettra aux clients de connaitre l'emplacement des listes de révocation différentielles.

Inclusion du nouvel emplacement dans la liste de révocation

Nous en avons fini avec les listes de révocation, passons maintenant à l'emplacement du certificat de votre autorité secondaire. Sélectionnez l'extension Accès aux informations de l'autorité (AIA). Comme pour les listes de révocation, supprimez tout sauf la ligne commençant par C:\Windows\System32 et ajoutez un nouvel emplacement.

Entrez l'adresse à laquelle les clients pourront trouver le certificat. Il est également logique de le mettre sur le même serveur que le certificat racine.

Accès aux informations de l'autorité (AIA)

Pour finir, il faut inclure le nouvel emplacement dans l'extension AIA des certificats émis.

Inclusion du nouvel emplacement dans l'extension AIA des certificats émis

Cliquez ensuite sur OK pour fermer les propriétés de l'autorité. Vous devrez redémarrer l'autorité quand cela vous sera proposé.

Redémarrage de l'autorité pour prendre en compte les changements

Nous allons maintenant pouvoir générer les listes de révocation de votre autorité secondaire. Pour cela, ouvrez l'arborescence de votre autorité, faites un clic droit sur Certificats révoqués, Toutes les tâches, Publier.

Publication des listes de révocation

Commencez par publier une nouvelle liste de révocation des certificats. Répétez l'opération en publiant une liste de révocation des certificats delta uniquement.

Publication d'une nouvelle liste de révocation

Publication d'une nouvelle liste de révocation delta

Vous allez pouvoir retrouver les listes de révocation et le certificat d'autorité dans %windir%\System32\Certsrv\CertEnroll\. Copiez les fichiers sur votre serveur web. Le certificat de votre autorité ainsi que la liste doivent être renommés respectivement en ca.crt et ca.crl. Le fichier se terminant par +.crl est la liste de révocation delta. Il faut renommer ce fichier en ca-delta.crl.

III-B-6 - Activation des attributs SAN

Lorsque vous faites plusieurs sites web sécurisés sur un même serveur ou que vous travaillez avec Exchange ou Office Communications Server, il est nécessaire d'avoir une PKI capable de délivrer des certificats avec plusieurs noms. Actuellement, votre PKI est capable de délivrer des certificats uniquement pour un seul nom. L'attribut SAN (Subject Alternate Name) permet de gérer plusieurs noms par certificat.

Afin de permettre à votre autorité secondaire de délivrer des certificats avec cet attribut, il faut exécuter la commande suivante :

certutil -setreg policy\EditFlags +EDITF_ATTRIBUTESUBJECTALTNAME2

Il faut redémarrer votre autorité pour prendre en compte les changements. Redémarrez le service Autorité de certification ou exécutez les commandes suivantes :

net stop certsvc
net start certsvc

Votre infrastructure à clés publiques est maintenant achevée. Vous pouvez commencer à générer des certificats pour vos serveurs, utilisateurs et ordinateurs.

IV - Renouvellement des autorités de certification

Il s'agit d'une étape qui se planifie. En effet, il va falloir redémarrer votre autorité une à deux fois. Si vous ne renouvellez pas le certificat de votre autorité à temps, celle-ci ne fonctionnera plus : elle ne pourra plus délivrer de certificats puisque le sien sera périmé. Vous pourrez avoir un event 96 de Microsoft-Windows-CertificationAuthority :

Les services de certificats Active Directory n'ont pas pu créer de certificat de chiffrement. Demandé par DOMAIN\User. Un certificat requis n'est pas dans sa période de validité selon la vérification par rapport à l'horloge système en cours ou le tampon daté dans le fichier signé. 0x800b0101 (-2146762495).

Lorsque vous ouvrirez le gestionnaire de serveur, vous pourrez voir votre autorité de certification en erreur (vue imbriquée de pkiview.msc) :

Autorité de certification en erreur (pkiview.msc)

Le renouvellement de certificat prend environ cinq minutes : pendant ce temps, votre autorité sera inopérante. J'ai réalisé le renouvellement sur mon autorité intermédiaire. Sur une autorité racine, le principe est identique : seule la partie de signature de certificat par l'autorité parente n'aura pas lieu. Pour commencer, ouvrez la console de gestion de votre autorité puis faites un clic-droit sur votre autorité, Toutes les tâches, Renouveler le certificat d'autorité de certification...

Renouvellement du certificat d'autorité

La mmc vous préviendra que votre autorité doit être arrêtée : acceptez.

L'autorité peut être arrêtée ?

Vous devez maintenant répondre à une question importante. Doit-on renouveler le certificat ou alors générer un nouveau certificat ? Lorsque le certificat est en fin de vie ou périmé, on devra le renouveler. Si la clé privée de l'autorité a été compromise ou que vous avez de nouveaux niveaux de sécurité à respecter (clé plus longue par exemple), il faudra créer une nouvelle paire de clés. Dans notre cas, on ne souhaite pas créer une nouvelle paire de clés mais seulement les renouveler. On répondra donc non.

Pas de création d'une nouvelle paire de clé privée/publique

Si vous renouvelez votre autorité racine, l'étape suivante (signature du certificat) doit être ignorée.

Le fichier de requête de renouvellement sera alors créé. Vous pourrez décider de l'envoyer directement à votre autorité racine ou alors de le transférer manuellement. Mon autorité racine est totalement indépendante et ne possède pas de connexion réseau pour éviter tout problème. Je vais donc choisir de transférer manuellement la requête. Pour cela, il faut cliquer sur Annuler. Le fichier est stocké à l'endroit spécifié sur la fenêtre.

Envoi de la requête ?

Vous devrez ensuite soumettre le fichier de requête à l'autorité racine comme pour l'installation de l'autorité intermédiaire. Exportez ensuite le certificat comme lors de l'installation. Une fois que le fichier du nouveau certificat est sur votre autorité intermédiaire, reprenez la console de l'autorité de certification puis faites un clic-droit sur votre autorité, Toutes les tâches, Installer un certificat d'autorité de certification....

Installation du nouveau certificat

Sélectionnez le fichier contenant le certificat de l'autorité puis redémarrez votre autorité.

Si vous ouvrez le gestionnaire de serveur sur le rôle autorité de certification, la vue imbriquée de pkiview.msc vous indiquera que tout fonctionne correctement.

pkiview.msc sans erreur

Il faudra ensuite exporter le certificat de votre autorité de certification seul (au format crt). Vous devrez remplacer le fichier ca.crt présent dans le site IIS créé pour gérer la révocation. Si vous utilisez la distribution de certificats par GPO, pensez à remplacer le certificat de votre autorité intermédiaire afin de conserver une chaine de certification valide.

Pensez à supprimer les fichiers qui ont été créés (requête, fichier du nouveau certificat).

V - Conclusion

La mise en place d'une infrastructure à clés publiques à deux niveaux n'est pas une chose aisée. Les probabilités de faire des erreurs lors de la configuration sont élevées quand on configure "à la va-vite". Il est donc très important de configurer la PKI en étant concentré. Cela vous évitera de perdre du temps à essayer de résoudre un problème survenu à cause d'une inattention. La bonne configuration de la PKI vous permettra d'utiliser des services sécurisés de manière sereine. De plus en plus de services sont sécurisés avec des certificats dans le monde Microsoft. La PKI jouera donc un rôle de plus en plus important dans votre réseau d'entreprise.

VI - Remerciements

Je tiens à remercier shawn12 et Hédhili Jaïdane pour leurs conseils et leurs corrections.