Presentation de L IGC Windows Serveur 2003

Prsentation de lIGC Windows Server
2003
Version 1.0
Publication : Avril 2008
Auteur : Stphane Metenier, Philippe Beraud

Contributeurs : Christophe Dubos
Copyright
2008 Microsoft Corporation. Tous droits rservs.
Objectif
Ce livre-blanc a pour but de faire dcouvrir les services dinfrastructures de gestion de cls
publiques (IGC Public Key Infrastructure ou PKI en anglais) prsents dans le systme
dexploitation Windows Server 2003 (R2) sous la dnomination Services de certificat
(certificate services en anglais). Ce document permet ainsi pour les administrateurs
techniques mais galement pour tout acteur de la scurit davoir une vue densemble
permettant dapprhender clairement ces services dinfrastructure de Windows Server 2003
(R2) et leur mise en uvre et dploiement.
Un second document dcrivant les services dIGC de Windows Server 2008 est aussi
disponible ici : Livre Blanc tlcharger : Grille dvaluation Services de certificats Active
Directory V1.0
2008 Microsoft Corporation. Tous droits rservs.

Les informations contenues dans ce document reprsentent le point de
vue actuel de Microsoft Corporation sur les sujets traits la date de
publication. Etant donn que Microsoft doit sadapter aux conditions
changeantes du march, ces informations ne doivent pas tre
interprtes comme un engagement de la part de Microsoft, et
Microsoft nest pas en mesure de garantir lexactitude de toute
information prsente aprs la date de publication.
Ce document nest fourni qu titre dinformation. MICROSOFT NE
DONNE AUCUNE GARANTIE EXPRESSE OU IMPLICITE DANS CE
DOCUMENT.
Les autres noms de produits ou de socits cits dans ce document
peuvent tre des marques de leurs propritaires respectifs.
Microsoft Corporation One Microsoft Way Redmond, WA 980526399 Etats-Unis
ii
Introduction | Prsentation de lIGC Windows Server 2003
Sommaire
1.
INTRODUCTION
1.1.
1.2.
2.
11
INTRODUCTION .............................................................................................................. 11
PRESENTATION GENERALE ............................................................................................ 12
FONCTIONNALITES ........................................................................................................ 14
ARCHITECTURE ............................................................................................................. 21
ADMINISTRATION ET EXPLOITATION ................................................................................ 25
INTEROPERABILITE ........................................................................................................ 28
STANDARDS SUPPORTES ............................................................................................... 30
MISE EN UVRE DES SERVICES DIGC

3.1.
3.2.
3.3.
3.4.
3.5.
4.
CONTEXTE ...................................................................................................................... 4
USAGES DUNE IGC ........................................................................................................ 4
DESCRIPTION DES SERVICES DIGC

2.1.
2.2.
2.3.
2.4.
2.5.
2.6.
2.7.
3.
34
PERFORMANCES ........................................................................................................... 34
DIMENSIONNEMENT ET MATERIELS ................................................................................. 34
METHODOLOGIE ............................................................................................................ 35
COUTS ......................................................................................................................... 39
SUPPORT...................................................................................................................... 39
CONCLUSION
40
ANNEXE A.
REFERENCES
41
ANNEXE B.
POUR DES INFORMATIONS COMPLEMENTAIRES
44
Prsentation de lIGC Windows Server 2003| Introduction
iii
1. Introduction
1.1.
Contexte
Les socits ouvrent de plus en plus leurs rseaux pour faciliter l'accs des employs aux
ressources et simplifier les interactions avec leurs clients et partenaires. Tandis que cet accs
tendu permet daccroitre la productivit, il prsente galement des dfis significatifs en
termes de scurit et dauthentification des utilisateurs. Beaucoup dorganisations se rendent
compte que les solutions traditionnelles bases sur le nom et le mot de passe utilisateur ne
sont plus suffisantes pour scuriser l'accs aux moyens et aux donnes sensibles de
lentreprise. Pour rpondre ces besoins, de nombreux diteurs proposent aujourdhui des
solutions sophistiques d'authentification telles que les cartes puces avec certificats
numriques embarqus.
De mme, scuriser les changes lectroniques entre entreprises, particuliers et
administrations est aujourdhui devenu une ncessit pour la mise en place dune informatique
de confiance. Ces infrastructures mettent en place une scurit accrue garantissant la qualit
des changes en renforant les procds dauthentification, lintgrit des donnes, la
confidentialit et la non rpudiation.
Le dploiement de ces infrastructures rpond galement aux exigences imposes par les
textes lgislatifs nationaux et communautaires en confrant certains actes mis par voie
lectronique une vritable valeur juridique (ex : loi du 13 mars 2000 portant adaptation du droit
de la preuve aux technologies de l'information et relative la signature lectronique,
http://www.legifrance.gouv.fr/texteconsolide/AREBV.htm).
Diffrents standards (Cf. Annexe A, section Standards issus du projet PKIX de lIETF )
ont t tablis et dfinissent les types de certificats utiliss afin de permettre une relle
interoprabilit avec les outils constitutifs des systmes dinformation et capables dexploiter
ces certificats pour garantir un niveau de scurit.
Pour rpondre tous ces besoins, les infrastructures de gestion de cls publiques (en abrg
IGC), appeles galement PKI (Public Key Infrastructure en anglais), apportent une
rponse approprie aux difficults techniques, organisationnelles et juridiques que posent la
scurisation des accs et des changes lectroniques. Cette approche base sur une
cryptographie asymtrique (comprenant une cl prive secrte et une cl publique) permet,
au-del des signatures numriques, de scuriser de nombreux types dchanges tels que la
messagerie scurise, les transactions commerciales en ligne via le protocole SSL/TLS, la
mise en place de tl procdures spcifiques, laccs aux ressources dun rseau (grce
IPsec), etc.
Bien que les certificats numriques et les supports cryptographiques soient une excellente
solution, ils peuvent introduire une complexit de gestion supplmentaire. Pour rpondre ses
nouvelles problmatiques de gestion, les administrateurs ont besoin d'un point central de
gestion des certificats numriques et des supports cryptographiques simples mettre en
uvre et exploiter. Cette technologie doit tre flexible, fonctionner naturellement avec
l'infrastructure existante et avoir la capacit intgrer une large varit de systmes.
Usages dune IGC
1.2.
Un des enjeux majeurs en matire de scurit pour les entreprises et les administrations est
de dterminer un moyen de limiter laccs des ressources sensibles.
Une infrastructure de gestion de cls constitue un de ces moyens. Elle est un ensemble de
composantes des technologies de l'information. Cet ensemble concourt la scurisation des
bi-cls en gnrant, et en assurant la gestion complte de certificats de cls publiques.
Le rseau ainsi cre est dtermin par la confiance porte un certificat qui dpend
directement de la confiance porte l'infrastructure de confiance toute entire. Cependant, la
nature distribue du systme d'information constituant l'IGC rend difficile l'valuation du niveau
de confiance accorder une infrastructure de gestion de cls. Revenons un instant sur les
fondements mme dune telle infrastructure.
1.2.1.
Chiffrement cl secrte
Pendant longtemps, le systme cryptographique le plus utilis a t le chiffrement symtrique

qui repose sur des cls secrtes partages (une seule et mme cl permet de chiffrer et de
dchiffrer).
Lmetteur et le rcepteur partagent la mme cl et chiffrent les donnes avec celle-ci, ainsi
seules ces personnes ont accs aux ressources protges par le chiffrement.
Un rseau de confiance se cre donc entre les diffrentes entits qui partagent la cl.
Si le secret de la cl est prserv, on sassure que les changes nont lieu quentre
interlocuteurs de confiance.
Des difficults subsistent quant la mthode employe pour scuriser le processus de
dlivrance de la cl (et de renouvellement de la cl dans le temps) puisque cette cl transitera
ncessairement un moment donn entre les deux entits pour que puisse stablir une
relation de confiance.
1.2.2.
Chiffrement cl publique
Le chiffrement asymtrique ou cl publique sappuie sur cls relies entre elles

mathmatiquement : une cl, dite prive , permet de chiffrer et une autre, dite publique ,
permet de dchiffrer ce que la premire a chiffr et rciproquement.
Il nest pas possible Il nest pas possible de driver la cl prive partir de la simple
connaissance de la cl publique en un temps raisonnable. En effet, les oprations
cryptographiques lies au chiffrement asymtrique se basent sur une fonction mathmatique
sens unique porte drobe (trap-door en anglais) plus facile calculer dans une direction
(sens aller) que dans la direction oppose (sens inverse) si lon ne connait pas la porte
drobe : le sens aller peut prendre quelques secondes, le sens inverse peut prendre des
mois, des annes, etc.
La cl publique donne une information sur la fonction, la cl prive une information sur la porte
drobe :
Celui qui connait la porte drobe peut calculer la fonction facilement dans le sens
inverse. Les autres, faute de porte drobe, peuvent simplement aller dans le sens
aller ;
Le sens aller est utilis pour le chiffrement et la vrification de la signature ;
Le sens inverse est utilis pour le dchiffrement et la gnration de la signature ;
Les changes de donnes sappuient aujourdhui sur des schmas de ngociation de cl

directement bas sur les principes de chiffrement cl publique. Une premire proposition de
ngociation de cl a fait son apparition en 1976 avec lalgorithme Diffie-Hellman (en abrg
*
DH) propos en tant que standard PKCS #3 [PKCS#3] qui permet deux partenaires de
ngocier une valeur de cl secrte (de session) la vole ; cet algorithme ne permet pas le
chiffrement/dchiffrement des donnes en tant que tels.
Dans ce nouveau schma, seules les cls publiques transitent entre les parties pour que
puisse stablir la relation de confiance. Le premier avantage tient au fait que seules les
donnes caractre public transiteront en clair sur le rseau avant d'tablir une
communication scurise pour acheminer les donnes sensibles .
De mme le problme li au processus dacheminement de la cl secrte aux parties
intresses ne se pose plus.
Toutefois le problme de lidentification reste entier puisquil est toujours ncessaire de
sassurer que la personne qui fournit sa cl publique est bien celle quelle prtend tre.
3 solutions sont envisageables pour pallier cette difficult :
1. Utiliser, comme dans le cas des cls secrtes, un change hors bande
(typiquement une disquette ou une cl USB) ;
2. Faire transiter la cl publique sur le rseau avec lchange dun condens (dit hash en
anglais) via une communication hors bande (typiquement le tlphone) ;
3. Utiliser une tierce partie de confiance reconnue comme telle par les deux parties :
lautorit de certification.
1.2.3.
Autorit de Certification
Chacune des deux parties fait confiance lautorit de certification (en abrg AC ou AC pour
Certificate Authority en anglais).
Elle dlivre des certificats a cl publique (ou certificats dans la suite de ce document) qui
sont des structures de donnes liant ( minima) la cl publique du propritaire avec son
identit, cela de faon non reproductible.
En produisant un certificat, lautorit fournie un acte sign par un algorithme cryptographique :
Je, soussign lAutorit de Certification, certifie avoir suivi ma politique de scurit et assure
que la cl publique dans ce certificat appartient rellement lidentit fournie dans ce
certificat.
Cela signifie que lautorit dispose dun politique de scurit (politique de certification), et
quelle est mise disposition des parties avant de commencer les oprations.
RFC 2631 Diffie-Hellman Key Agreement Method (http://tools.ietf.org/html/rfc2631) en 1999 puis norme ANSI X9.42 en 2000.
Autorit de
certification
(AC)
Requte signe par lAC
Requte
Poste client
1. Soumission dune demande de certificat lAC

Un des standards les plus utiliss pour les requtes est PKCS #10 [PKCS#10], qui
consiste en un champ DN (Distinguished Name en anglais), une cl publique et
optionnellement des attributs, le tout sign par lEntit dExtrmit (en abrg EE)
mettant la requte (ici client )
2. Validation de la requte de demande de certificat et tirage du certificat
LAC, aprs validation de sa politique de scurit (Security Policy en anglais), tire un
certificat, le signe ; le client le rcupre ensuite lissue du traitement (synchrone ou
asynchrone) de sa requte.
Un certificat est donc le rsultat sign du traitement favorable par lAC dune requte de
demande de certificat reu par celle-ci.
1.2.4.
IGC et scurit
La scurit repose ici toujours sur la cl prive, mais un nouvel acteur fait son apparition: lAC.
LAC est un lment sensible. On comprend bien que, si elle est compromise, toute relation
de confiance est perdue: un attaquant pourrait par exemple dlivrer ses propres certificats. Il
est ncessaire de veiller ce que cette autorit soit toujours bien protge.
Comme en matire de chiffrement asymtrique lmentaire (utilisation simple dune cl prive
pour chiffrer et dune cl publique pour dchiffrer), il est primordial de veiller la conservation
et non-divulgation des cls prives (celles des AC bien videmment ainsi que celles des
clients) car elles constituent la pierre angulaire de la confiance qui stablit entre les diffrentes
entits.
A compter de la dlivrance du certificat, les cls prives ne transitent plus sur le rseau.
Il est dailleurs important de protger la cl prive au moment o la demande de certificat
(requte) est transmise lAC et lors de la dlivrance de celui-ci.
Pour contourner ce problme et viter que la cl prive ne circule sur le rseau, certaines IGC,
telles que celle de Windows, permettent au requrant de gnrer sa propre paire de cls. Ci
tant, pour certaines demandes de certificat non lie la signature, la cl prive peut tout de
mme transiter de faon chiffre du requrant lAC pour des besoins de squestre de cls.
Techniquement, cela se traduit :
Parfois par la prsence de balises adquates de type <KEYGEN> dans des pages
Web et qui permettent au client de gnrer sa paire de cls de faon autonome,
Ou, en ayant recours, par exemple, au travers de CryptoAPI, linterface

programmatique de gestion des oprations cryptographiques de lenvironnement
Windows, un fournisseur de services cryptographiques (en abrg CSP pour
Cryptographic Service Provider en anglais). Il sagit dun module indpendant
effectuant les oprations cryptographiques de faon logicielle ou de faon matrielle
en relation avec un support cryptographique externe (par exemple une carte puce
dote dun processeur cryptographique).
1.2.5.
Composantes dune IGC
Les composantes dune IGC sont les suivantes :

Autorit de
certification
racine
Autorit de
certification
intermdiaire
Interne
Autorit de
certification
intermdiaire
Externe
Autorit de
certification
SSL
Rseau
dentreprise
Autorit de
certification
Authentification
Autorit de
certification
SSL
requete
requete
requete
certificat
certificat
certificat
Serveur Web
Poste client
externe
Autorit dEnregistrement (AE)
Poste client
interne
Autorit de certification (en abrg AC) - Le rle de lAC est central dans le cadre
dune IGC. Cette entit calcule les cls et tire (dite) le certificat associ en le signant
avec sa propre cl prive ce qui garantie lauthenticit du certificat. La livraison est
sous sa responsabilit technique et lgale. LAC va grer la liste des certificats
rvoqus et elle conserve le certificat de ses utilisateurs.
Elle peut dlguer le contrle didentit une structure proche des utilisateurs qui sera
reconnue sous le terme dAutorit denregistrement (en abrg AE ou RA pour
Registration Authority en anglais). La livraison du certificat peut tre ralise en ligne,
le certificat est rcupr directement sur lEntit dExtrmit (en abrg EE), le poste
client. LAC peut galement remettre par porteur ou face face le certificat contenu
sur disquette, carte, cl USB, etc. Une autorit de certification peut tre dsigne
autorit racine en tant que rfrence certifiant dautres AC.
Autorit de certification racine (en abrg ACR) - LACR a les mmes caractristiques
quune AC mais se place au sommet de la chane de confiance de lIGC.
Le certificat de cette autorit est auto sign et son rle se borne dlivrer des
certificats dautres autorits dites subordonnes.
Autorit administrative (en abrg AA) - Autorit responsable de l'IGC et assumant les
fonctions d'autorit de scurit, auxquelles s'ajoutent les fonctions de gestion. Elle a
un pouvoir dcisionnaire au sein de l'IGC
Autorit denregistrement (en abrg AE) - Composante de lIGC qui vrifie les
donnes propres au demandeur ou porteur de certificat ainsi que les contraintes lies
lusage dun certificat, conformment la politique de certification. LAE est une
composante optionnelle de lIGC qui dpend dau moins une AC.
10
2. Description des services dIGC

2.1.
Introduction
Les services de certificat de la plateforme Windows Server 2003 (R2) proposent des services
personnalisables pour la cration et la gestion de certificats cl publique X.509 v3 utiliss
dans les applications, services, systmes et dispositifs reposant sur les technologies cl
publique.
Les organisations peuvent sappuyer sur ses services pour amliorer la scurit en liant
lidentit dune personne, dune machine, dun dispositif ou dun service la cl prive
correspondante. Ces derniers comprennent dans le mme temps des fonctionnalits qui
permettent la gestion de lenrlement et de la rvocation des certificats dans un contexte
denvironnements distribus.
Les diffrents composants des services de certificats de Windows Server 2003 (R2)
permettent dmettre et de grer des certificats au format standard pour une utilisation par des
applications, services et systmes Microsoft, non Microsoft et/ou non Windows.
Ils autorisent ainsi la matrialisation dune infrastructure de confiance au travers de la mise en
uvre de services dIGC. Pour cette raison, ces services sont aussi simplement dnomms
dans la suite du document IGC Windows.
LIGC Windows constitue lune des solutions de gestion didentit et de contrle daccs
de Microsoft, au mme titre, par exemple, que :
Lannuaire dentreprise Active Directory avec lequel lIGC Windows propose une
intgration native important de nombreux services automatiss (Cf. plus bas)
Le systme de gestion du cycle de vie des identits, des certificats et supports

cryptographiques Identity Lifecycle Manager (en abrg ILM) 2007 qui offre les
services :
a. DAE volue pour des AC bass sur services de certificat Windows Server 2003
en mode entreprise avec le support de workflows personnalisables pour mettre
en conformit les processus organisationnels des entreprises avec leurs politiques
de scurit et de certification pour la dlivrance et la gestion des certificats X.509
utilisateur et des supports (carte puce, jeton USB etc.) ventuellement associs ;
b. De systme de gestion de supports cryptographiques (ou CMS pour Card
Management System en anglais), cette fonction constituant un lment essentiel
dune infrastructure de confiance lorsque des supports (carte puce, jeton USB
etc.) sont par exemple dploys grande chelle ;
Le systme de Web SSO, Web SSO extranet et de fdration didentit Active

Directory Federation Service (en abrg AD FS) vis--vis duquel une AC base sur les
services de certificat de Windows Server 2003 peut dlivrer des certificats (de
signature de jeton SAML, dauthentification client, dauthentification de proxy AD FS,
etc.) destination de ses diffrentes composantes ;
Prsentation de lIGC Windows Server 2003| Description des services dIGC
11
Ces diffrentes solutions sont prsentes dans le portail Web Microsoft IDA (Identity and
Access Solutions) ladresse Internet http://www.microsoft.com/identity.
2.2.
Prsentation gnrale
LIGC Windows sarchitecture autour des services dAC ainsi que des services de point de
publication en rendant disponible les certificats et les listes de rvocation (en abrg CRL pour
Certificate Revocation List en anglais). Elle comprend galement les outils de gestion des
certificats (gestion des audits, des rvocations, des missions ou toutes les autres tapes
dans la vie dun certificat).
Ce service peut sappuyer sur dautres services comme :
Un annuaire pour les identits numriques,
Une AE,
Une solution de gestion des supports cryptographiques,
Un systme de scurisation matriel (en abrg HSM pour Hardware Storage Module
en anglais),
Ainsi que des services rseaux classique DNS, SMTP, etc.
LIGC Windows propose une intgration possible avec Active Directory

permettant doptimiser :
La scurit de la solution en authentifiant les demandes,
Les cots de mise en uvre et dexploitation au quotidien en utilisant les stratgies de

groupes (en abrg GPO pour Group Policy Object en anglais) pour automatiser les
principales oprations dmission / renouvellement / remplacement / rvocation,
La disponibilit de la solution via les fonctionnalits de rplication propres Active

Directory.
Cette intgration native permet par ailleurs de garantir un fonctionnement optimal dans les
scnariis demands ceux-ci ayant dj t mis en uvre par de nombreuses entreprises au
niveau mondial avec des cots dintgration maitriss.
12
Description des services dIGC | Prsentation de lIGC Windows Server 2003
Une AC base sur les services de certificat Windows Server 2003 en mode entreprise, c'est-dire, quand elle est intgre Active Directory, propose les usages suivants :
Authentification des demandes,
Dlgation dadministration au sein de lautorit,
Dploiement des certificats des autorits racines via les stratgies de groupe,
Dploiement/renouvellement automatiss des certificats via les stratgies de groupe,
Stockage des gabarits de certificats dans Active Directory,
Renseignement optionnel des informations didentit au sein des certificats lors de la

gnration du certificat,
Publication optionnelle des certificats dans Active Directory.
Dans le cadre de ce livre-blanc nous proposons dutiliser une solution comme Microsoft ILM
2007 pour rendre les services complmentaires dAE et de gestion du support cryptographique
(CMS) mme si lIGC Windows intgre quelques fonctionnalits pouvant couvrir partiellement
ces besoins.
Diffrentes architectures sont envisageables :
Autorit unique sans intgration Active Directory (mode autonome) - Cette

architecture nest gnralement pas prconise car elle est moins riche
fonctionnellement et la plus onreuse exploiter. En effet, toutes les demandes
dmission ou de renouvellement de certificats doivent tre traites manuellement.
Autorit unique avec intgration Active Directory (mode entreprise) - Cette

architecture est essentiellement utilise dans le cas ou il ny a quune seule foret
Active Directory.
Autorits multiples avec intgration Active Directory (mode entreprise) - Cette

architecture est la plus souvent prconise car elle est la plus riche fonctionnellement,
sa mise en uvre est la plus simple et elle est supporte nativement, en outre :
a. Elle offre un niveau de scurit identique larchitecture AC unique via les
mcanismes de dlgation qui permettent de contrler les types de certificats
mis, les contraintes dmission et les populations cibles,
b. Elle offre un niveau de disponibilit identique larchitecture AC unique,
c.
Elle permet un regroupement gographique des autorits, permettant une

administration centralise,
d. Et enfin, cette architecture est prouve.
13
Dans ce cadre, les grands principes darchitecture que nous pressentons sont illustrs au
travers du schma suivant :
AC Racine (Hors ligne)
HSM
HSM rseau
AC Emettrice
AC Emettrice
AD
AD
AE
Fort Active Directory 1
AE
Fort Active Directory 2
Cette architecture est compose :
Dune autorit de certification racine (hors ligne) en mode autonome (pas de

rattachement une fort Active Directory) et assiste dun boitier HSM,
Pour chaque fort Active Directory :

a. Une AC mettrice,
b. Une AE, ce service peut tre couvert comme mentionn prcdemment par la
solution Microsoft ILM 2007.
Un boitier HSM en rseau pour le squestre des cls des diffrentes AC mettrice
Il est tout fait envisageable davoir plusieurs niveaux de hirarchie des AC. Ce schma
illustre simplement les principes darchitecture.
Dautre part, ce schma ne fait pas apparaitre les solutions de redondance ou de reprise sur
incident.
2.3.
Fonctionnalits
Les services de certificat de Windows Server 2003 (R2) proposent des services
personnalisables pour la cration et la gestion de certificats cl publique X.509 v3 utiliss
dans les applications, services, systmes et dispositifs reposant sur les technologies cl
publique.
Ils autorisent ainsi la matrialisation dune infrastructure de confiance au travers de la mise en
uvre de services dIGC.
14
Ces derniers sont des lments dinfrastructure par excellence et de ce fait ne sont par perus
par les utilisateurs. En effet, les interactions se feront dans les scnarii voqus
principalement par des autorits denregistrement.
Nanmoins la grande richesse fonctionnelle de lIGC Windows autorise des scenarii ou des
interactions entre lIGC et lutilisateur sont rendus transparent pour ce dernier de part la forte
lintgration des services de certificats de Windows Server 2003 (R2) avec lenvironnement
utilisateur. Le cycle de vie complet de certificats poste et utilisateur peut ainsi soprer sans
intervention pour permettre la mise en uvre de scnarii comme le Wifi scuris, le
chiffrement de flux en IPsec, le chiffrement et la signature sans support cryptographique, etc.
Pour une comprhension des fonctionnalits de cette solution nous avons souhaits apporter
un clairage sur ses principales caractristiques comme suit.
2.3.1.
Gestion des CRL et CRL diffrentielles
LAC disponible au sein de Windows Server 2003 (R2) au travers des services de certificat
supporte la publication des listes de rvocation vers les diffrents emplacements mandats
par les RFC et permet leur accs via les protocoles HTTP [RFC 2585], LDAP [RFC 2587] et
ventuellement CIFS.
Le ou les emplacements sont indiqus au sein de chaque certificat sous forme dURL dans le
champ CDP (cRLDistributionPoint).
Les emplacements de publications sont paramtrables et peuvent tre multiples (chemin
LDAP, chemin HTTP: ou fichier FILE:).
Dans une architecture distribue ou forte tolrance aux pannes, on privilgiera la publication
de la CRL dans Active Directory (chemin LDAP).
2.3.2.
Enrlement
LAC Windows Server 2003 supporte en standard les requtes de certification (en abrg CSR
pour Certificate Signing Request en anglais) au format PKCS #10 [PKCS#10], ainsi que les
messages PKCS #7 [PKCS#7]/CMS (Certificate Message Syntax en anglais) [RFC 3852] pour
la fourniture du certificat sign en retour.
Le standard CMC (Certificate Management over CMS en anglais) [RFC 2797] est support
nativement et permet une gestion plus scurise de lenrlement, en particulier le squestre
de la cl de chiffrement.
Les balises KEYGEN pour lenrlement HTTP sont supportes.
2.3.3.
Annuaire
LIGC Windows peut tirer parti de lannuaire Active Directory pour la gestion de lidentit et de
lauthentification.
En configuration mode entreprise , une AC Windows Server 2003 peut dlivrer
automatiquement, mcanisme appel auto-enrlement , des certificats des entits
(utilisateur, et/ou machines) dment authentifis et en suivant une politique de certification et
denrlement. Lauto-enrlement gre non seulement la certification des utilisateurs et/ou de
machines de manire automatique, mais aussi le cycle de vie des certificats, et en particulier
leur renouvellement (ou remplacement selon un autre gabarit).
15
Une AC Windows Server 2003 en mode entreprise publie automatiquement les certificats
mis dans lannuaire AD. Lannuaire Active Directory est interrogeable via LDAP pour
permettre aux applications daccder aux certificats de lorganisation.
Une AC Windows Server 2003 peut cependant tre installe en mode autonome , dans ce
cas elle nest pas couple avec Active Directory.
La personnalisation de module de stratgie (policy module en anglais), matrialisant une
politique de certification, et de module de sortie (exit module en anglais) permet de btir
une vritable architecture de certification sur mesure mettant en uvre des technologies de
fournisseurs htrognes.
Par exemple, un module de sortie spcifique peut publier les certificats mis dans un
annuaire LDAP. Il est frquent de placer en amont dune telle AC un serveur faisant office
dautorit denregistrement, comme par exemple Microsoft ILM 2007.
2.3.4.
Support des stratgies de groupe
Les stratgies de scurit peuvent s'appliquer des sites, des domaines ou des units
organisationnelles (OU) et affectent les groupes de scurit associs, groupes qui contiennent
des utilisateurs ou des ordinateurs. La stratgie de scurit relative l'IGC ne reprsente
qu'une partie de la stratgie globale de scurit de la plateforme Windows. Elle fournit un
mcanisme permettant de dfinir et de grer la stratgie de faon centralise, tout en veillant
son application sur l'ensemble du systme.
Les principaux aspects de la stratgie de scurit de l'IGC sont dcrits ci-dessous.
La fiabilit des AC racine peut tre tablie au moyen de stratgies, afin de crer les relations
d'approbation que les clients de domaine utiliseront pour vrifier les certificats de cl publique.
L'ensemble des AC de confiance est configur l'aide de l'diteur de stratgies de groupe. Il
peut tre configur pour chacun des ordinateurs, puis appliqu globalement tous les
utilisateurs de cet ordinateur.
L'administrateur peut, aprs avoir dfini une AC racine comme tant digne de confiance,
configurer les proprits d'utilisation associes celle-ci. Ces proprits permettent de limiter
le nombre de cas dans lesquels les certificats mis par l'autorit de certification sont valides.
Les restrictions spcifies s'appuient sur les identificateurs d'objet (en abrg OID pour Object
Identifier en anglais), comme cela est expliqu pour les extensions ExtendedKeyUsage dans
le document IETF PKIX.
La liste des OID utiliss au niveau de la plateforme Windows est prcise dans larticle
287547 OBJECT IDS ASSOCIATED WITH MICROSOFT CRYPTOGRAPHY
(http://support.microsoft.com/default.aspx?scid=287547).
Dans leur forme actuelle, ces restrictions permettent de limiter l'utilisation d'une combinaison
quelconque des lments ci-dessous :
Authentification du serveur,
Authentification du client,
Signature de code,
Courrier lectronique,
Systme de terminaison de scurit IP (IPsec),
Tunnel IPsec,
Utilisateur IPsec,
16
Horodatage,
Systme de fichiers chiffrs (en abrg EFS pour Encryption File System en anglais)
pour le systme de fichier NTFS.
Dans le cadre de l'intgration de l'IGC avec un environnement Active Directory, les

mcanismes de stratgie ont t prvus pour prendre en charge un processus d'enrlement
automatique des certificats. Ce processus repose sur deux lments cls : les gabarits
(modles) de certificat et les objets d'enrlement automatique. Ceux-ci sont intgrs l'objet
stratgie de groupe (en abrg GPO pour Group Policy Object en anglais) et peuvent tre
dfinis sur la base d'un site, d'un domaine, d'une unit organisationnelle, d'un ordinateur ou
d'un utilisateur.
2.3.5.
Gabarits de certificat
Une AC mettrice en mode entreprise permet de dfinir et de sappuyer sur des modles
(ou gabarits) de certificats.
Deux types de modles sont ainsi proposs : version 1, version 2 (une version 3 a t ajoute
dans les services de certificat de Windows Server 2008). La version 1 correspond aux
modles introduits historiquement avec Windows Server 2000, la version 2 ceux de
Windows Server 2003.
Les modles proposs par dfaut sont compltement personnalisables et peuvent ainsi tre
dupliqus en versions 2 et modifis de faon rpondre au(x) besoin(s) exprim(s) tant vis-vis du serveur (extensions, OID de politique, etc.) que du client (module cryptographique,
longueur de cl, cl exportable, etc.). Le gabarit dfinit diffrents lments, tels que les rgles
d'attribution de noms, la priode de validit, les CSP autoriss avec CryptoAPI pour la
gnration de cls prives, les algorithmes, ainsi que les extensions qui pourraient tre
ajoutes au certificat.
Les gabarits de certificats dfinissent aussi les fonctionnalits et les restrictions des types de
certificats. En utilisant des gabarits version 2 les paramtres additionnels suivants peuvent
tre dfinis pour chaque type de certificat :
Utilisation de lauto-enrlement pour la gnration et le renouvellement de certificat ;
Autoriser la squestre de cl prive (en vue dun recouvrement futur) ;
Publier le certificat dans un objet de compte Active Directory ;
Autoriser la gnration et le stockage des cls par les CSP, ainsi que la longueur de
cl minimum ;
Les utilisateurs et groupes autoriss enrler ou auto-enrler le certificat ;
Les autres extensions de certificat, incluant les stratgies de gnration et

dapplication.
D'une faon gnrale, chaque AC dfinit la liste des modles quelle peut offrir partir de la
liste des modles dclars dans Active Directory. Une mme AC permet d'offrir plusieurs
modles. L'AE liste son niveau les types de certificats disponibles qui peut correspondre
un sous ensemble des modles offerts par l'AC. Lentre Services dinscription au niveau
dActive Directory liste de faon globale les AE disponibles avec les modles ainsi proposs.
La page Web CERTIFICATE TEMPLATES OVERVIEW
(http://technet2.microsoft.com/windowsserver/en/library/e42693ef-374b-40a9-af3c569f0d1fe1c91033.mspx) prcise les 29 modles proposs par dfaut de Windows
Server 2003 (R2).
17
Cette liste extensible par duplication et personnalisation dun gabarit prdfini comprend, entre
autres, la signature, l'ouverture de session par carte puces, la scurisation de ml, la
signature de code logiciel, IPsec, 802.1X, l'authentification Internet via SSL/TLS (client et
serveur), les politiques de restrictions logicielles Windows Server et le chiffrement EFS pour le
systme de fichiers NTFS.
2.3.6.
Auto-enrlement / auto-renouvellement / auto-remplacement
Ce mode suppose une AC mettrice en mode entreprise dans la mesure o une intgration
avec lannuaire Active Directory est requise. Ce mode combine en effet les stratgies de
groupe (GPO) et les gabarits de certificats (Cf. ci-dessus) publis dans Active Directory.
Ce mode permet de disposer de mcanismes dauto-enrlement / auto-renouvellement / autoremplacement pour les utilisateurs, machines et services. Ce mode peut tre qualifi de
modle tout-auto offrant selon le niveau dapplication des GPO une granularit fine quant
la population cible.
Ce modle permet dallger les contraintes organisationnelles et techniques lors de la mise en
uvre dune infrastructure dIGC.
Le modle tout-auto est dcrit dans son ensemble dans le livre blanc CERTIFICATE
AUTOENROLLMENT IN W INDOWS SERVER 2003 ladresse Internet
http://www.microsoft.com/technet/prodtechnol/windowsserver2003/technologies/security/a
utoenro.mspx.
Par ailleurs, il nous parait important de mentionner ici que ce modle tout-auto a fait partie
de la cible dvaluation Critres Communs au niveau EAL 4+ (Cf. section 2.6.2 Evaluation
Critres Communs ci-dessous).
Enfin, le modle tout-auto peut fonctionner de pair avec les services ditinrance de
crdentits (Credential Roaming en anglais) si ces derniers sont activs. Ces services
permettent de dlivrer les certificats la session courante de la machine courante dun
utilisateur via la rplication Active Directory et les stratgies de groupes.
Ceci facilite lusage de fonctions comme la messagerie scurise (S/MIME), lauthentification
client TLS et propose une exprience utilisateur amliore pour lusage des supports (carte
puce, jeton USB) ;
Larticle 935441 W EBCAST: CREDENTIAL ROAMING BASICS ladresse Internet
http://support.microsoft.com/?id=935441 propose une vue densemble de ce service.
2.3.7.
Dlgation dadministration
Les services de certificats Active Directory de Windows Server 2003 intgrent un modle
dadministration qui permet de satisfaire aux exigences des critres communs (Cf. section
ponyme 2.5.3 et section 2.6.2 Evaluation Critres Communs ci-dessous) concernant
la sparation des rles et assurant ainsi quune seule personne ne soit pas capable de
compromettre la scurit des services dIGC.
A ces rles correspondent des droits daccs lAC et au serveur qui lhberge. Ces rles
possdent galement des quivalences en rle dadministration Windows, facilitant ainsi leur
implmentation.
Lactivation de la sparation des rles seffectue via lutilitaire certutil.exe.
18
Les bonnes pratiques observer dans ce domaine pourraient se rsumer ainsi :
Assigner les rles des groupes (et non pas des comptes utilisateurs) ;
S'assurer qu'un compte utilisateur ne se voit assign qu'un seul rle ;
Sassurer que les groupes pour lesquels les rles Gestionnaire de services dIGC, et
Gestionnaire de certificats sont assigns ne soient pas aussi administrateur local ;
Garder l'esprit que les administrateurs locaux restent tout puissants et ces droits
sont ncessaires pour le renouvellement du certificat de lAC ;
2.3.8.
Mise disposition des certificats
Les services de certificat de Windows Server 2003 proposent les modes de mise disposition
de certificat logiciel suivants vers lEE :
Lenrlement automatique par GPO,
Par la MMC,
Par linterface web denrlement,
Par API.
Ces services proposent pour la mise disposition de certificat sur support cryptographique
lenrlement par dlgation un agent denrlement (disposant dun certificat dagent
denrlement).
La publication par mail peut tre ralise via un module de sortie (exit module en anglais)
spcifique ; ce dernier reoit lensemble des notifications du moteur lorsque des oprations ont
lieu (par exemple lmission dun certificat) et peut donc publier les informations ncessaires.
Une description de linterface de ce module est disponible ladresse Internet
http://msdn2.microsoft.com/en-us/library/Aa382386.aspx.
Microsoft ILM 2007 en tant quAE propose une souplesse accrue en termes de scnarii pour la
mise disposition de certificat sur lEE ou sur le support cryptographique.
2.3.9.
Fonction de squestre / recouvrement des cls de chiffrements
Les services de certificat de Windows Server 2003 permettent, par le biais des agents de
rcupration de cls (en abrg KRA pour Key Recovery Agent en anglais), dassurer des
fonctions de squestre et de recouvrement de la cl prive des utilisateurs.
Cette dernire est stocke dans la requte de lutilisateur, elle-mme stocke dans la base de
donnes de lAC.
Un aspect important de larchivage et de la rcupration des cls est quaucune cl permettant
de dchiffrer les cls des utilisateurs, protges par les KRA, ne rside sur lAC. Cela afin de
ne pas pouvoir compromettre la scurit des cls archives.
La fonction de squestre et de recouvrement des cls de chiffrements permet :
La fourniture par lutilisateur de sa cl prive lAC avec la requte de certificat ;
Le stockage scuris des cls avec les certificats X.509 v3 dans la base des
certificats.
19
L'IGC Windows offre des mcanismes manuel et automatique de squestre de cls de

chiffrement.
Ceci requiert que lAC soit configure pour supporter cette fonctionnalit de squestre et de
recouvrement et que lactivation de la sparation des rles, lidentification du ou des KRA et
lmission leur intention dun certificat KRA soient mis en uvre.
Le mode manuel repose sur la commande certutil.exe -importkms qui permet le squestre
manuel de cl partir d'un export de la cl dans un fichier PKCS #12 [PKCS#12].
Le mode automatique sappuie sur la fonctionnalit dauto-enrlement / auto-renouvellement.
Il est ncessaire, dans ce cas, que le gabarit du certificat considr ait la fonction de
squestre de cl active.
La cl prive est alors automatiquement transmise sous forme chiffre dans la requte
d'enrlement CMC conformment la RFC 2797 [RFC 2797] pour squestre.
En terme de recouvrement, seul le gestionnaire de certificats, si la sparation des rles est
active, peut extraire les cls squestres sous leur forme chiffre (blob authentifi PKCS #7
[PKCS# 7] - ICertAdmin2::GetArchiveKey Certadm.dll) pour les fournir un agent de
recouvrement.
Cette opration est ralise via la commande certutil.exe getkey pour lobtention du blob de
recouvrement PKCS#7 [PKCS# 7] depuis lautorit de certification considre et son criture
dans un fichier. Le blob est chiffr avec la cl publique du certificat du ou des KRA
destinataire(s).
Le KRA utilise la commande certutil.exe -recoverkey pour (en conjonction avec sa cl prive)
extraire la cl et la remettre dans un PKCS #12 [PKCS#12] (.pfx) chiffr avec un mot de
passe.
Ce fichier sera alors transmis l'utilisateur.
Compte tenu de cette description succincte, le recouvrement d'une cl prive constitue un
processus manuel qui exige, pour l'utilisateur qui a perdu sa cl prive, de contacter le
gestionnaire de certificats afin de lui demander de procder son recouvrement.
L'identification de l'utilisateur demandant le recouvrement, la transmission du fichier blob de
recouvrement l'agent de recouvrement et la transmission du fichier .pfx contenant la cl
recouvre avec son mot de passe l'utilisateur constituent autant dtapes qui doivent tre
soigneusement planifies.
Ce modle de recouvrement permet la sparation des rles et des pouvoirs dcisionnel et
excutif vis--vis desquels le gestionnaire de certificats et lagent de recouvrement sont des
personnes physiques diffrentes. Le gestionnaire de certificats peut dcider de recouvrir une
cl mais na pas accs la cl alors que le KRA peut seulement accder une cl dont le
recouvrement a t dcid.
2.3.10. Support du protocole OCSP

Les services de certificat de Windows Server 2003 supportent le protocole Online Certificate
Status Protocol (OCSP) [RFC 2560] et s'appuient en termes de fournisseur et rpondeur sur
les offres tierces suivantes :
Ascertia TrustFinder OCSP (http://www.ascertia.com/products/tf_ocsp),
Corestreet Server Validation Extension (SerVE)

(http://www.corestreet.com/products/serve.html),
Tumbleweed Communications Valicert Validation Authority (VA)

(http://www.tumbleweed.com/products/validationauthority.html),
20
Kyberpass Validation Server

(http://www.kyberpass.com/products/trustplatform/index.html),
RSA Validation Solution (http://www.rsasecurity.com/node.asp?id=1355).
Par ailleurs, les services de certificat de Windows Server 2003 permettent de gnrer des
certificats OCSP (emplacement de l OCSP Responder prcis dans lextension AIA) ainsi
que des certificats OCSP Responder pour le rpondeur en ligne.
Windows Server 2008 permet la mise en uvre de la fonctionnalit de rpondeur en ligne
OCSP avec le dcodage des requtes de statut de rvocation pour des certificats donns,
lvaluation du statut de ces certificats, lenvoi en retour dune rponse signe contenant
linformation de statut demande.
Ce service est dcrit dans le livre blanc INSTALLING, CONFIGURING, AND
TROUBLESHOOTING THE MICROSOFT ONLINE RESPONDER ladresse Internet
http://technet2.microsoft.com/windowsserver2008/en/library/045d2a97-1bff-43bd-8deaf2df7e270e1f1033.mspx.
2.4.
Architecture
2.4.1.
Hirarchies dAC
LIGC Windows supporte un modle dAC hirarchique. Une hirarchie de certification apporte
la monte en charge, la facilit dadministration et la liaison avec des offres dIGC tierces.
Dans sa plus simple forme, une hirarchie de certification consiste en une seule AC.
Cependant, en gnral, une hirarchie plusieurs AC avec des relations parent-enfant bien
dfinies. Dans ce modle, les AC enfants subordonnes sont certifies par le certificat gnr
par leur AC parent, ce qui lie la cl publique dune AC son identit. LAC au sommet de la
hirarchie est appele ACR. Les AC enfants de lautorit racine sont appeles AC
subordonnes.
Dans Windows XP et Windows Server 2003, si vous faites confiance une ACR (car
son certificat est rfrenc comme ACR de confiance dans le magasin de certificats),
vous faites confiance toutes les AC subordonnes de la hirarchie, moins quune
AC subordonne ait eu son certificat rvoqu par son AC parent ou que son certificat
soit expir.
Lutilisation dune hirarchie dAC introduit aussi un certains nombre de scnarii pratiques
de mise en uvre notamment :
Par usage, des AC subordonnes sont alors ddies lmission de certificats pour
des besoins particuliers, tels que le courriel scuris ou lauthentification rseau ;
Par organisation, des AC subordonnes mettent des certificats selon lorganisation

de lentreprise ;
Par rpartition gographique ;
Pour de la rpartition de charge, des AC subordonnes mettent les mmes types de

certificats ;
Pour de la sauvegarde et de la tolrance aux pannes.
21
Une hirarchie de certification fournit aussi les bnfices suivants :
Une configuration flexible de la scurit de lAC pour rpartir au mieux scurit et

facilit dutilisation, comme la force de la cl, la protection physique et la protection
contre des attaques rseau ;
La capacit darrter une partie de la hirarchie sans en affecter les autres membres.
Une sous-hirarchie dAC mise en uvre au travers des services de certificat de Windows
Server 2003 peut tre rattache une hirarchie mise en uvre par des technologies non
Windows. Dans ce cas, le certificat dune AC Windows Server 2003 est sign par une AC non
Windows.
A linverse, une AC Windows peut mettre des certificats pour des AC non-Windows
permettant ainsi de rattacher une racine (racine AC Windows, ou hirarchie de AC Windows)
une branche dAC mise en uvre par des technologies de fournisseurs tiers.
AC Racine
Tierce / Publique
AC
Intermdiaire
AC
Emettrice Externe
AC
Emettrice
Fort Active Directory
2.4.2.
Certification croise
La notion de hirarchie de type certification croise (Cross Certification en anglais) est dcrite
dans la RFC 3280 [RFC 3280].
Les services de certificats de Windows Server 2003 (R2) permettent la mise en uvre de ce
modle par la subordination qualifie qui autorise la dfinition de contraintes (contraintes
lmentaires, contraintes de noms, contrainte de politique, contraintes application).
La subordination qualifie offre deux applications pratiques :
1. Quels certificats d'un partenaire peut-on valider / accepter ? La subordination qualifie
permet doffrir un contrle plus prcis de la confiance des certificats avec linclusion /
exclusion d'usages (purposes en anglais). Par exemple, la subordination qualifie peut
22
permettre l'usage d'un certificat tiers pour ml seulement, alors que le certificat
spcifie e-mail et IPsec.
2. Contrler l'mission des AC subordonnes. Ceci permet dempcher les AC
d'mettre :
Dans des espaces de noms invalides / non autoriss ;
Avec des politiques d'mission invalides / non autorises ;
Avec des politiques d'application invalide / non autorises ;
La subordination qualifie est compltement dcrite dans le livre blanc PLANNING AND
IMPLEMENTING CROSS-CERTIFICATION AND QUALIFIED SUBORDINATION USING W INDOWS
SERVER 2003 ladresse Internet
http://www.microsoft.com/technet/prodtechnol/windowsserver2003/technologies/security/
ws03qswp.mspx.
2.4.3.
Support de lAC Pont
Le modle AC Pont (Bridge en anglais) selon le principe Federal Bridge Certification Authority
(FBCA) est galement support par les services de certificats de Windows Server 2003.
A ce titre, les services de certificat de Windows Server 2003 (R2) sont certifis US Federal
Bridge AC (Cf. http://www.cio.gov/fbca/techio.htm).
Un exemple de mise en uvre est linfrastructure de confiance WISeKey Certify ID
(http://www1.wisekey.com/index.aspx).
Lutilisation de ttes de pont permet linteroprabilit entre un nombre plus important de
hirarchies ou sous-hirarchies IGC dorganisations spares.
2.4.4.
Architecture physique
Un rseau ouvert avec une connectivit transparente entre toutes les connexions est le
meilleur promoteur dune IGC. Cependant, les rseaux complexes utilisent des pare-feu pour
contrler le trafic. De ce fait, une fonctionnalit comme lauto-enrlement (sappuyant sur
DCOM) ne sera pas disponible sur tous les points du rseau. Dans un environnement
scuris, on privilgiera la fourniture de certificats via un enrlement Web ou personnalis.
Nous illustrons cela par un exemple darchitecture dAC selon trois scnarii:
Le Centre de Donnes Centralis (en abrg CDC, Centralized Data Center en

anglais) ;
Le Centre de Donnes Extranet (en abrg CDE, Extranet Data Center en anglais) ;
Le Centre de Donnes Internet (en abrg CDI, Internet Data Center pour en anglais).
Les scnarii Centre de Donne Internet, Extranet et Centralis requirent chacun leur propre
infrastructure dAC. Parce que le centre de donnes Internet est relativement indpendant de
linfrastructure de lentreprise, il est raisonnable dy installer une IGC spare.
23
Exemple dinfrastructure dAC

Centre de Donnes Centralis
Le scenario CDC exploite 2 principaux groupes dAC mettrices (CA111 AC 114) chaines
une seule AC intermdiaire hors-ligne, CA11. CA11 est elle-mme chaine CA1, racine de
confiance de lentreprise. Une seconde autorit CA2 auto-signe fait partie du CDC pour
apporter les certificats routeur.
CA111 et CA112 sont des AC redondantes et en ligne qui mettent des certificats aux
utilisateurs quand un processus de remise en main propre est ncessaire. CA113 et CA114
mettent des certificats ncessitant moins de contraintes de remise scurise, comme par
exemple des certificats techniques. Toutes les AC peuvent publier leurs certificats utilisateurs
dans Active Directory, si ncessaire.
Les deux AC, nommes CAx11 et CAx12, mettent des certificats dans les cas ou les
utilisateurs communiquent avec des tiers extrieurs lentreprise. Les deux AC sont chaines
une ACR externe. Le certificat de lACR externe est dploy par le service de mise jour de
racine de Windows pour bnficier de racines de confiance par dfaut.
Centre de Donnes Extranet
Le scnario CDE exploite 3 AC mettrices chaines une AC intermdiaire ddie (CA12),
laquelle est gre par des administrateurs externes. CA12 est chaine lAC racine de
lentreprise, CA1. CA121 et CA122 sont redondantes et mettent des certificats pour les
membres de lextranet. Les deux AC mettrices publient les certificats utilisateur sur le
contrleur de domaine de lextranet. CAx2 est chain une ACR publique et met des
certificats ou la confiance en la racine publique est ncessaire.
Centre de Donne Intranet
Le scnario CDI utilise une hirarchie spare avec deux AC mettrices redondantes, CA31 et
CA32. Les deux AC publient les certificats utilisateurs sur le contrleur de domaine du CDI.
Parce que le CDI est spar des autres centres de donnes, il utilise une ACR spare, CA3,
24
qui est le parent de CA31 et de CA32. CAx3 est chaine une AC racine publique pour
mettre des certificats ncessitant une racine de confiance publique.
Pour tablir une relation de confiance entre les CDI et CDC, une certification croise avec
subordination qualifie doit tre dfinie (Cf. section 2.4.2 Certification croise ci-dessus).
Un cluster de serveur Web, prsent dans la zone primtrique, fournit une copie de chaque
CRL toutes les AC pour rendre les CRL disponibles publiquement.
Le serveur AD/AM de la zone primtrique collecte les utilisateurs et les certificats de toutes
les forts et reprsente donc le rfrentiel central scuris des certificats. La synchronisation
des donnes est effectue par la solution Microsoft ILM 2007.
En fonction des diffrents niveaux de publication, les certificats sont visible pour diffrents
groupes utilisateurs. Le serveur AD/AM fournit aussi les CRL et les certificats dAC pour les
clients qui ne peuvent pas ou ne doivent pas rcuprer du contenu HTTP de lInternet.
2.4.5.
Environnement multi-forts
Dans un environnement ou de multiples forts Active Directory sont prsentes, il est

ncessaire de fournir un rfrentiel des certificats qui autorise lchange de certificat interforts.
Par dfaut, les informations de certificats, CRL et dAC sont disponibles seulement dans leur
propre fort Active Directory.
Dans un environnement multi-forts Active Directory, il est ncessaire de dfinir les AC
membre de chaque fort en fonction des contraintes applicatives et/ou de certificat.
Par exemple, pour fournir des certificats SSL des serveurs Web de diffrentes forts, il nest
pas obligatoire davoir des AC dans chacune dentre elles car les serveurs SSL peuvent
enrler manuellement des certificats partir dune AC dune autre fort Active Directory.
Dans les versions actuelles de Windows, une fort dfinie la frontire externe dune
AC en mode entreprise; les entits qui appartiennent diffrentes forts ncessites
donc des AC en mode entreprise spares. Le nombre de domaines dans une fort
Active Directory ne joue, par contre, aucun rle sur le nombre dAC mettrices.
2.5.
Administration et Exploitation
LAC disponible au sein de Windows Server 2003 permet une exploitation soit via une
interface graphique de type console MMC soit via une interface mode ligne de commande.
2.5.1.
Scurisation des accs logiques
La scurisation des accs logiques passe, par exemple, par les actions dadministrations
suivantes :
Forcer une authentification par carte puce ;
Contrler lappartenance aux groupes sensibles ;
Activer la sparation des rles.
25
2.5.2.
Scurisation des accs physiques
La scurisation des accs physiques rentre dans le cadre de loffre de services (livrables) qui
accompagne la mise en uvre dune infrastructure de confiance.
2.5.3.
Dlgation dadministration
Les services de certificats de Windows Server 2003 (R2) intgrent un modle dadministration
qui permet de satisfaire aux exigences des critres communs (Cf. section 2.6.2 Evaluation
Critres Communs ci-dessous) concernant la sparation des rles et assurant ainsi quune
seule personne ne soit pas capable de compromettre la scurit des services dIGC.
Les rles que lon peut ainsi mettre en uvre sont conformes ceux dcrits dans le
document CERTIFICATE ISSUING AND MANAGEMENT COMPONENTS FAMILY OF PROTECTION
PROFILES ladresse Internet
http://csrc.nist.gov/pki/documents/CIMC_PP_20011031.pdf.
Une AC Windows Server 2003 (R2) propose en standard des rles dadministration qui
peuvent sadapter la plupart des processus de gestion du cycle de vie des certificats et des
services dIGC :
Gestionnaire de services dIGC - Configure et administre les serveurs de certificats,

dsigne les gestionnaires et renouvelle les certificats des autorits de certification ;
Gestionnaire de certificats - met et rvoque les certificats pour des groupes

d'utilisateurs sur lesquels ils ont juridiction ;
Agent de recouvrement ;
Demandeurs - utilisateurs authentifis tant autoriss mettre une requte de

certificat sur lAC. Cela ne correspond pas un rle dadministration sur lAC ;
Auditeur - Audite les actions des administrateurs locaux, des gestionnaires de services
et de certificats ;
Oprateur de sauvegardes.
A ces rles correspondent des droits daccs lAC et au serveur qui lhberge. Ces rles
possdent galement des quivalences en rle dadministration Windows, facilitant ainsi leur
implmentation.
2.5.4.
Plan de Reprise dActivit (PRA)
La mise en uvre dune IGC doit ncessairement intgrer la dfinition de plans de reprise
dactivit et de continuit dactivit afin dassurer la meilleure disponibilit de se service. Il est
ncessaire de distinguer les diffrents composants de larchitecture afin den dfinir le niveau
de disponibilit attendu qui sera dtermin par limpact en cas dindisponibilit et la frquence
et la dure dindisponibilit estims.
De part nos retours dexprience auprs des milliers de clients ayant mis en uvre nos
solutions, il apparat que le composant le plus critique au bon fonctionnement de
linfrastructure de gestion de cls est laccs aux CRL dont la consultation est obligatoire. Il est
donc impratif que les CRL soient consultables en tout point de lenvironnement et avec une
garantie de disponibilit de 100%, il est possible dobtenir ce type de disponibilit soit en
multipliant les points de publication des listes de rvocation dfinis de certificats mis soit en
26
redondant et mettant en rpartition de charge les points de publication par exemple laide de
moyens rseau redonds.
Dans une architecture distribue, cette disponibilit pourra tre obtenue par la publication de la
CRL dans Active Directory, et donc par sa disponibilit au sein de chaque contrleur de
domaine.
La disponibilit des autres composants de lIGC, AC et AE, nest pas aussi critique que celle
des CRL (ou de linformation de rvocation) et devra tre dfinie de manire prcise lors de la
phase de dfinition darchitecture dtaille de faon dterminer le niveau protection
ncessaire (depuis la mise en uvre de procdures de sauvegarde et de restauration de type
System State jusqu la mise en uvre de solutions entirement redondantes ncessitant de
dployer un nombre deux fois plus important de machines hbergeant les services de lautorit
de certification).
Il est, par ailleurs, noter que dans le cas de lmission/renouvellement automatique des
certificats les contrleurs de domaine sont amens jouer un rle dAE et que dans ce cas la
disponibilit/redondance est assure par les mcanismes propres Active Directory.
Vous trouverez de plus amples informations sur les recommandations en termes de
scurisation et de mise en uvre de procdures de sauvegarde ladresse suivante :
https://www.microsoft.com/technet/prodtechnol/windowsserver2003/technologies/security/
mngpki.mspx.
2.5.5.
Audit
Une AC Windows Server 2003 permet la fois laudit dvnements russis ou ayant
chous, qui sont inscris dans la file dattente de Scurit de la base dvnements de
Windows. Les catgories dvnements suivants sont supportes :
Sauvegarde et restauration de la base de lAC ;
Modification dans les configurations de lAC ;
Modification des paramtres de scurit de lAC ;
Gestion et Gnration de requtes de certificats ;
Rvocation de certificats et publication de CRL ;
Archivage et recouvrement de cls archives ;
Lancement & Arrt des services de certificats.
2.5.6.
Gestion des traces
Larchitecture de la plateforme Windows propose une structure daccueil pour lenregistrement

dvnements dans diffrents journaux (application, scurit, systme, etc.) avec des
mcanismes de notification et de collecte, chaque vnement ayant des attributs clairement
identifis comme une source, un ID, un contexte de scurit, etc.
Des interfaces dinstrumentation de la plate-forme comme Windows Management
Instrumentation (en abrg WMI) ou des solutions de supervision comme Microsoft System
Center Operation Manager (en abrg SCOM) tirent directement bnfices de cette approche
standard plateforme pour proposer une exploitation avance de ces informations comme
notamment de la corrlation dvnements pour le dclenchement automatis doprations de
tches dexploitation.
27
Les journaux utiliss peuvent tre dimensionns en consquence et offrent une gestion
circulaire si besoin.
Comme toute application respectant les rgles de dveloppement de la plateforme Windows,
les services de certificats de Windows Server 2003 (R2) sappuient de faon approprie sur
ces journaux pour lenregistrement des vnements qui lui sont relatifs. Le format
dexportation peut tre converti au standard W3C.
Au-del de ce comportement par dfaut rien nempche la configuration dun module de sortie;
ce module recevant lensemble des notifications du moteur lorsque des oprations ont lieu (par
exemple lmission dun certificat) peut donc stocker les logs dans une base SQL ou dans un
fichier de log.
Il sagit de lun des deux points dextensibilit du moteur tel que dcrit dans la page
MSDN CERTIFICATE SERVICES ARCHITECTURE ladresse Internet
http://msdn2.microsoft.com/en-us/library/Aa376540.aspx.
Lutilisation dun module de sortie personnalis pour le stockage des logs dans une base
Microsoft SQL Server conjointement lutilisation de Microsoft Reporting Services permet
dlaborer des tats avancs.
Cette approche est, par exemple, celle suivie par la composante CMS de lenvironnement
Microsoft ILM 2007.
Il est possible de signer les fichiers, mais cette fonctionnalit nest pas intgre nativement.
Dautre part, il est possible de tracer les actions (modifications) sur les traces.
2.5.7.
Support de la virtualisation
Une seule AC peut tre installe par instance serveur de Windows Server 2003. Par contre,
une plateforme Windows Server 2003 comprenant le service de certificat est virtualisable dans
une machine virtuelle gre par Microsoft Virtual Server 2005.
La politique de support en environnement virtualis est dcrite ladresse Internet
suivante : http://support.microsoft.com/kb/897613.
Les ressources techniques relatives Microsoft Virtual Server sont disponibles
ladresse Internet
http://www.microsoft.com/windowsserversystem/virtualserver/default.mspx.
Une mme License Windows Server 2003 permet dutiliser sur la plateforme hte jusqu 4
machines virtuelles Windows Server 2003.
2.6.
Interoprabilit
Linteroprabilit, aussi bien entre organisations, quau sein dun environnement htrogne
dune mme organisation est assure au travers du support des standards PKIX.
Linteroprabilit de lAC Windows Server 2003 a t dmontre dans le cadre du projet pki
Challenge (en abrg pkiC), plus large projet dinteroprabilit IGC conduit ce jour sous
lgide de lEEMA, the independent European association for e-business, et cofinanc par le
gouvernement suisse et la Commission Europenne. Ce projet vise identifier, analyser et
dpasser les problmatiques dinteroprabilit entre les fournisseurs de solutions dIGC.
Les diffrents rapports sont disponibles aux adresses Internet suivantes:
http://www.eema.org/index.cfm?fuseaction=focus.content&cmid=148&CFID=1265205&C
28
FTOKEN=5d0b84ad83bfb3db-EE165315-FE45-BA16-A015751C772C5C43 et
http://www.eema.org/downloads/security_finished_papers/pkiC_final_report.pdf.
Lautorit de certification Microsoft est par ailleurs certifie US Federal Bridge AC
(http://www.cio.gov/fbca/techio.htm)
2.6.1.
Boitiers HSM
Les services de certificats de Windows Server 2003 (R2) supportent lutilisation de boitiers
matriels (en abrg HSM pour Hardware Storage Module en anglais) pour le stockage des bicls.
Ceci suppose simplement pour ces matriels la disponibilit dun CSP comme cest le cas
avec :
AEP SureWare Keyper Enterprise

(http://www.aepnetworks.com/products/key_management/keyper/ent_overview.aspx) FIPS 140-2 Level 4,
Algorithmic Research PrivateServer (http://www.arx.com/PrivateServer.html) - FIPS

140-1 Level 3,
Crysalis/Rainbow/SafeNet Luna SA (http://www.safenetinc.com/products/pki/lunaSA.asp) - FIPS 140-2 Level 3,
Crysalis/Rainbow/SafeNet Luna CA3 (http://www.safenetinc.com/products/pki/lunaCA3.asp) - FIPS 140-1 Level 3,
Eracom ProtectServer Orange (http://www.eracomtech.com/protectserver_orange.0.html) - FIPS 140-1 Level 3,
nCipher nShield
(http://www.ncipher.com/cryptographic_hardware/hardware_security_modules/8/nshiel
d/) - FIPS 140-2 Level-3 ;
Et nCipher netHSM
(http://www.ncipher.com/cryptographic_hardware/hardware_security_modules/10/neth
sm) - FIPS 140-2 Level-3 ;
Lutilisation de botiers HSM est recommande pour les AC en ligne. Cette dernire peut
ncessiter plusieurs oprateurs/administrateurs pour dmarrage, avec cartes.
2.6.2.
Evaluation Critres Communs
Lvaluation Critres Communs (en abrg CC pour Common Criteria en anglais) est un
standard international (ISO/CEI 15408) pour la scurit des systmes d'information. Le nom
complet du standard est Common Criteria for Information Technology Security Evaluation.
Les Critres Communs a pour vocation dtre utiliss comme base pour lvaluation des
proprits de scurit des produits et systmes des Technologies de lInformation. En
tablissant une telle base de critres communs, les rsultats dune valuation de la scurit
des Technologies de lInformation seront significatifs pour une plus large audience.
Les CC permettent de comparer les rsultats dvaluations de scurit menes
indpendamment les unes des autres. Cela est rendu possible grce un ensemble commun
dexigences pour les fonctions de scurit des produits et systmes et pour les mesures
dassurance qui leur sont appliques pendant une valuation de scurit. Le processus
dvaluation tablit un niveau de confiance dans le fait que les fonctions de scurit de tels
29
produits et systmes et les mesures dassurance qui leur sont appliques satisfont ces
exigences. Les rsultats de lvaluation peuvent aider les acheteurs dterminer si le produit
ou le systme est suffisamment sr pour lapplication quils envisagent et si les risques lis la
scurit qui sont implicites dans son utilisation sont tolrables.
Les CC sont utiles en tant que guide pour le dveloppement des produits ou systmes incluant
des fonctions de scurit des Technologies de lInformation et pour lapprovisionnement de
produits ou systmes commerciaux dots de telles fonctions. Pendant lvaluation, un tel
produit ou systme est qualifi de cible dvaluation (en abrg TOE pour Target Of
Evaluation en anglais). De telles TOE peuvent tre par exemple des systmes dexploitation,
des rseaux informatiques, des systmes distribus et des applications.
Vous trouverez lensemble de la documentation relative au CC sur le site de la Direction
Centrale de la Scurit des Systmes dInformation (en abrg DCSSI) CRITERES ET
METHODOLOGIE D'EVALUATION ladresse Internet suivante :
http://www.ssi.gouv.fr/fr/confiance/methodologie.html.
Les services de certificat de Windows Server 2003, ainsi que la plateforme Windows sousjacente, ont fait et font, selon les versions considres, lobjet dune valuation Critres
Communs.
Ainsi, Les services de certificat de Windows Server 2003 sont aujourdhui :
EAL (Evaluation Assurance Level) 4+ : EAL 4 Augmented with ALC_FLR.3

(Systematic Flaw Remediation) and AVA.VLA.4 (Highly Resistant Vulnerability
Analysis) ;
Conforme avec CIMC (Certificate Issuing and Management Components) Security

Level 3 Protection Profile, version 1.0 ;
Le rapport dvaluation Critres Communs correspondant est disponible ladresse

Internet http://www.commoncriteriaportal.org/public/files/epfiles/st_vid9507-vr.pdf ainsi
que sur le site du NIAP (National Information Assurance Partnership) la page NIAIP
CERTIFICATION FOR W INDOWS SERVER 2003 CERTIFICATE SERVER (http://niap.nist.gov/ccscheme/st/ST_VID4024.html).
La plateforme Windows Server 2003 SP1 (tout comme Windows XP SP2) est galement EAL
4 Augmented with ALC_FLR.3 (Systematic Flaw Remediation) and AVA.VLA.4 (Highly
Resistant Vulnerability Analysis).
Le rapport dvaluation Critres Communs correspondant est disponible ladresse
Internet http://www.commoncriteriaportal.org/public/files/epfiles/st_vid9506-vr.pdf ainsi
que sur le site du NIAP la page NIAP CERTIFICATION FOR W INDOWS XP SP2 AND
W INDOWS SERVER 2003 SP1 (http://niap.nist.gov/cc-scheme/st/ST_VID4025.html).
2.7.
Standards supports
LIGC Windows respecte les standards mentionnes explicitement en Annexe A, section

Standards issus du projet PKIX de lIETF issus du groupe de travail Public Key
Infrastructure X.509 (en abrg PKIX. Il sagit en particulier des standards tels que RFC 2459
[RFC 2459], RFC 3280 [RFC 3280], RFC 2560 [RFC 2560].
Les certificats dlivrs par lIGC Windows sont au format X.509 v3 [RFC 3280], ce qui permet
de modifier les extensions des certificats pour rpondre des besoins spcifiques (des
informations dauthentification par exemple) ce qui peut gnrer parfois des difficults en
matire dinteroprabilit.
LIGC Windows permet de dfinir ses propres extensions dans des gabarits (ncessite une AC
en mode entreprise ), et contourne ainsi la difficult.
30
LIGC Windows se base galement sur les standards RSA Security PKCS #1 [PKCS#1],
PKCS #7 [PKCS#7], PKCS #10 [PKCS#10], PKCS #12 [PKCS#12].
Pour ce qui est de PKCS #11, Microsoft a pris la dcision de ne pas le supporter ; ce dernier
tant jug inutilement lourd, compliqu et peu performant. PKCS #11 est, en effet une API trs
vaste rarement implmente dans son ensemble.
Lensemble des fonctions prvues par PKCS #11 est support en standard par CryptoAPI,
lAPI de gestion des oprations cryptographiques de la plaeforme Windows. CryptoAPI
rpond aux besoins cryptographiques des applications, et sapplique par consquent aux
traitements de son IGC.
Dans ce contexte, CryptoAPI permet nativement de :
Les oprations de chiffrement avec les algorithmes standard (MD5, SHA-1, RC2, RC4,
DES, 3DES, AES, RSA, DSS, DH),
La gestion des messages de signature et de chiffrement aux formats standard

(PKCS #7 [PKCS#7], CMS [RFC 3852]),
La gestion des demandes de certificat, des certificats et des CRLs aux formats
standards (PKCS #10 [PKCS#7], CMC [RFC 2797], certificats X509v3 [RFC 3280],
CRL X509v2 [RFC 3280])
Lutilisation et la vrification des certificats, des signatures, des CRLs selon les
standards tels que RFC 2459 [RFC 2459] et 3280 [RFC 3280]. L'architecture prend en
compte la vrification en ligne telle quOCSP [RFC 2560], etc.
2.7.1.
Formats des certificats et validation
Comme mentionn ci-dessus, lIGC Windows respecte le format X.509 v3 pour les certificats
et les profils associs pour lutilisation de ces certificats, les listes de rvocations y compris les
CRL Delta [RFC 3280], ainsi que le support dOCSP ([RFC 2560]. Le support standard
(toutefois optionnel) des extensions CDP (cRLDistributionPoint) et AIA (id-peauthorityInfoAccess) facilite grandement la validation des certificats (rvocation et chaine de
certification) entre technologies de fournisseurs tiers.
Les services de certificat de Windows Server 2003 (R2) permet dmettre des certificats au
format standard pour une utilisation par des applications non Microsoft et/ou non Windows
respectueuses de ces standards.
Inversement, les applications Microsoft Windows (Outlook, Outlook Express, Outlook Web
Access pour S/MIME, SSL/TLS, IPsec, etc.) sappuient sur CryptoAPI et peuvent tre
dployes pour une utilisation de certificats mis par des AC non Windows.
Larchitecture ouverte de CryptoAPI permet la validation en ligne (OCSP) par le biais dun
module client de validation (Revocation Provider en anglais) disponible auprs de fournisseurs
tiers. Cette validation peut se faire contre un rpondeur OCSP non Microsoft/non Windows.
Les nouvelles versions de la plateforme Windows (Vista et Windows Server 2008) intgrent
une implmentation OCSP.
2.7.2.
Support des CRL et CRL diffrentielles
LIGC Windows est conforme la RFC 2459 [RFC2459] qui dfinit les rgles d'utilisation des
certificats et CRL : validation de la signature avec l'autorit au-dessus, priode de validit, non
rvocation, contraintes d'espace de noms, par rapport au sujet, politique, extensions critiques
reconnues, certificat est de type AC (contraintes lmentaires).
31
LIGC Windows supporte galement les delta CRL tels que spcifi dans la RFC 3280 [RFC
3280]. Une delta CRL permet de rafrachir la CRL de base avant son expiration, en spcifiant
une nouvelle base dans la delta CRL.
2.7.3.
Formats des requtes de certificats
Les Services de certificats de Windows Server 2003 supportent nativement les requtes de
certification (en abrg CSR pour Certificate Signing Request en anglais) au :
Format PKCS #10 [PKCS#10] ;
Standard CMC tel que dcrit dans la RFC 2797 [RFC 2797].
2.7.4.
Formats de mise disposition des certificats et des cls
Les formats suivants sont supports :
PKCS #7 [PKCS#7],
PKCS #12 [PKCS#12] (.p12 ou .pfx),
PEM (.pem),
DER (.der),
CER (.cer).
Le format PEM est obtenu a partir dune conversion par ligne de commande via la commande
certutil encode.
2.7.5.
Format PFX
Le standard PKCS #12 [PKCS#12] permet la sauvegarde et lchange dune bi-cl RSA et de
son certificat associe laide dun fichier protg par mot de passe.
2.7.6.
Algorithmes de chiffrement
LIGC Windows et, dune faon gnrale Windows Server 2003, sappuient sur CryptoAPI qui
comporte une architecture ouverte de gestion doprations cryptographiques base de CSP
pour les oprations cryptographiques en tant que telles.
La liste ci-dessous reprsente un ventail (non exhaustif) des algorithmes supportes en
standard sur la plateforme Windows :
RC2, RC4, DES, 3DES, AES128, AES192, AES256,
MD4, MD5, SHA-1,
HMAC (MD5, SHA-1),
RSA, DH, DSS.
32
2.7.7.
Longueur de cl
La longueur de cl est en partie dtermine par lalgorithme cryptographique slectionn. Les

longueurs de cls supports par une AC Windows Server 2003 (R2) varient entre 384 bits et
16,384 bits, selon le CSP choisi. Dans un dploiement classique, les certificats utilisateurs ont
des cls de 1,024 bits et ceux des AC racine ont 4,096 bit.
2.7.8.
Extensions supportes
Les extensions suivantes sont supportes :
KeyUsage,
Enhanced Key Usage,
BasicConstraints,
SubjectKeyIdentifier,
AuthorityKeyIdentifier,
CRLDistributionPoints,
CertificatePolicies,
SubjectAltName.
Les extensions suivantes relatives aux CRL sont supportes :
AuthorityKeyIdentifier,
CRLNumber.
33
3. Mise en uvre des services dIGC

3.1.
Performances
LAC disponible au sein de Windows Server 2003 (R2) au travers des services de certificat
t teste pour une capacit de stockage de plusieurs dizaines de millions de certificats mis
et pour une capacit dmission de plusieurs millions de certificats par jour (pour une longueur
de cl publique de 2048 bits).
3.2.
Dimensionnement et matriels
La solution dIGC Windows est implmente dans les environnements serveur Windows
Server 2003, objet de ce livre-blanc, et Windows Server 2008.
Pour ce qui est de Windows Server 2003, la version Windows Serveur 2003 Enterprise
Edition est requise. Il est par ailleurs recommand dutiliser des botiers HSM.
Les pr-requis dun serveur sont :
Matriel : Pentium 4 1,8 Ghz, 1 Go RAM, 40 Go DD disponible
Logiciel : Windows Server 2003 Enterprise Edition ou DataCenter Edition
Les pr-requis dun poste client sont :
34
Matriel : Pentium 4 1 Ghz, 512 Mo RAM
Logiciel : Windows XP / Vista, Windows 2000 dans une moindre mesure
Mise en uvre des services dIGC | Prsentation de lIGC Windows Server 2003
3.3.
Mthodologie
La dcomposition des diffrentes tches utiles sinon ncessaires limplmentation de lIGC

Windows au sein dune entreprise peut tre schmatise comme suit :
Mise en uvre dune
architecture
PKI Windows 2003
Phase 1 :
Vision & Primtre
Phase 2 :
Planification
Analyse de
lexistant
Spcification
fonctionnelles de la PKI
Analyse des
contraintes
et besoins
Architecture HSM
Scenarii
darchitecture
Rdaction du
dossier danalyse
Phase 3 :
Ralisation
Mise en uvre
du prototype
Architecture dtaille
Phase 4 :
Pilote
Prparation du pilote
Installation de
linfrastructure
Dfinition des rles
Procdures
dinstallation
Assistance Pilote
Dfinition du
prototype ILM
Procdures
dexploitation
Bilan Pilote
Rdaction du
dossier de conception
Phase 5 :
Dploiement
Prparation du
dploiement
Assistance
au dploiement
Bilan
du dploiement
Rdaction du dossier
darchitecture
Les sections suivantes dcrivent les diffrentes tapes de ce chantier.
3.3.1.
Phase 1 Vision et Primtre
Une bonne connaissance des environnements et processus existants est primordiale de faon
dtecter les synergies possibles, les contraintes en terme de dploiement, les axes
damlioration ventuels en ce qui concerne ladministration.
Certains des processus seront aussi analyss dans lobjectif de pouvoir proposer des solutions
techniques adaptes ou apportant une amlioration (gestion des changements, traitement des
demandes EE, processus de traitement des incidents, etc.).
Le but est de raliser, dans cette tape, une tude de larchitecture du systme
dinformation existant qui comprendra :
Organisation - Bien comprendre votre organisation

architectures les mieux appropries votre contexte ;
Administration et Exploitation - La description de lorganisation actuelle de

ladministration et de lexploitation permettra didentifier les points devant tre pris en
compte et adapts lors de la conception de larchitecture ;
Environnement Windows : il est important de comprendre comment sont utiliss les

systmes Windows existants ;
Environnement et quipements non-Windows : il est important de comprendre

comment sont utiliss ces systmes existants ;
aidera
envisager
Prsentation de lIGC Windows Server 2003| Mise en uvre des services dIGC
35
les
Environnement rseau - Il est ncessaire dobtenir des informations dtailles sur

votre environnement rseau (topologie des sites gographiques, infrastructure
physique, services rseaux, adressage rseau, etc.).
Dautres indicateurs seront ncessaires comme :
Les besoins scuritaires,
La disponibilit,
Le nombre dutilisateurs,
Le nombre de sites,
Lvolutivit
Etc.
Il est difficile, sans un travail pralable dtude, de dfinir compltement la solution. Celle-ci
devra tre tudie au niveau de chacun des sous projets ou lots. Il est, par contre,
envisageable et souhaitable de dfinir les grandes orientations dans une phase amont de
faon permettre lquipe dans son ensemble de partager une mme vision de la cible
atteindre. Il est possible que, sur certains axes, les lments ncessaires la dfinition dune
vision de solution ne soient pas encore disponibles. Dans ce cas, cette phase permettra quand
mme de dgager des pistes permettant dorienter les tudes ultrieures.
Cette phase consistera donc dfinir et partager une vision macroscopique de la solution
mettre en uvre pour adresser le primtre du projet. Elle permettra, en outre, de dfinir
prcisment le planning du projet.
Cette phase sera conduite sur la base de :
Analyse de documents et/ou danalyses qualitatives ou quantitatives existants

(spcifications actuelles),
Constitution de grille danalyse,
Runions du groupe de travail,
Analyses complmentaires ventuelles.
Livrable : un dossier danalyse constituera le livrable de cette tape et dcrira notamment :
Une synthse de lexistant,
Les besoins et les contraintes,
Une vision de larchitecture de lIGC (potentiellement plusieurs scnarii avec

avantages, inconvnients et prconisations),
La mise jour du plan projet.
Phase 2 Planification
3.3.2.
Ltape prcdente, a permise de dfinir les grandes lignes de larchitecture pressentie suivant
le contexte. Cette tape a donc pour objectif daffiner larchitecture gnrale IGC.
Il convient dtudier plus prcisment notamment :
Conception de la hirarchie dAC :
36
Dfinition des rles des AC dans la hirarchie de confiance,
Dfinition du nombre dAC et leur localisation,
Rgles de convention de noms,
Plan dintgration avec Active Directory.
Conception des configurations :
Scurisation du stockage des cls - type, nombre et localisation des HSM,
Dimensionnement des serveurs, RAID, bases de donnes/log, localisation,
Scurisation des serveurs lACR et les AC intermdiaires doivent tre scuriss

et non utiliss,
Renforcement de la scurit des AC mettrices.
Conception des rgles dadministration et de dlgation :
Identification des rles et des besoins de sparation des rles pour ladministration
des AC (sauvegarde/restauration, audit, etc.),
Identification des utilisateurs (ou groupe) et assignation dans les rles identifis,
Dfinition des rgles de gestion pour chacun des rles.
Cration dune politique gnrique denrlement et de renouvellement des certificats
Cration dune politique gnrique des gabarits de certificat
Conception dune stratgie de groupe (GPO) gnrique pour le dploiement des

certificats
Conception de la politique gnrique de rvocation des certificats
Dfinition de la procdure de rvocation (quand, pour quelles raisons, sur quels

vnements, etc.)
Choix dune localisation de la CRL et des mthodes daccs (HTTP, LDAP),
Choix du type de CRL (base, delta), de la frquence de mise jour et des

priodes de validit.
Conception de la politique de recouvrement de cl
Conception du prototype de validation
Cette phase sera conduite sur la base de runions du groupe de travail.

Livrable : Le livrable de cette tape est constitu du document darchitecture gnrale de
linfrastructure IGC.
3.3.3.
Phase 3 Ralisation
Cette tape a pour objectif de construire et tester linfrastructure propose. Les choix
techniques sont valids et affins en ralisant des prototypes.
Cette tape met donc en uvre des :
Prototypes de validation technique afin de tester les paramtrages, configurations,

organisations, etc.
Ces prototypes identifis pralablement sont ncessaires ce stade pour affiner les
diffrents paramtres des composantes du systme cible. Ils peuvent galement
37
mettre en vidence des problmes particuliers dintgration. En effet, ltude des

environnements gnraux, serveur, poste de travail et priphrique, conduit la mise
en place de sous-projets pour lesquels il convient de conserver une vue globale vis-vis de linfrastructure gnrale cible.
Prototypes oprationnels
Le but dun prototype oprationnel est de disposer dun ensemble cohrent de
fonctionnalits du systme cible dans le cadre dexploitation prvu afin dobtenir des
ractions et corriger les ventuels problmes.
Les prototypes permettent de recetter la plate-forme technique et la future architecture avant la

gnralisation de la solution et la dfinition des modalits dindustrialisation.
Ces prototypes oprationnels ncessitent la constitution dune plate-forme dintgration qui
sera utilise tout au long des tapes restantes (autres lots) du projet.
Cest galement au cours de cette phase que sont ralises, testes et documentes les
procdures dadministration, dinstallation et notamment :
Les procdures de sauvegarde et de restauration (AC, cls dAC, CRL, etc.),
Les procdures de supervision,
Les procdures dinstallation,
Le guide dopration.
Livrable : Le livrable de cette tape est constitu du document darchitecture dtaille

intgrant les procdures dadministration et dexploitation de larchitecture ainsi dfinie.
3.3.4.
Phase 4 Pilote
Cette phase se poursuit par une exprimentation pilote qui permet une validation finale avant
la gnralisation du dploiement. Lexprimentation pilote est ralise en conditions relles sur
un sous-ensemble reprsentatif de la communaut des utilisateurs.
Il est ncessaire de dterminer quel sous-ensemble fera lobjet de lexprimentation pilote
sachant quil doit tre :
Reprsentatif de lenvironnement de lentreprise,
Motiv pour lexprimentation.
Lexprience Pilote permet de sassurer, dans des conditions relles, que larchitecture
technique dfinie et teste dans le prototype est rellement oprationnelle et prte tre
dploye et ce, en illustrant le bon fonctionnement de lensemble des composants constituant
lenvironnement cible du projet.
La mise en uvre de la solution ncessite des installations utilisant les procdures
dinstallation finales.
Cette exprience pilote implique donc une logistique :
Acquisition et livraison du matriel,
Locaux rservs linstallation,
Acheminement du serveur vers le site final,
Installation physique,
Coordination avec la logistique rseau,
38
3.3.5.
Procdures de secours.
Phase 5 Dploiement
Il sagit de la phase de gnralisation du dploiement lensemble du parc. En effet, le site

pilote permet de valider la solution en condition relle. Il reste donc gnraliser cette solution
pour tous les sites et ce conformment aux tapes de transitions qui ont t dfinies. Les
transitions doivent tre les plus douces possibles.
Pour ce faire, un plan de gnralisation ou de dploiement est mis au point pralablement au
dploiement final.
3.4.
Cots
Les services de certificats de Windows Server 2003 (R2) constituent lun des services Serveur
de la plateforme Windows Server 2003 (R2).
Il ny a pas de facturation spcifique aux fonctions ncessaires pour tablir une infrastructure
de confiance avec lIGC Windows.
Ces fonctions sont disponibles dans Windows Server 2003, et leur droit dutilisation inclus
dans le cot des licences associes.
3.5.
Support
Le niveau de support est le mme que pour la plateforme Windows et suppose un contrat de
support obtenu auprs de Microsoft ou de ses partenaires agrs.
Le niveau de disponibilit varie selon le type de contrat de support souscrit auprs de
Microsoft ou de ses partenaires agrs.
La gamme des services de support disponibles auprs de Microsoft est dcrite
ladresse Internet http://support.microsoft.com/default.aspx?scid=fh;FR;Offerings&ln=fr.
Au sein de cette gamme, Microsoft Support Premier est un contrat de support adaptable,
pouvant tre personnalis aux besoins et objectifs de lorganisation.
Les services principaux se composent des 2 lments suivants :
1. Gestion technique du compte avec des services techniques personnaliss et
proactifs ;
2. Accs hautement ractif aux experts techniques du support Microsoft, 24 heures sur
24, 7 jours sur 7.
Le support Premier est dcrit ladresse Internet
http://support.microsoft.com/gp/premsup.
39
4. Conclusion
A lheure ou les systmes dinformations souvrent de plus en plus vers lextrieur et que les
changes saccentuent la scurit est devenue une ncessit pour sassurer contre
lusurpation didentit, les accs non autoriss, le vol ou la perte dinformation, etc.
Dans la diversit des solutions de scurit proposes lIGC embarque dans Windows
Serveur 2003 possde de nombreux atouts pour devenir LA plateforme de rfrence :
Base sur des standards
Incluant des fonctions de scurits compltes :
Authentification,
Chiffrement,
Signature.
Exploite par de nombreux services et applications
Systmes dexploitation,
Messagerie,
Applications bureautiques,
Protocoles rseaux,
Etc.
Les services de certificat de Windows Server 2003 (R2) apportent tous les services dune
plateforme de confiance complte et est mme de dlivrer des moyens daccs scuriss
par certificat numrique, y compris les supports cryptographiques pour de lauthentification
forte et le transport des secrets.
Reposant sur une architecture volutive et ouverte vers lextrieur, ce service possde
lavantage dtre inclus comme un service de la plateforme Windows Server ce qui porte son
cot au seul cot dacquisition de la plateforme Windows.
Lintgration avec Active Directory et Windows ainsi que lutilisation de gabarit de certificat
apporte des capacits de dploiement, de gestion et dautomatisation sans communes
mesures avec les autres offres du march.
Enfin, cette solution dveloppe, amliore, maintenue et intgre au systme dexploitation
depuis Windows NT 4.0 par Microsoft est un gage de prennit pour une entreprise devant
sengager dans une IGC pendant des annes.
40
Conclusion | Prsentation de lIGC Windows Server 2003
Annexe A. Rfrences
Standards issus du projet PKIX de lIETF
Le groupe de travail Public Key Infrastructure X.509 (en abrg PKIX), form en 1995 par
lInternet Engineering Task Force (en abrg IETF), visait la dfinition dun ensemble de
profils de certificats et de modles oprationnelles qui conviendraient sur Internet.
Ce groupe est lorigine de trs nombreuses RFC aujourdhui implmentes dans les
solutions dIGC. La liste complte est disponible sur la page daccueil du groupe ladresse
Internet http://www.ietf.org/html.charters/pkix-charter.html.
RFC 2527 Internet X.509 Public Key Infrastructure Certificate Policy and Certification
Practices Framework , http://tools.ietf.org/html/rfc2527
RFC 2459 Internet X.509 Public Key Infrastructure Certificate and CRL Profile ,
http://tools.ietf.org/html/rfc2459
RFC 2560 X.509 Internet Public Key Infrastructure Online Certificate Status Protocol OCSP , http://tools.ietf.org/html/rfc2560
RFC 2585 Internet X.509 Public Key Infrastructure Operational Protocols: FTP and HTTP ,
RFC 2587 Internet X.509 Public Key Infrastructure LDAPv2 Schema,
RFC 2797 Certificate Management Messages over CMS , http://tools.ietf.org/html/rfc2797
RFC 3279 Algorithms and Identifiers for the Internet X.509 Public Key Infrastructure
Certificate and Certificate Revocation List (CRL) Profile , http://tools.ietf.org/html/rfc3279
RFC 3280 Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List
(CRL) Profile , http://tools.ietf.org/html/rfc3280
RFC 3647 Internet X.509 Public Key Infrastructure Certificate Policy and Certification
Practices Framework , http://tools.ietf.org/html/rfc3647
RFC 3852 Cryptographic Message Syntax (CMS) , http://tools.ietf.org/html/rfc3852
Autres standards
RFC 4556 Public Key Cryptography for Initial Authentication in Kerberos (PKINIT) ,
RFC 4557 Online Certificate Status Protocol (OCSP) Support for Public Key Cryptography
for Initial Authentication in Kerberos (PKINIT) , http://tools.ietf.org/html/rfc4557
PKCS #1 RSA Cryptography Standard , http://www.rsa.com/rsalabs/node.asp?id=2125
PKCS #3 Diffie-Hellman Key Agreement Standard ,
http://www.rsa.com/rsalabs/node.asp?id=2126
PKCS #7 Cryptographic Message Syntax Standard ,
Prsentation de lIGC Windows Server 2003 | Annexes
41
PKCS #8 Private-Key Information Syntax Standard ,

PKCS #10 Certification Request Syntax Standard ,
PKCS #12 Personal Information Exchange Syntax Standard ,
PC/SC v1.0, http://www.pcscworkgroup.com/specifications/specdownloadV1.php
SCEP, draft Internet IETF Cisco Systems' Simple Certificate Enrollment Protocol (SCEP) ,
http://www.ietf.org/internet-drafts/draft-nourse-scep-15.txt
USB-CCID, http://www.usb.org/developers/devclass_docs
Ressources Windows Server 2003

Les ressources relatives aux services de certificat de Windows Server 2003 (R2) sont
regroupes ladresse Internet suivante :
http://www.microsoft.com/Windowsserver2003/technologies/pki/default.mspx
BEST PRACTICES FOR IMPLEMENTING A MICROSOFT W INDOWS SERVER 2003 PUBLIC KEY
INFRASTRUCTURE ,
http://www.microsoft.com/technet/prodtechnol/windowsserver2003/technologies/security/ws3p
kibp.mspx
DESIGNING A PUBLIC KEY INFRASTRUCTURE (W INDOWS SERVER 2003) ,
http://go.microsoft.com/fwlink/?LinkID=84709
PLANNING AND IMPLEMENTING CROSS-CERTIFICATION AND QUALIFIED SUBORDINATION USING
W INDOWS SERVER 2003 ,
http://www.microsoft.com/technet/prodtechnol/windowsserver2003/technologies/security/ws03
qswp.mspx
ADVANCED CERTIFICATE ENROLLMENT AND MANAGEMENT ,
http://www.microsoft.com/technet/prodtechnol/windowsserver2003/technologies/security/advce
rt.mspx
CERTIFICATE AUTOENROLLMENT IN W INDOWS SERVER 2003 ,
http://www.microsoft.com/technet/prodtechnol/windowsserver2003/technologies/security/autoe
nro.mspx
IMPLEMENTING AND ADMINISTERING CERTIFICATE TEMPLATES IN W INDOWS SERVER 2003 ,
http://www.microsoft.com/technet/prodtechnol/windowsserver2003/technologies/security/ws03
crtm.mspx
KEY ARCHIVAL AND MANAGEMENT IN W INDOWS SERVER 2003 ,
http://www.microsoft.com/technet/prodtechnol/windowsserver2003/technologies/security/kyac
ws03.mspx
W INDOWS SERVER 2003 PKI OPERATIONS GUIDE ,
http://technet2.microsoft.com/WindowsServer/en/Library/e1d5a892-10e1-417c-be1399d7147989a91033.mspx
42
Annexes | Prsentation de lIGC Windows Server 2003
Ressources Windows Vista

W INDOWS VISTA SMART CARD INFRASTRUCTURE ,
http://www.microsoft.com/downloads/details.aspx?FamilyID=ac201438-3317-44d3-963807625fe397b9&displaylang=en
TROUBLESHOOTING PKI PROBLEMS ON W INDOWS VISTA ,
http://go.microsoft.com/fwlink/?LinkId=85484
Prsentation de lIGC Windows Server 2003 | Annexes
43
Annexe B. Pour des informations complmentaires

Pour des informations gnrales sur les services de certificats de Windows Server 2003 (R2),
vous pouvez consulter ladresse Internet http://www.microsoft.com/pki
Pour des informations gnrales sur la solution Microsoft ILM 2007, vous pouvez consulter
ladresse Internet http://www.microsoft.com/ilm
Pour les dernires informations sur Windows Server System, vous pouvez consulter le site
ddi Windows Server System ladresse Internet
http://www.microsoft.com/windowsserversystem.
44
Annexes | Prsentation de lIGC Windows Server 2003

Presentation de L IGC Windows Serveur 2003

Transféré par

Informations du document

Description :

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Description :

Droits d'auteur :

Formats disponibles

Presentation de L IGC Windows Serveur 2003

Titre original :

Transféré par

Description :

Droits d'auteur :

Formats disponibles

Prsentation de lIGC Windows Server

Auteur : Stphane Metenier, Philippe Beraud

2008 Microsoft Corporation. Tous droits rservs.

Introduction | Prsentation de lIGC Windows Server 2003

MISE EN UVRE DES SERVICES DIGC

DESCRIPTION DES SERVICES DIGC

POUR DES INFORMATIONS COMPLEMENTAIRES

Prsentation de lIGC Windows Server 2003| Introduction

Usages dune IGC

Introduction | Prsentation de lIGC Windows Server 2003

Pendant longtemps, le systme cryptographique le plus utilis a t le chiffrement symtrique

Le chiffrement asymtrique ou cl publique sappuie sur cls relies entre elles

Le sens aller est utilis pour le chiffrement et la vrification de la signature ;

Le sens inverse est utilis pour le dchiffrement et la gnration de la signature ;

Les changes de donnes sappuient aujourdhui sur des schmas de ngociation de cl

Prsentation de lIGC Windows Server 2003| Introduction

Introduction | Prsentation de lIGC Windows Server 2003

Requte signe par lAC

1. Soumission dune demande de certificat lAC

Ou, en ayant recours, par exemple, au travers de CryptoAPI, linterface

Introduction | Prsentation de lIGC Windows Server 2003

Composantes dune IGC

Les composantes dune IGC sont les suivantes :

Autorit dEnregistrement (AE)

Prsentation de lIGC Windows Server 2003| Introduction

Introduction | Prsentation de lIGC Windows Server 2003

2. Description des services dIGC

Le systme de gestion du cycle de vie des identits, des certificats et supports

Le systme de Web SSO, Web SSO extranet et de fdration didentit Active

Prsentation de lIGC Windows Server 2003| Description des services dIGC

Un annuaire pour les identits numriques,

Une solution de gestion des supports cryptographiques,

Ainsi que des services rseaux classique DNS, SMTP, etc.

LIGC Windows propose une intgration possible avec Active Directory

La scurit de la solution en authentifiant les demandes,

Les cots de mise en uvre et dexploitation au quotidien en utilisant les stratgies de

La disponibilit de la solution via les fonctionnalits de rplication propres Active

Description des services dIGC | Prsentation de lIGC Windows Server 2003

Authentification des demandes,

Dlgation dadministration au sein de lautorit,

Dploiement/renouvellement automatiss des certificats via les stratgies de groupe,

Stockage des gabarits de certificats dans Active Directory,

Renseignement optionnel des informations didentit au sein des certificats lors de la

Publication optionnelle des certificats dans Active Directory.

Autorit unique sans intgration Active Directory (mode autonome) - Cette

Autorit unique avec intgration Active Directory (mode entreprise) - Cette

Autorits multiples avec intgration Active Directory (mode entreprise) - Cette

Elle permet un regroupement gographique des autorits, permettant une

d. Et enfin, cette architecture est prouve.

Prsentation de lIGC Windows Server 2003| Description des services dIGC

Cette architecture est compose :

Dune autorit de certification racine (hors ligne) en mode autonome (pas de

Pour chaque fort Active Directory :

Description des services dIGC | Prsentation de lIGC Windows Server 2003

Gestion des CRL et CRL diffrentielles

Prsentation de lIGC Windows Server 2003| Description des services dIGC

Support des stratgies de groupe

Systme de terminaison de scurit IP (IPsec),

Description des services dIGC | Prsentation de lIGC Windows Server 2003