Commençons par quelques rappels : dans le cadre d’un déploiement d’une PKI (public key infrastructure, autrement dit le système permettant l’émission de certificats en entreprise), il est nécessaire d’inclure un ou plusieurs mécanismes de vérification de la révocation des certificats.

Le plus fréquemment utilisé s’appelle la CRL, ou certificate revocation list : il s’agit simplement d’une sorte de fichier texte contenant la liste des certificats révoqués par une autorité donnée, accessible via une classique adresse http. Bien qu’il existe des mécanismes de mise en cache, l’accès à cette liste de révocation peut s’avérer problématique lorsqu’elle commence à devenir volumineuse ou lorsqu’elle est accédée très souvent par de nombreux autres systèmes.

Un autre mécanisme nommé OCSP (online certificate status protocol) permet de pallier à ces limitations : au lieu de télécharger la liste intégrale des certificats révoqués à chaque vérification, il devient possible d’interroger ce service pour lui demander si le certificat n°XXXXX provenant de l’autorité Y est révoqué ou non.

C’est ce second mécanisme qui nous intéresse aujourd’hui, et plus précisément un bug assez surprenant que j’ai rencontré au cours d’un déploiement récent chez un client.

Lors d’un test de la chaine de validation des certificats à l’aide de la commande certutil -urlfetch -verify testcertificat.cer (très utile pour identifier à quel niveau un certificat est refusé, plus d’informations ici par exemple : https://www.sevecek.com/EnglishPages/Lists/Posts/Post.aspx?ID=13 ), je me suis retrouvé avec une exécution incomplète et en boucle des différents tests :

Suivie au bout de quelques secondes par un plantage pur et simple de certutil :

Quelques vérifications rapides me permirent de constater que lorsque le serveur OCSP était rendu indisponible, certutil retrouvait un fonctionnement normal (et indiquait bien sûr l’indisponibilité de l’OCSP) mais impossible d’aller plus loin dans la résolution, et Internet semblait pour une fois muet sur ce souci.

C’est finalement grâce à un collègue qui avait déjà rencontré ce cas que la solution a été trouvée : il s’avère le certificat OCSP Signing doit être émis par l’autorité pour laquelle le serveur OCSP réalise la vérification de révocation, autrement certutil présente ce comportement ; alors que dans ce déploiement c’est l’autorité émettrice qui avait été utilisée pour émettre les certificats OCSP Signing pour la vérification de l’autorité émettrice mais aussi de l’autorité racine (standalone et hors ligne).

La résolution du problème s’impose alors d’elle-même : il faut générer le certificat OCSP Signing sur chacune des autorités dont la vérification sera assurée par le répondeur OCSP, y compris lorsqu’il s’agit d’autorités standalone.

La procédure dans ce cas précis est détaillée sur ce blog : https://blogs.technet.microsoft.com/askds/2009/06/30/implementing-an-ocsp-responder-part-iv-configuring-ocsp-for-use-with-standalone-cas/ .
Notez également qu’il est nécessaire d’ajouter l’extension id-pkix-ocsp-nocheck au préalable (à l’aide de la commande certutil -v -setreg policy\EnableRequestExtensionList +1.3.6.1.5.5.7.48.1.5), car elle n’est par défaut pas disponible sur les autorités standalone.

Enfin, on regrettera que les informations disponibles à ce sujet sur les ressources officielles soient contradictoires, puisqu’on retrouve sur technet les deux passages suivants :

Windows Vista SP1 and Windows Server 2008 enable the OCSP signing certificate implemented by the OCSP responder to use a certificate that terminates in a different root CA than the CA whose revocation information is reported in the OCSP responses. This feature enables an organization with a diverse PKI to limit sources of revocation information and the CAs that can issue OCSP signing certificates.
(https://technet.microsoft.com/en-us/library/ee619736(v=ws.10).aspx au chapitre Independent OCSP signing certificate)

Online Certificate Status Protocol (OCSP) Response Signing certificates need to be signed by the same certification authority (CA) key that was used to sign the end-entity certificates that they provide status for.
( https://technet.microsoft.com/en-us/library/cc754774(v=ws.11).aspx )