Supervision d’une autorité de certification

I. Présentation

Ce chapitre évoque la supervision (ou monitoring) d'une autorité de certification sous Windows Server, basée sur AD CS.

Une fois déployé, le service d'autorité de certification devient un service critique pour lequel une supervision est nécessaire. Par exemple, si la liste de révocation n'est plus mise à jour (et donc expirée) ou qu'elle n'est pas joignable, les certificats émis par cette autorité peuvent être considérés invalides.

II. Les composants

A. Services

L'état des services est une première brique à regarder. Dans notre architecture d'exemple, il nous faudra superviser le service d'autorité, les composants IIS et le service OCSP, soit la liste suivante de services au niveau de Windows Server :

• CertSvc
• W3SVC
• OcspSvc

B. Activités

La fonctionnalité d'audit intégrée au service AD CS permet d'enregistrer les activités d'exploitation de l'autorité. Depuis la console "Autorité de certification", en accédant aux "Propriétés" de l'autorité, vous verrez un onglet "Audit". Je vous recommande d'activer à minima les événements illustrés dans la capture.

Attention, pour que cela fonctionne, il faut activer l'audit au niveau système (voir la rubrique suivante).

C. Événements

Pour permettre l'enregistrement des événements, il convient d'activer l'audit au niveau système.

Pour une autorité de type autonome, on passera par une stratégie locale, et par une commande :

auditpol /set /subcategory:"Certification Services" /success:enable /failure:enable

Pour des autorités de type Enterprise, on privilégiera une stratégie de groupe pour activer le paramétrage mis en évidence sur l’image ci-dessous. Il implique la configuration d’une stratégie d’audit.

Par exemple, si j’ajoute une URL dans l’extension AIA de l’autorité, je modifie sa configuration et un événement est ajouté dans le journal Sécurité :

Si on veut aller plus loin, il nous faut également vérifier les changements apportés via les entrées de registres. En effet, toute modification de paramétrages ne passe pas obligatoirement par la console de gestion de l'autorité.

Pour une autorité de type autonome, on passera par une stratégie locale, et par une commande :

auditpol /set /subcategory:"Registry" /success:enable /failure:enable

Pour des autorités de type Enterprise, on reprend la méthode stratégie de groupe pour ajouter :

Pour les deux types d'autorité, il nous faut ajouter directement depuis regedit, l'audit sur les entrées de registres AD CS sous :

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\CertSvc\Configuration

Accédez au menu "Autorisations" par un clic-droit :

1. Accédez au menu "Avancé"
2. Sélectionnez l'onglet "Audit"
3. Cliquez sur le bouton "Ajouter"
4. Sélectionnez "Utilisateurs authentifiés"
5. Comme type, ciblez "Tout"
6. Ajouter les autorisations avancées telles qu'illustrées.

Enfin, pour aller encore plus loin, on peut auditer les changements sur les modèles de certificats : ajout de modèles, modifications de paramétrages et changement des permissions. Considérant que l'audit système est déjà activé, puisque nous l'avons fait précédemment, il suffit d'exécuter cette commande sur l'autorité :

certutil -setreg policy\EditFlags +EDITF_AUDITCERTTEMPLATELOAD

III. Solutions de supervision pour AD CS

A. Outils du marché

Il s'agit ici de vérifier l'état de santé des services AD CS qui composent la plateforme de PKI. À cet effet, vous pouvez utiliser un outil de supervision du marché (Nagios, PRTG, Zabbix, etc…), qui vérifiera l'état des services Windows, les événements des journaux d'événements, l'expiration des certificats.

Il sera également possible d'intégrer des sondes de type check_http pour s'assurer que le service OCSP répond ou encore que le téléchargement du fichier de CRL est possible.

B. PKIview

Pour obtenir en un coup d'œil l'état de santé de toute l'infrastructure d'autorités de certification, je vous recommande d'utiliser la console MMC qui fait partie des outils d'administration AD CS, à savoir :

pkiview.msc

De là, vous pourrez observer :

• La validité des certificats d'autorité
• La disponibilité du service OCSP
• La bonne publication des CRLs

Prenons l'exemple de notre plateforme PKI. La vue est la suivante :

On observe que pour les deux autorités intermédiaires, le statut est OK partout. Cela signifie qu'à la fois le certificat d'autorité, le point de distribution des infos sur l'autorité (AIA) et les emplacements de vérification de révocation (CDP et OCSP) sont accessibles.

En revanche, si on s'intéresse à l'autorité racine, on voit qu'un point AIA est en erreur (un peu fait exprès). En effet, le fichier de certificat n'est pas accessible puisqu'on référence le serveur d'autorité racine qui est en Workgroup. De plus, l'autorité étant éteinte, c'est sur notre serveur S-SERVICESCA que le fichier doit être présent.

Il s'agit du paragraphe AIA du module 3 qui traite de la configuration de l'autorité racine, que je n'ai pas appliqué volontairement. Si je suis à présent la procédure, il ne me reste plus qu'à renouveler les certificats d'autorité pour que tout rentre dans l'ordre.

L'emplacement AIA est à présent correct, la vue PKIView est en statut OK partout. Notez que le numéro de version stipulé à droite du nom de l'autorité a changé également, puisqu'un renouvellement de certificat a eu lieu.

Astuce en passant, si la date d'expiration de la liste de révocation est proche, le statut passera en avertissement. Selon l'échéance que vous avez fixée, il peut être préférable de modifier les options de la console pour éviter un avertissement alors que la date est lointaine.

De plus, avec cette console PKIView, il vous sera possible de gérer l'inscription des objets dans l'Active Directory. Il faut pour cela réaliser un clic-droit à la racine de la console et choisir "Gérer les conteneurs Active Directory".

Vous verrez apparaître ici toutes les informations que l'on retrouve également dans la console « Sites et Services Active Directory » sous « Services\Public Key Services ». Si une ancienne liste de révocation est présente, il est très simple de la supprimer. Je m'aperçois souvent au travers de cet écran que d'anciennes autorités sont toujours présentes dans l'AD, car mal décommissionnées.

IV. Conclusion

Maintenant que tout est en place côté supervision, regardons un autre aspect important : la sauvegarde de l'autorité de certification.