Implémenter une PKI dans Windows server 2008

Avant d’implémenter une PKI sous Windows server 2008, certains éléments
sont à prendre en compte. Et le plus majeur est la préparation d’un environnement AD DS (en
anglais Active Directory Domain Services). Tout d’abord lorsqu’un administrateur système
doit envisager le déploiement d’une PKI Windows server 2008, il doit se poser plusieurs
questions :

Est-ce que je dois mettre à jour tous les contrôleurs de domaines de la forêt vers
Windows server 2008 ?

La réponse est non. Une PKI Windows server 2008 ne repose pas sur un contrôleur de
domaine en version 2008. Il est possible d’installer une PKI Windows server 2008 dans un
environnement AD (Active Directory) sous Windows server 2000 ou 2003.

Est-ce que je dois augmenter le niveau fonctionnel de mon domaine ou de ma forêt

vers un niveau fonctionnel de Windows server 2008 ?

Une fois encore la réponse est non, une PKI Windows server 2008 n’a pas d’exigence pour le
niveau fonctionnel de domaine ou de la forêt. On peut mixer différents environnements
Active Directory.

Quelles sont les actions à entreprendre pour préparer mon environnement Active
Directory au déploiement de ma PKI sous Windows server 2008 ?

I- Analyse de l’environnement Active Directory

Plusieurs préparations devraient être entreprises avant l’installation d’une ACE (autorité
de certification d’entreprise) Windows server 2008 dans un environnement Active Directory
Windows 2000 ou Windows 2003 :

Déterminer le nombre de forêts dans l’environnement

Le nombre de forêts va influencer le nombre d’ACE nécessaires dans notre

environnement AD CS (Active Directory Certificate Services). Une ACE peut délivrer des
certificats seulement aux utilisateurs et ordinateurs ayant un compte de la même forêt. S’il
y a plusieurs forêts qui doivent utiliser les certificats de la PKI, vous devez déployer au moins
une AC par forêt.

Déterminer le nombre de domaines par forêt

Si plusieurs domaines sont présents à l'intérieur d'une forêt, il faut choisir le domaine qui
hébergera l’ACE. Le choix du domaine qui hébergera le compte d'ordinateur de l'autorité de
certification va dépendre du mode de management de notre organisation, centralisée ou
décentralisée? Dans le cas d'une administration centralisée, l'autorité de certification doit être
placée dans le domaine qui stocke le compte d'ordinateur de l’AC. Dans le cas d'une
administration décentralisée, il est possible de placer l’AC dans différents domaines.

Déterminer la composition des groupes administrateurs locaux pour un serveur

membre

Si l'on utilise un outil de cryptage pour protéger la clé privée de l'autorité de certification,
tous les membres du groupe local Administrateurs du compte d'ordinateur de l'autorité de
certification  ont la capacité d'exporter la clé privée. Il est important de commencer par
identifier quel domaine ou quelle unité d'organisation (OU) permettrait de limiter le nombre
d'administrateur local. Par exemple, une organisation qui décide de déployer une forêt racine,
peut choisir d'installer toutes les autorités de certification entreprise dans le domaine de cette
forêt racine pour limiter le nombre des administrateurs locaux sur l’AC.

Déterminer la version du schéma du domaine

Pour implémenter une AC Windows 2008  et bénéficier  de toutes les nouveautés

introduites par Active Directory Certificate Services(ADCS), il est nécessaire d'installer la
dernière version du schéma AD CS. Le schéma Windows 2008 peut être déployé dans des
forêts contenant un contrôleur de domaine sous Windows 2000, Windows 2003, Windows
2008.

NB : Pour mettre à jour le schéma sur un contrôleur de domaine sous Windows 2000, ce
dernier doit être doté avec le Service Pack 4 au minimum. Pour un DC Windows Server
2003 aucun Service Pack n'est requis pour procéder à la mise à jour du schéma.
 1- Mise à jour du schéma active directory 

Les forêts Windows 2000 ou 2003 doivent être mises à jour pour bénéficier des nouvelles
fonctionnalités apportées par le schéma Windows 2008 comme par exemple :

Support de la version 3 du Template de certificat :

Le schéma de Windows Server 2008 comprend la définition de la version 3 du Template de

certificat. Cette version 3 permet  l'implémentation d'algorithmes de cryptographie de
nouvelle génération dans la publication des certificats.

Ajout d'un répondeur en ligne :

Windows Server 2008 introduit un service de répondeur sur le statut des certificats en ligne
(OCSP). Ce service permet de mettre à jour la validation des demandes de certificat plutôt que
d'utiliser une liste de révocation de certificat (LCRs) 

Service de déploiement de certificat pour les périphériques réseaux (NDES) :

Windows Server 2008 supporte nativement l'émission automatique de certificat pour les
périphériques Cisco en utilisant le Simple Certificate Enrollment Protocol (SCEP). SCEP
permet l'émission automatique  de certificat pour les périphériques réseaux sans que ces
derniers n'aient un compte ordinateur pour les périphériques dans Active Directory.

Support natif des certificats qualifiés :

Les certificats qualifiés, décrit dans la RFC 3739 "Internet X.509 Public Key Infrastructure
Qualified Certificates Profile", autorise l'émission de certificat pour une sécurité accrue dans
les signatures électroniques. Un certificat qualifié peut également comprendre des
informations biométriques sur le demandeur du certificat.

2- Identification du maitre de schéma

Si la forêt est dans une version Windows 2000 ou Windows 2003, il faut identifier le maître
de schéma. La procédure est la suivante :

Ouvrir l’invite de commande

 Taper sur cette invite de commande la commande suivante « regsvr32
schmmgmt.dll »

Dans la boite de message RegSvr32, cliquer sur le bouton « OK »

Taper sur le prompt la commande « mmc »

Dans le menu fichier, sélectionner « Ajouter/ Supprimer des composants logiciels

enfichables »

Dans la boite de dialogue qui s’ouvre, sélectionner « schéma Active Directory » et

appuyer sur le bouton « Ajouter » et cliquer sur le bouton « OK »

Dans l’arborescence, sélectionner « schéma Active Directory », faire un clic droit

dessus et choisir « maitre d’opération ».

Dans la boite changer le contrôleur de domaine qui s’ouvre, cliquer sur le bouton
« fermer »

Fermer la console « mmc » sans sauvegarder.

3- Mise à jour du schéma

Une fois que le maitre de schéma est identifié, il faut se connecter au contrôleur de
domaine en tant que membre des groupes administrateurs du schéma, administrateurs de
l'entreprise dans la forêt racine du domaine et membre du groupe administrateur du domaine
du serveur qui héberge le maitre de schéma.

Insérer dans le lecteur DVD, le DVD d’installation de Windows server 2008

Ouvrir l’invite de commande

Sur cette invite de commande taper X : (ou X est la lettre qui représente votre lecteur
DVD) et appuyer sur la touche « Entrée » sur votre clavier.

Sur l’invite de commande taper « cd\sources (support)\adpred », et appuyer sur la

touche « Entrée »
 Sur l’invite de commande taper « adpred / forestprep», et appuyer sur la touche
« Entrée »

Au message d’avertissement dans l’invite de commande, appuyer la touche « C »

pour continuer.

Rassurez-vous qu’à la fin, vous obtenez le message suivant : «  les informations au

niveau des forêts ont été mises à jour avec succès »  

Quand la mise à jour du schéma est terminée,  il faut s'assurer que ces modifications
soient entièrement répliquées sur tous les autres contrôleurs de domaine de la forêt. On peut
observer les réplications grâce à l'utilitaire graphique replmon.exe (Réplication Monitor) ou
avec l'utilitaire en ligne de commande repadmin.exe disponible dans les Windows Support
Tools. Une fois les modifications du schéma répliquées sur tous les contrôleurs de domaine de
la forêt, on peut préparer chaque domaine à bénéficier des extensions du schéma Windows
Server 2008.

Insérer dans le lecteur DVD, le DVD d’installation de Windows server 2008

Ouvrir l’invite de commande

Sur cette invite de commande taper X : (ou X est la lettre qui représente votre lecteur
DVD) et appuyer sur la touche « Entrée » sur votre clavier.

Sur l’invite de commande taper « cd\sources (support)\adpred », et appuyer sur la

touche « Entrée »

Sur l’invite de commande taper « adpred / domainprep /gpprep», et appuyer sur la

touche « Entrée »

4- Modification de la portée du groupe d’éditeur de certificats

Le groupe Editeurs de certificats est un groupe par défaut présent dans chaque domaine
d'une forêt Active Directory. Ce groupe dispose des permissions  lire et écrire sur les
informations de certificat de l'attribut userCertificate des objets utilisateur de ce domaine. Les
certificats publiés avec ces attributs sont typiquement des certificats cryptés qui autorise une
personne à obtenir la clé publique du certificat crypté par une requête à Active Directory.
La difficulté est que la portée du groupe Editeurs de certificats est définie par le premier
contrôleur de domaine du domaine.

Si l'environnement Active directory est sous Windows 2000, le groupe Editeurs de certificats
est un groupe global. Cela signifie que seuls les comptes d'ordinateur provenant du même
domaine peuvent devenir membre du groupe. Si l'environnement AD est sous Windows 2003
ou Windows 2008, le groupe Editeurs de certificats est un groupe de domaine local. Cela
signifie que les comptes d'ordinateur de n'importe quel domaine peuvent devenir membre de
ce groupe.

Si une autorité de certification publie un certificat pour un utilisateur et qu'il est nécessaire
d'éditer l'attribut userCertificate, la modification échouera si l'autorité de certification n'est
pas membre du groupe Editeurs de certificats.

NB  : Si l'autorité de certification n'a pas les permissions suffisantes pour écrire dans
l'attribut userCertificate, le message suivant apparait dans le journal des évènements partie
application :

EVENT ID: 80

Description:

Certificate Services could not publish a certificate for request # (where # is the request ID of
the certificate request) to the following location on server dc.example.com:
CN=pierre.dupont, OU=users, OU=Accounts, DC=monlab, DC=local.

Insufficient access rights to perform the operation. 0x80072098 (WIN32:8344).

L'exemple ci-après repose sur le schéma suivant à savoir deux autorités de certification,
SVR001 et SVR002, situées dans l'OU Computers la forêt D00.local.  

 
 

Membres Editeurs de certificats quand le groupe est un groupe de domaine local

(Windows 2003 ou Windows 2008) :

Dans cet exemple les domaines D00.local, D10.D00.local et D100.D00.local sont créés dans
des environnements Windows Server 2003 ou Windows Server 2008. Dans ce cas de figure, il
faut ajouter le compte ordinateur du domaine D00.local aux groupes Editeurs de certificats
des domaines D10.D00.local et D100.D00.local. Il n'est pas nécessaire de réaliser cette
opération pour le domaine D00.local car l'ajout du compte ordinateur de l'autorité de
certification est automatiquement réalisé lors de l'installation d’Active Directory Certificate
Services. L'ajout du compte d'ordinateur aux groupes Editeurs de certificats des domaines
D10 et D100 peut être fait à l'aide d'un script VBS ou Powershell.

Stratégies du groupe Editeurs de certificats si le groupe est un groupe global

(Windows 2000):
Si le domaine est créé à partir d'un environnement Windows Server 2000, deux stratégies sont
possibles :

 Modifier les permissions pour permettre au groupe Editeurs de certificat de chaque

autorité de certification dans chaque domaine de lire et écrire dans l'attribut
userCertificate pour tous les autres domaines de la forêt.

 Modifier la portée du groupe Editeurs de certificats de groupe local à groupe de

domaine local et ajouter le compte de l'autorité de certification au groupe Editeurs de
certificats dans chaque domaine.

Modifier les autorisations dans Active Directory :

 L'article 300532 de la base de connaissance Windows s'intitulant "Windows 2000 Enterprise

CAs Not Added to Certificate Publishers Group in Windows Server 2003 Domain", propose
un guide sur comment définir les permissions pour autoriser le groupe Editeurs de certificats
d'un domaine à éditer l'attribut userCertificate d'un certificat utilisateur quand le compte de
l'utilisateur appartient à un domaine différent. Voici un résumé des actions à entreprendre : 

1- Autoriser au groupe Editeurs de certificats du domaine D00.local à lire l'attribut

userCertificate dans tous les autres domaines de la forêt.

2- Autoriser au groupe Editeurs de certificats du domaine D00.local à écrire dans l'attribut

userCertificate dans tous les autres domaines de la forêt.

3-Autoriser au groupe Editeurs de certificats du domaine D00.local à lire l'attribut

userCertificate  pour le container CN=adminsholder,CN=system,DomainName dans tous les
autres domaines de la forêt.

4- Autoriser le groupe Editeurs de certificats à écrire dans l'attribut userCertificate du

container CN=adminsholder,CN=system,DomainName dans tous les autres domaines de la
forêt.
NB  : Si le compte d'ordinateur de l'autorité de certification existe dans plusieurs domaines
au sein de la forêt AD, il faut modifier l'affectation des permissions du groupe Editeurs de
certificats d'une autorité de certification dans un des domaines de la forêt.

Modification de la portée du groupe Editeurs de certificats:

En pratique, il n'est pas évident de prévoir ce que la portée du groupe Editeurs de

certificats peut être sans avoir inspecté chaque domaine de la forêt. La portée est basée
uniquement sur ce que le premier contrôleur de domaine de la forêt a implémenté. Si le
domaine a été contruit dans un environnement Windows 2000, le groupe Editeurs de
certificats est un groupe global. Si le domaine a été implémenté dans un environnement
Windows 2003 ou 2008, ce groupe sera un groupe de domaine local.

La difficulté ici, est qu'il n'est pas possible de changer le type de groupe du groupe Editeurs de
certificats avec la console Utilisateurs et Ordinateurs Active Directory. Cette modification ne
peut être réalisée qu'avec l'aide d'un script. Dans l'ordre voici les actions à engager :  

1- Convertir le groupe Editeurs de certificats de groupe global à groupe universel.

2- Convertir le groupe Editeurs de certificats de groupe universel à groupe de domaine local.

3- Peupler le groupe Editeurs de certificats avec tous les comptes d'ordinateur des autorités de
certification de la forêt.

NB  : Il n'est pas possible de convertir directement un groupe global en groupe de domaine
local. La transition vers un groupe universel est toujours obligatoire.

Pour réaliser un script permettant d'obtenir la conversion des groupes, il faut garder à l'esprit
que l'attribut groupType d'un groupe universel est -2147483640 et celui d'un groupe de
domaine local est -2147483644.

Ce script pourrait ressembler à l'exemple suivant :

1 Set grp = GetObject("LDAP://CN=Cert Publishers,CN=Users,DC=D10,DC=D00,DC=local")

2 grp.Put "grouType","-2147483640"
3 grp.SetInfo
4 grp.Put "groupType","-2147483644"
5 grp.SetInfo
6 grp.SetInfogrp.add ("LDAP://CN=SVR001,CN=Computers,DC=D00,DC=local")
7 grp.SetInfogrp.add ("LDAP://CN=SVR002,CN=Computers,DC=D00,DC=local")
8 grp.SetInfo
9 Set grp = GetObject("LDAP://CN=Cert Publishers,CN=Users,DC=D100,DC=D00,DC=local")
1 grp.Put "groupType" , "-2147383640"
0 grp.SetInfo
1 grp.Put "groupType", "-2147383644"
1 grp.SetInfo
1 grp.SetInfogrp.add ("LDAP://CN=SVR001,CN=Computers,DC=D00,DC=local")
2 grp.SetInfogrp.add ("LDAP://CN=SVR002,CN=Computers,DC=D00,DC=local")
1 grp.SetInfo
3 grp.SetInfo 
1
4
1
5
1
6
1
7

II- Installation de l’autorité de certification sous Windows server

2008
Après avoir préparé l’environnement Active Directory, nous pouvons maintenant passer à
l’installation de notre autorité de certification(AC). Notons qu’il existe deux types d’autorités
de certifications :

 l’autorité de certification autonome(ACA)

 l’autorité de certification entreprise(ACE)

Le de l’une des autorités de certification doit être réfléchi puisque vous n’avez pas la
possibilité de changer le type de votre autorité simplement. Si vous décidez, vous devez
supprimer votre autorité de certification pour la réinstaller. Cela n’est pas sans risque,
notamment au niveau de la conservation des clés. Quel que soit le type d’AC choisit, nous
avons deux niveaux fonctionnels :
  l’autorité racine(AR) qui est la première autorité du réseau
 l’autorité intermédiaire(AI), elle dépend d’une AR

Voici un tableau résumant les recommandations de Microsoft quant aux types d’autorités a
utilisé selon le niveau fonctionnel (racine, intermédiaire, délivrance).

Type de l’autorité 3 niveaux 2 niveaux 1 niveau

Racine offline Autonome Autonome Entreprise
Intermédiaire offline Autonome
Délivrance online Entreprise Entreprise

Tableau 1: recommandation de Microsoft

NB  : après l’installation des services de certificats, il n’est plus possible de changer le nom
ou le domaine du serveur.

1- Autorité autonome
Elle permet de délivrer les certificats dans réseau comme internet. Son fonctionnement
pour un utilisateur est moins automatique que celui d’une ACE, car elle ne dépend pas de
l’environnement Active Directory utilisé. Par défaut les utilisateurs peuvent demander les
certificats auprès d’une ACA à partir de ses pages web uniquement. Les ACA qui n’utilisent
pas AD devront exiger, en règle générale, que le demandeur de certificats produise des
informations d’indentification plus complètes. Une ACA publie sa liste de révocation de
certificats (LCRs) dans un dossier partagé ou dans le cas échéant dans AD. Les scénarios
d’utilisation d’une ACA sont :

 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 (quel que 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.
 2- Autorité d’entreprise
Elle utilisée si l’AC doit délivrer les certificats dans un domaine auquel appartient le
serveur. Cette autorité doit être contrôleur de domaine. Elle dépend de l’environnement AD
utilisé, elle offre à un demandeur plusieurs type de certificats, selon les certificats qu’elle
habilitée à émettre et les autorisations de sécurités du demandeur. Elle utilise les informations
disponibles dans AD pour faciliter la vérification de l’identité du demandeur. Elle publie sa
liste de révocation de certificats dans l’AD ainsi que dans un répertoire partagé. Les scénarios
d’utilisation d’une ACE sont :

 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.

3- Hiérarchie des ACs

L'autorité de certification racine étant l'élément le plus critique d'une PKI en raison de la
confidentialité de sa clé privée, il est fortement conseillé d'utiliser une infrastructure à
plusieurs niveaux. Nous allons utiliser une hiérarchie à trois niveaux.
Figure 1: hiérarchie à trois niveaux

Dans l'exemple ci-dessus, l'autorité racine ne délivre que deux certificats (donc
seulement deux utilisations de sa clé privée) aux autorités de certifications intermédiaires.
Une fois les autorités de certifications intermédiaires approuvées par l'autorité racine, elle
peut être déconnectée du réseau ce qui garantit qu'aucun utilisateur malveillant ne pourra
"voler" la clé privée de l'autorité de certification racine. Lorsque ces autorités de certifications
intermédiaires auront reçues leur certificat leur permettant d'exercer leur fonction, elles
pourront à leur tour autoriser les autorités de certifications dites "émettrice". De cette manière,
il est aussi possible de déconnecter du réseau les autorités intermédiaires en laissant les
autorités de certifications "émettrices" signer les certificats. Cette hiérarchie permet non
seulement de choisir quelle autorité va délivrer tel type de certificat, mais aussi de limiter les
risques d'attaque de cette PKI, puisqu'en aucun cas il ne sera possible d'être en possession de
la clé privée de l'autorité racine stockée dans un endroit sûr puisque hors du réseau (et dans un
endroit physiquement protégé).

NB : Il est toujours recommandé d'utiliser une Edition Enterprise de Windows Server 2008
quand il est question de déployer une autorité de certification d'entreprise. La version
Enterprise propose des fonctionnalités avancées qui ne sont pas disponibles dans la version
Standard de Windows 2008.

Avant de procéder à l’installation de notre Autorité de Certification Racine Autonome

(ACRA), il nous faut d’abord éditer son fichier de configuration CAPolicy.inf. Le modèle du
fichier de configuration CAPolicy.inf est la suivante :

[Version]
Signature= “$Windows NT$"
[PolicyStatementExtension]
Policies = LegalPolicy
Critical = 0
[LegalPolicy]
OID = 1.3.6.1.4.1.311.21.43
Notice = “Legal policy statement text."
URL = “http://www.example.com/certdata/cps.asp"
[AuthorityInformationAccess]
Empty = true
;URL = http://%1/Public/My CA.crt
;URL = ftp://ftp.example.com/Public/MyCA.crt
;URL = file://\\%1\Public\My CA.crt
Critical = false
[CRLDistributionPoint]
Empty = true
;URL = http://%1/Public/My CA.crl
;URL = ftp://%1/Public/MyCA.crl
;URL = file://\\%1\Public\My CA.crl
Critical = true
[EnhancedKeyUsageExtension]
OID = 1.3.6.1.4.1.311.21.6 ; szOID_KP_KEY_RECOVERY_AGENT
OID = 1.3.6.1.4.1.311.10.3.9 ; szOID_ROOT_LIST_SIGNER
OID = 1.3.6.1.4.1.311.10.3.1 ; szOID_KP_CTL_USAGE_SIGNING
Critical = false
[basicconstraintsextension]
pathlength = 4
critical=false
[certsrv_server]
renewalkeylength=4096
RenewalValidityPeriodUnits=20
RenewalValidityPeriod=years
CRLPeriod = days
CRLPeriodUnits = 2
CRLDeltaPeriod = hours

CRLDeltaPeriodUnits = 4

Nous allons prendre l’exemple d’une hiérarchie à deux niveaux, pour illustrer comment
déployer une PKI Windows server 2008.

4- Installation de l’autorité racine autonome

a) Création du fichier de configuration 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. 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

NB: 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://guichetunique.org/pkiw8

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

[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://guichetunique.org/pkiw8

Une fois que le fichier de configuration a été créé, nous pouvons passer à l’installation de
l’autorité de certification.

b) Installation des services de certificats Active Directory (AD CS)

L'installation des AD CS doit s'effectuer avec un compte membre à la fois du groupe
administrateur de l'entreprise de la forêt et  du groupe administrateur local de la machine
recevant l'autorité de certification.

Vérifier que l’heure et la date sur l’ordinateur de l’ACRA soit correcte

Cliquer sur le menu « démarré », sélectionné « Outils d’administration » et cliquer
enfin sur « Gérer les serveurs ».
Dans la fenêtre qui s’affiche, cliquer sur « Rôles » dans l’arborescence, ensuite sur le
lien « Ajouter des Rôles » à l’extrême droite de la fenêtre.
Dans la fenêtre « Assistant Ajout de rôle », cocher la case « ignorer cette page par
défaut » et cliquer sur le bouton « suivant ».
Dans  « rôle de serveur », cocher AD CS (Service de Certificat Active directory),
puis cliquer sur le bouton « suivant ».
Dans la page « Introduction aux services de certificats Active Directory », cliquer
sur le bouton « suivant ».
Dans la page « sélectionner les services de rôle », cocher « Autorité de
certification » et cliquer sur le bouton « suivant ».
Dans la page « spécifier le type d’installation », cocher « Autonome » et cliquer sur
le bouton « suivant ».
Dans la page « spécifier le type de l’AC », cocher « Autorité de certification
Racine » et cliquer sur le bouton « suivant »
Dans la page « configurer la clé privée », cocher « créer une nouvelle clé privée »
et cliquer sur le bouton « suivant »
Dans la page « configurer le chiffrement pour l’AC », dans sélectionnez un
fournisseur de service de chiffrement, sélectionné « RSA #Microsoft Software Key
Storage Provider » ; dans longueur de la clé en caractères, sélectionner « 4096 » ;
dans sélectionner l’algorithme de hachage pour la signature des certificats émis par
cette AC, sélectionner « SHA256 », cliquer sur le bouton « suivant »
Dans la page « configurer le nom de l’autorité de certification », donner les
informations suivantes et cliquer sur le bouton « suivant » :
 Nom commun de cette AC : GuceRootCA
 Suffixe du nom unique : DC=guichetunique,DC=org
Dans la page période de validité de certificat, sélectionner 20 années et cliquer sur le
bouton « suivant ».
Dans la page configurer les bases de données des certificats, donner les informations
suivantes et cliquer sur le bouton suivant :
 Emplacement de la base de données des certificats : D\CertDB
 Emplacement des journaux des certificats : D\CertLog

NB  : vous pouvez laisser les valeurs par défaut.

Dans la page confirmer les sélections pour l’installation, cliquer sur le bouton
« installer ».
 Dans la page résultat de l’installation, vérifier l’installation a été réalisée avec succès
et cliquer sur le bouton « fermer »

NB  : l’algorithme de hachage SHA256 et SHA512 sont utilisés lorsque tous vos clients
sont sous Windows vista, Windows server 2008, Windows server 2008 R2, Windows 7. Il est
préférable d’utiliser le SHA1 pour garder la compatibilité avec les clients sous Windows
XP, Windows 2003.

c) 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. 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. 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. Il faut ensuite
inclure cette extension dans les futurs certificats émis par cette autorité. Cliquez sur Inclure
dans l'extension CDP des certificats émis. 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. Pour finir
la configuration, cliquez sur OK pour appliquer les nouveaux paramètres et redémarrer les
services de certificats. 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. 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. 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 autonome). 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 guichetunique.org.

5- Installation de l’autorité de certification secondaire d’entreprise

a) Création du fichier de configuration 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=1
0
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, il faut 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://guichetunique.org/pki/rootca.crl
[AuthorityInformationAccess]
URL=http://guichetunique.org/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 :

[version]
Signature="$Windows NT$"
[Certsrv_Server]
RenewalKeyLength=2048
RenewalValidityPeriod=Years
RenewalValidityPeriodUnits=10
CRLPeriod=Years
CRLPeriodUnits=1
CRLDeltaPeriod=Months
CRLDeltaPeriodUnits=3
[CRLDistributionPoint]
URL=http:// guichetunique.org /pki/rootca.crl
[AuthorityInformationAccess]
URL=http:// guichetunique.org /pki/rootca.crt
 b) 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.

Vérifier que l’heure et la date sur l’ordinateur de l’ACEE soit correcte

Cliquer sur le menu « démarré », sélectionné « Outils d’administration » et cliquer
enfin sur « Gérer les serveurs ».
Dans la fenêtre qui s’affiche, cliquer sur « Rôles » dans l’arborescence, ensuite sur le
lien « Ajouter des Rôles » à l’extrême droite de la fenêtre.
Dans la fenêtre « Assistant Ajout de rôle », cocher la case « ignorer cette page par
défaut » et cliquer sur le bouton « suivant ».
Dans  « rôle de serveur », cocher AD CS (Service de Certificat Active directory),
puis cliquer sur le bouton « suivant ».
Dans la page « Introduction aux services de certificats Active Directory », cliquer
sur le bouton « suivant ».
Dans la page « sélectionner les services de rôle », cocher « Autorité de
certification » et cliquer sur le bouton « suivant ». si vous souhaitez, vous pouvez
cocher la case « inscription de l’autorité de certification via le web » afin de
permettre aux clients de créer des certificats via une interface web. Dans ce cas une
boite de dialogue s’affiche et vous appuyez sur le bouton « Ajouter les services de
rôle requis ».
Dans la page « spécifier le type d’installation », cocher « Entreprise » et cliquer sur
le bouton « suivant ».
Dans la page « spécifier le type de l’AC », cocher « Autorité de certification
Secondaire » et cliquer sur le bouton « suivant »
Dans la page « configurer la clé privée », cocher « créer une nouvelle clé privée »
et cliquer sur le bouton « suivant »
Dans la page « configurer le chiffrement pour l’AC », dans sélectionnez un
fournisseur de service de chiffrement, sélectionné « RSA #Microsoft Software Key
Storage Provider » ; dans longueur de la clé en caractères, sélectionner « 2048 » ;
dans sélectionner l’algorithme de hachage pour la signature des certificats émis par
cette AC, sélectionner « SHA1 », cliquer sur le bouton « suivant »
Dans la page « configurer le nom de l’autorité de certification », donner les
informations suivantes et cliquer sur le bouton « suivant » :
  Nom commun de cette AC : GuceAuthoritySecondaire
 Suffixe du nom unique : DC=guichetunique,DC=org
Dans la page période de validité de certificat, sélectionner 10 années et cliquer sur le
bouton « suivant ».

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.

Dans la page « Demandé un certificat à une autorité de certification parent »,

coché « Enregistrer une demande de certificat dans un fichier et envoyer
ultérieurement à une autorité de certification parente », ensuite appuyer sur le
bouton « suivant ».
Dans la page configurer les bases de données des certificats, donner les informations
suivantes et cliquer sur le bouton suivant :
 Emplacement de la base de données des certificats : D\CertDB
 Emplacement des journaux des certificats : D\CertLog

Dans la page confirmer les sélections pour l’installation, cliquer sur le bouton
« installer ».

Dans la page résultat de l’installation, vérifier l’installation a été réalisée avec succès
et cliquer sur le bouton « fermer »

c) Certification de l’autorité secondaire par l’autorité racine

Supposons que notre requête de certificat a été enregistrée dans l’emplacement :
C:\ca.guichetunique.org_certificat authority.req. Nous allons copier ce fichier 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,
sélectionner la requête fraichement transférée. 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.
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. 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.
Dans la page « Assistant d’exportation de certificat », coché respectivement les cases
« Standard de syntaxe de message de chiffrement –certificat PKCS #7(.p7b) » et
« inclure tous les certificats dans le chemin d’accès de certification si possible » et cliquer
sur le bouton suivant. 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.
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.

d) Activation de l’autorité secondaire

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.
Taper la commande suivante : certutil -addstore root rootca.crt pour 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.
NB : 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.
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. Sélectionnez le fichier P7B exporté
depuis votre 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.
NB  : 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 (flèche verte en dessous du menu Affichage sur la
barre d’outil). Un petit cercle vert atteste du bon démarrage et de la bonne santé de votre
autorité secondaire. Le travail n'est pas encore fini, il reste encore la configuration de l'autorité
à finaliser.

e) 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. 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 (par exemple
http://guichetunique.org/pki/ca.crl), et appuyer en suite sur le bouton « OK ». Vous devrez
ensuite sélectionner d'inclure ce 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 (par exemple http://guichetunique.org/pki/ca-delta.crl) et ensuite
appuyer sur le bouton « OK » 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. 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 (appuyer sur le bouton
« Ajouter »). Entrez l'adresse à laquelle les clients pourront trouver le certificat. Il est
également logique de le mettre sur le même (par exemple
http://guichetunique.org/pki/ca.crt) serveur que le certificat racine et appuyer sur le bouton
« OK ». Pour finir, il faut inclure le 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é (appuyer sur « OK »).
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. 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 (cliquer sur le bouton « OK »). 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.

f) Activation des attributs SAN (Subject Alternate Name)

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.

6- 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 renouvelez 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é. Le
renouvellement de certificat prend environ cinq minutes : pendant ce temps, votre autorité
sera inopérante. Réalisons ici 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.... La mmc vous préviendra que votre autorité doit être arrêtée : acceptez. 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.
NB  : 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. 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....
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. 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 (Group Policy Object), pensez à remplacer le certificat de
votre autorité intermédiaire afin de conserver une chaine de certification valide.
NB  : Pensez à supprimer les fichiers qui ont été créés (requête, fichier du nouveau
certificat).

V-