Maintenant que nous en avons fini avec notre autorité de certification racine, attaquons nous à quelque chose de plus consistant, à savoir :
- Notre autorité de certification autonome, subordonnée à RootCA
- Le rôle NPS
- Le Health Registration Authority
Setup First
Les éléments précédemment cités étant des rôles, il faudra bien les installer sur le serveur nps.corp.windows2008R2.com. Commençons donc. Sur le serveur on va installer tous les rôles cités :
Le fait de cocher la case d’option “Health Registration Authority” va automatiquement nous indiquer qu’il sera nécessaire d’installer un serveur web. Ceci est rendu nécessaire car le HRA est uniquement accessible par les clients sous forme d’URL.
Notre HRA doit impérativement être associée à une autorité de certification. Cependant, à ce stade de l’installation, elle n’est même pas encore installée. Il nous fout donc indiquer une configuration ultérieure :
Le HRA est capable de traiter les demandes authentifiées en provenance des machines du domaine. Il est aussi capable de traiter les demandes en provenance des systèmes non raccordés au domaine. Les demandes de certificats sont donc anonymes. Ce mode de fonctionnement est très pratique pour les postes en cours de déploiement, qui ne sont pas encore raccordé au domaine :
Les URL utilisées par les clients peuvent être sécurisées en utilisant le protocole HTTPS. Ceci implique des certificats. Cependant, nous sommes en phase d’installation des rôles. Pour la configuration, on repassera plus tard :
Ici encore, l’installation de l’autorité de certification sera complétée par le site web de demande de certificats. L’intérêt est de pouvoir soumettre les demandes sans passer par la console d’administration:
Notre autorité de certification secondaire sera de type autonome, ce qui implique que celle-ci n’utilisera pas Active Directory. Par conséquence, il ne sera pas possible de réaliser des demande de certificats automatiques, encore moins des renouvellement. Cela ne nous posera pas de problème puis que le HRA pilotera tout cela :
Notre autorité autonome sera de type secondaire, c’est à dire subordonnée à l’autorité de certification principale ROOTCA.
Ici encore, le seul choix possible, c’est de créer une nouvelle clé privée.
Tous les choix proposés par défaut sont conservés. Dans une implémentation réelle, on aurait réduit la taille de la clé :
Notre nouvelle autorité de certification sera nommée NAPCA, indiquant ainsi qu’elle sera dédiée à cette fonction. Dans le cadre de NAP IPSEC, c’est une bonne pratique vu le volume de certificats qui seront générés. Les listes de révocations vont être volumineuses!
Le choix fainéant aurait été de réaliser la demande en ligne profitant ainsi de l’enregistrement automatique des demandes de certificats et de la délivrance (puisque l’utilisateur Administrateur que je suis a le droit de demander ce type de certificat). Et bien non, on va illustrer cela à l’ancienne :
Pas la peine d’isoler des fichiers en relation avec la base de données, il n’y a pas de séparation des rôles (c’est mal, …).
L’installation du serveur Web comprend déjà toutes les options nécessaires, pas la peine d’en rajouter :
On arrive à la fin ou presque. Plus qu’une confirmation.
Le processus d’installation nous indique que l’installation est techniquement terminée mais pour que l’autorité de certification et le HRA soient opérationnel, il reste du travail :
Demander le certificat de l’autorité de certification autonome
Comme j’ai pas voulu être fainéant et stocker la demande de certificat dans un fichier texte, il ne me reste plus qu’à la soumettre à l’autorité de certification RootCA au travers du site web d’enregistrement accessible via l’URL : (pas de HTTPS mais quelle honte. Oui mais toujours en laboratoire, na!). On va donc effectuer une demande de certificat :
Une authentification sera nécessaire. A ce stade, seul l’administrateur du domaine peut demander un certificat pour une autorité de certification secondaire (toujours pas de séparation des rôles, tsss!). Ce ne sera pas une demande pour un certificat utilisateur mais une demande avancée :
La demande existant déjà sous forme de fichier requête, on va donc soumettre son contenu à l’autorité de certification :
Le contenu du fichier de requête (à l’exclusion des marqueurs de début et fin) doit être copié dans la zone de texte prévue à cet effet. Reste plus qu’à sélectionner le gabarit : Subordinate Certification Authority :
Oh, miracle! Mon utilisateur est autorisé à soumettre un tel type de demande et à les valider automatiquement. Reste plus qu’à télécharger le certificat :
Oui, on télécharge le certificat car il doit être placé dans un magasin spécifique pour être utilisable par l’autorité de certification. En plus, cela permettra de pouvoir le stocker, de préférence dans un endroit sûr.
Installer le certificat de l’autorité de certification
Il ne reste plus qu’à installer le certificat en demandant son installation par la console d’administration de l’autorité de certification (Il aurait été possible de réaliser l’opération avec quelques commandes CERTUTIL.EXE mais bon, …).
Le certificat installé, si tout est opérationnel, alors il doit être possible de démarrer cette nouvelle autorité de certification :
Et effectivement elle fonctionne.
Configuration de la politique de la CA autonome
Reste maintenant à la configurer. En premier lieu pour délivrer automatiquement les certificats dès lors que les demandes sont émises par un demandeur autorisé (qui sera le HRA).
C’est un paramétrage qui implique un arrêt.
Puis un redémarrage le la CA pour être pris en compte.
Pour que le HRA soit autorisé, encore faut-il qu’il dispose des permissions suffisantes. Dans notre cas, le HRA est installé sur le même serveur que l’autorité de certification autonome (c’est moche mais on est en laboratoire, pas en production!). On peut donc se contenter de positionner les permissions pour le contexte “Network Service”. Sinon, c’est le compte ordinateur qu’il faut spécifier :
Configuration du Health Registration Authority
La configuration du HRA n’était pas complète. En effet il manquait encore auprès de quelle autorité de certification soumettre les demandes :
Ainsi que de s’assurer que c’est bien une autorité autonome. Avec Windows Server 2008 R2, on pourrait utiliser une autorité d’entreprise, ce qui permettrait de différencier les certificats pour les demandes authentifiées des celles qui sont anonymes. Ce choix aurait permit d’éviter d’installer une autorité de certification supplémentaire mais j’ai décidé de continuer à dédier mon autorité de certification à ce rôle précis pour raison de volumétrie de la liste de révocation (en plus, je reste compatible avec Windows Server 2008). On remarquera que les certificats générés seront valables seulement quatre heures :
Et pour finir avec la PKI, une petite subtilité registre avec la clé de registre indiquant la périodicité selon laquelle les certificats inutiles seront supprimés de la base de données. La valeur par défaut est de cinq minutes :
Voila pour l’installation de notre serveur NPS. Ce fut long mais on en a fini avec l’installation. Le prochain billet sera dédié à la mise en œuvre de NAP. Après, on pourra s’attacher à la mise en œuvre des mécanismes d’isolation IPSEC (on va s’éclater, promis!).
Benoîts- Simple and Secure by Design