Récemment, alors qu'il travaillait sur un déploiement de Microsoft Network Device Enrollment Services (NDES), un client a posé une question assez simple sur l'empreinte du certificat de l'autorité de certification (CA) affichée dans l'interface graphique d'inscription de l'administrateur NDES : "Qu'est-ce que ce hachage ? Et pourquoi ne correspond-il à aucun des hashs de l'empreinte du certificat de l'autorité de certification dans ma chaîne d'autorité ?"
Dans le cadre d'une vaste étape de dépannage pour un appareil qui ne s'enrôlait pas correctement, le client vérifiait la configuration du serveur NDES et s'inquiétait du fait que l'empreinte ne correspondait pas aux empreintes affichées des certificats d'autorité de certification de sa chaîne.
Vue d'ensemble de la NDES
Le NDES (Network Device Enrollment Service) est l'implémentation par Microsoft du SCEP (Simple Certificate Enrollment Protocol), un protocole de communication qui permet à software , qui fonctionne sur des périphériques de réseau tels que des routeurs et des commutateurs, et qui ne peut pas être authentifié autrement sur le réseau, de s'inscrire pour obtenir des certificats X.509 auprès d'une autorité de certification (CA).
NDES fonctionne comme un filtre ISAPI (Internet Server Application Programming Interface) sur Internet Information Services (IIS) qui génère et fournit des mots de passe d'inscription à usage unique aux administrateurs, reçoit et traite les demandes d'inscription SCEP pour le compte de software fonctionnant sur des périphériques de réseau, et récupère les demandes en attente auprès de l'autorité de certification. https://technet.microsoft.com/en-us/library/cc753784(v=ws.10).aspx
Qu'est-ce que c'est que ce hachage ?
Après quelques vérifications, notamment un contrôle rapide des clés de registre dans HKLM\SOFTWARE\Microsoft\Cryptography\MSCEP, nous avons déterminé que le serveur NDES était configuré correctement et qu'il pointait vers la bonne autorité de certification.
J'ai donc fait appel à notre expert en cryptographie (Ted Shorter, directeur technique de CSS) et nous avons commencé par examiner le certificat public de l'autorité de certification vers laquelle pointait le serveur NDES. Nous avons constaté que son hachage ne correspondait pas à ce que nous voyions sur la page d'administration du NDES.
Une autre chose est apparue immédiatement : le hachage du certificat que nous pouvions voir à travers l'interface graphique par défaut de Microsoft était de 20 octets (SHA-1), et le hachage sur la page d'administration des DNES n'était que de 16 octets. Le hachage de la page d'administration des DNES pourrait-il être le hachage MD5 du certificat d'émission ?
Le vérificateur d'intégrité des sommes de contrôle de Microsoft (FCIV)
Nous aurions pu coller un code rapide pour vérifier les différentes valeurs de l'algorithme de hachage du certificat de l'autorité de certification émettrice, mais il existe un outil astucieux de Microsoft qui nous permet de vérifier rapidement un hachage MD5 ou SHA-1 : Le Microsoft Checksum Integrity Verifier (FCIV) https://support.microsoft.com/kb/841290. Utilisé pour comparer les valeurs des fichiers à une bonne valeur connue, il permet de s'assurer que les fichiers n'ont pas été modifiés.
Mais cela fonctionnerait également pour notre objectif. Nous avons donc lancé FCIV contre le certificat de l'autorité de certification émettrice en utilisant le hashtype par défaut de FCIV, à savoir md5.
Non, ce n'était pas ça.
Qu'en est-il de la racine ?
Bingo !
Le hachage qui vous est présenté dans la page d'administration de NDES est le hachage MD5 du certificat de l'autorité de certification racine !
Pourquoi le hachage MD5 ? Cette question pourrait faire l'objet d'un autre blog.