Il y a vingt-cinq ans, LDAP avait du sens.
Quand ADCS desservait un monde Windows pur derrière le périmètre corporatif, publier votre CRL dans LDAP était la norme. HTTP était aussi commun, pointant généralement vers C:\Windows\System32\CertSrv\CertEnroll sur l'AC elle-même. Les deux étaient faciles. Les choses ont changé.
Le problème du HTTP-sur-l'AC
Si votre URL CDP pointe au nom d'hôte de l'AC, la migration devient pénible. Remplacer une AC 2012 par une AC 2025, ça veut dire soit garder la machine 2012 active juste pour servir les CRL, soit mettre en place un alias DNS de l'ancien nom vers le nouveau. Ni l'un ni l'autre n'est bon. Pointez le CDP vers pki.macorp.peu-importe à la place, et vous redirigez juste la sortie CRL de la nouvelle AC vers cet emplacement DNS. Fini. C'est « un AC est un AC » appliqué à la couche CDP.
Maintenant LDAP
ADCS ne sert plus uniquement les clients Windows. Serveurs Linux, équipement réseau, IoT, mobiles, presque aucun d'entre eux ne s'authentifie à LDAP. Si vous avez ordonné vos chemins CDP avec soin, HTTP venait en premier et ces clients ne touchent jamais LDAP. Si LDAP venait en premier, ils le frappent, attendent le timeout, puis se rabattent sur HTTP. Ça fonctionne quand même. Ça semble juste bizarrement lent, d'une façon très difficile à diagnostiquer.
Le scénario à distance
Allez-vous ouvrir les ports 389 et 636 sur Internet pour que je puisse vérifier une CRL depuis mon café ? Non. HTTP, vous l'ouvririez. Alors quand je me connecte à votre appareil VPN et qu'il présente un cert d'authentification serveur, mon client valide la révocation, le CDP LDAP n'est pas accessible d'où je suis, et le fallback HTTP est ce qui fonctionne pour vrai.
Le problème LDAP plus discret
L'URL LDAP intégrée dans chaque certificat émis expose le namespace de configuration de votre Active Directory interne. Chaque cert qui quitte votre réseau emporte ce chemin avec lui. Perdez un appareil, partagez un cert avec un partenaire, exposez un cert dans une capture de paquets, et l'information structurelle part avec.
Donc, faire du LDAP, oui ou non ?
Mon avis : non. C'est incompatible avec trop de choses pour lesquelles ADCS est réellement utilisé en 2026, et ça laisse fuir des informations qui n'ont pas besoin de fuir. Un CDP HTTP vanity devant un load balancer va servir tout ce qui doit faire une vérification de révocation.
N'éteignez pas la vérification de révocation
L'autre chose que j'espère que vous n'avez pas faite, c'est de désactiver la vérification de révocation parce que c'est « compliqué ». Cette vérification, c'est ce qui vous protège quand on me vole mon téléphone pendant que j'ai le dos tourné, ou quand j'oublie mon portable dans un Uber. Vos utilisateurs savent-ils vraiment qu'il faut signaler un appareil perdu ?
Du terrain
Vous vous demandez comment réparer ça si vos CDP pointent déjà sur le nom d'hôte de l'AC ? Vous ajoutez une nouvelle valeur HTTP CDP avec le nouveau namespace, mais vous gardez l'emplacement CDP original actif aussi. Chaque cert déjà émis dans votre environnement référence l'ancienne URL. Les vérifications de révocation sur ces certs continuent à le frapper jusqu'à ce qu'ils expirent ou soient ré-émis avec la nouvelle valeur dans leur liste d'extensions.
L'ancien CDP meurt par attrition. Si vos durées de vie de modèle étaient considérées appropriées il y a 25 ans — des certs de cinq, dix, quinze ans — cette attrition peut prendre des années.