La révocation de certificats échoue : quel hôte n’atteint pas quoi

Des certificats peuvent se trouver dans leur période de validité alors que le VPN signale encore un échec d’authentification, et quelqu’un en conclut que le certificat est révoqué. Ce sont trois faits différents. Les données de révocation doivent être récupérées par l’appareil qui effectue la validation, auprès d’un point de publication nommé à l’intérieur du certificat lui-même. Quand cet appareil ne peut pas atteindre le point, la vérification échoue pour des raisons sans rapport avec le statut du certificat.

Le validateur possède le chemin de récupération

Commencez par identifier le validateur. Quand un ordinateur portable vérifie le certificat de la passerelle, c’est lui qui effectue la récupération ; quand la passerelle vérifie un certificat client, c’est elle qui le fait. Un service d’authentification en arrière-plan peut ajouter un troisième validateur avec sa propre position réseau. Chacun a une route différente vers internet et une configuration de proxy différente. Les preuves recueillies sur la station de travail d’un administrateur ne disent rien d’un serveur à l’intérieur d’une DMZ.

Notez le certificat, le validateur, l’heure de la tentative et le code de statut exact avant de changer quoi que ce soit.

Lisez le point de publication dans le certificat

Le certificat indique où se trouve son statut. Lisez ces champs au lieu de deviner une adresse de CA.

openssl x509 -in gateway.cer -noout -text | grep -A3 "CRL Distribution Points"
openssl x509 -in gateway.cer -noout -text | grep -A2 "Authority Information Access"

La première extension énumère les points de distribution CRL, et la seconde énumère les méthodes d’accès aux informations d’autorité, qui peuvent couvrir le statut OCSP et la récupération du certificat de l’émetteur. Ce sont des mécanismes différents, et un répondeur OCSP n’est pas un fichier CRL. L’hôte de publication est souvent un simple serveur web et non la machine de la CA, car un émetteur hors ligne peut signer une CRL qu’un autre serveur distribue. Une règle de pare-feu décrite comme un accès à la CA est donc trop vague pour être mise en œuvre ou revue.

Testez la récupération depuis l’appareil qui valide

Exécutez le test de récupération dans l’environnement qui effectue réellement la validation, avec du matériel de certificat approuvé et sans clés privées.

certutil -urlfetch -verify .\client-test.cer
curl -sS -o /dev/null -w "%{http_code}\n" http://crl.example.com/ca.crl

L’exécution de certutil vérifie la chaîne et indique quelles récupérations d’URL ont réussi ou échoué, tandis que l’appel curl teste une adresse de publication depuis le même hôte et ne renvoie qu’un code de statut. Une récupération échouée depuis une adresse joignable indique un problème de contenu ou de signature ; une erreur de connexion indique un problème de routage, de DNS ou de proxy. Conservez les deux résultats, car une récupération réussie ne prouve pas que toute la chaîne est utilisable. Remplacez l’hôte et le chemin de l’exemple par le point de distribution trouvé dans le certificat.

Séparez les données manquantes du statut révoqué

Quatre issues se ressemblent de l’extérieur : le point est injoignable, la liste est périmée, la liste est signée par le mauvais émetteur, ou le certificat est réellement révoqué. Seule la dernière est un résultat de statut, et seule celle-là justifie de retirer l’accès. La mise en cache complique encore le tableau, car des données récupérées auparavant peuvent masquer un chemin de publication cassé jusqu’au prochain rafraîchissement. Désactiver la vérification de révocation, supprimer des certificats sans rapport ou redémarrer la passerelle remplacent tous le diagnostic par de l’activité.

Après la correction, forcez une nouvelle authentification et confirmez que la récupération de statut prévue réussit. Là où une identité de test contrôlée existe, confirmez qu’elle est toujours rejetée, car une disponibilité qui supprime la vérification n’est pas une réparation.