PKI à 2 niveaux dans Win srv 2008 R2

Source (Maj 15 juin 2010 ): http://mtodorovic.developpez.com/tutoriels/windows/configuration-infrastructure-cles-publiques-sous-windows-2008/

PKI = Public Key Infrastructure. Comment mettre en place l'autorité de certification disponible dans Windows Server 2008 R2 Standard.

Si 2 niveaux, on a besoin de 2 serveurs de certification: un à la racine (qui va s'autocertifier, indépendant du domaine) et le second (approuvé par la racine, intégré au domaine) va délivrer les certificats au réseau.
L'autorité racine est complètement indépendante du réseau et du domaine Active Directory. Cette autorité doit être éteinte et placée en sécurité pour éviter tout vol de sa clé privée. Si cette autorité est compromise alors toutes les autorités inférieures ainsi que tous les certificats peuvent être compromis. Il faudra alors tout révoquer pour régénérer de nouveaux certificats.

Bien qu'il soit possible d'installer l'autorité sur un DC, ce n'est pas conseillé. Nous aurons donc trois serveurs : une autorité racine totalement indépendante et éteinte, un contrôleur de domaine et une autorité de délivrance intégrée au domaine AD.

Le niveau fonctionnel du domaine n'a pas d'influence sur le fonctionnement de la PKI.
Un srv web hebergera les certificats.

Autorité autonome ou entreprise ?

On ne peux pas en changer par la suite, à moins de supprimer et réinstaller (attention aux clefs).

autonome (standalone) enterprise
Scénarios d'utilisation d'une autorité
  • Utilisable pour une autorité éteinte racine ou intermédiaire
  • Pas besoin de personnaliser les modèles de certificats
  • Besoin d'une forte sécurité et politique d'approbation
  • Peu de certificats à approuver et le travail requis pour l'approbation est acceptable
  • Clients hétérogènes et ne pouvant pas bénéficier d'un accès à AD
  • Certification à travers le protocole SCEP pour les routeurs
  • Un grand nombre de certificats devra être approuvé automatiquement
  • La disponibilité et la redondance sont requises
  • Les clients utilisent Active Directory
  • L'approbation automatique doit être modifiée
  • Les modèles de certificats doivent être modifiés, dupliqués ou créés
  • L'archivage et la restauration des clés dans un dépôt spécifique

Reco de MS quant au type d'autorité à utiliser selon le type de l'autorité (racine, intermédiaire, délivrance) ?!?

DNS

Nommage des srv

rootca est indépendant, ne devrait pas etre connecté sur le réseau. On utilise un média pour transférer les données.

  • Contrôleur de domaine : domain-controller.developpez.adds
  • Autorité de certification : ca.developpez.adds
  • Serveur web : services.developpez.com

Nom de domaine privé/public ?

developpez.adds est le nom de domaine AD et n'est donc pas accessible sur Internet. developpez.com est un nom de domaine public donc accessible sur Internet.

Une PKI peut être utile pour proposer des services sécurisés à des clients qui connaissent votre société. Il suffira que les clients téléchargent le certificat racine pour faire confiance à vos services sécurisés. Cela va s'avérer utile pour des solutions de portails client (basés sur Sharepoint par exemple) ou pour faire des téléconférences grâce à Office Communication Server. Il est donc conseillé de placer les certificats et les listes de révocation de votre autorité racine et de distribution sur un serveur accessible portant un nom public.

Notre serveur web (qui met à disposition les certificats des autorités et les listes de révocation) devra être accessible depuis votre réseau interne comme depuis Internet. Afin d'éviter à vos postes internes d'aller sur Internet pour aller chercher un certificat racine ou la liste de révocation, nous utiliserons un "split-DNS".
Dans notre cas, nous allons utiliser deux serveurs DNS pour la zone developpez.com (l'un pour LAN l'autre pour internet).

Votre DNS de l'AD contiendra la zone publique developpez.com et contiendra des enregistrements pointant vers vos serveurs internes (avec des IP privées). Il n'est pas accessible del'exterieur. Les clients AD vont récupérer IP privées.
Nous allons créer les mêmes enregistrements dans la zone privée et la zone publique. Ces derniers porteront les mêmes noms mais pas les mêmes valeurs. La zone hébergée par AD contiendra des enregistrements à IP privée ; la zone publique (qu'elle soit gérée par vous ou votre fournisseur de domaine) contiendra les IP publiques de vos serveurs publiés.

Architecture suggérée

Ici, pas de reverse-proxy (mais le fonctionnement reste identique).
Si votre entreprise a choisi d'héberger elle-même le DNS public gérant votre domaine, il se trouvera en DMZ.

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

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