Twenty-five years ago, LDAP made sense.

When ADCS served a pure Windows world behind the corporate perimeter, publishing your CRL in LDAP was the norm. HTTP was also common, usually pointing at C:\Windows\System32\CertSrv\CertEnroll on the CA itself. Both were easy. Things have changed.

The HTTP-on-the-CA problem

If your CDP URL points at the CA's hostname, migration becomes painful. Replacing the 2012 CA with a 2025 CA means either keeping the 2012 box around just to serve CRLs, or setting up a DNS alias from the old name to the new. Neither is good. Point the CDP at pki.mycorp.whatever instead, and you just redirect the new CA's CRL output to that DNS-named location. Done. That's "a CA is a CA" applied to the CDP layer.

CDP extensions on an issuing CA, with a CDP pointing at the CA's own hostname ca01.pixa.local
Figure 1. CDP extensions on an issuing CA, showing the antipattern: a CDP pointing at the CA's own hostname (ca01.pixa.local). External clients can't resolve the .local namespace at all, and any future CA migration becomes painful because every cert already issued references this URL.

Now LDAP

ADCS isn't just serving Windows clients anymore. Linux servers, network gear, IoT, mobile, almost none of them authenticate to LDAP. If you ordered your CDP paths thoughtfully, HTTP came first and these clients never hit LDAP at all. If LDAP came first, they hit it, wait out the timeout, then fall back to HTTP. Things still work. They just feel weirdly slow, in ways that are very hard to track down.

The remote scenario

Will you open ports 389 and 636 to the internet so I can check a CRL from a coffee shop? No. HTTP, you'd open. So when I connect to the VPN appliance and it presents a server-auth cert, my client validates revocation, the LDAP CDP is unreachable from where I am, and the HTTP fallback is what actually works.

The quieter LDAP problem

The LDAP URL embedded in every issued certificate exposes the configuration namespace of your internal Active Directory. Every cert that leaves your network carries that path with it. Lose a device, share a cert with a partner, expose a cert in a packet capture, and the structural information goes with it.

So should you do LDAP at all?

My take is no. It's incompatible with too many of the things ADCS is actually used for in 2026, and it leaks information that doesn't need to leak. A vanity HTTP CDP in front of a load balancer will serve everything that needs to do a revocation check.

Don't turn off revocation checking

The other thing I hope you haven't done is turn off revocation checking because it's "hard." That check is what protects you when my phone gets stolen while my back's turned, or when I leave my laptop in an Uber. Do your users actually know to report a lost device?

From the field

You wonder how to fix this if you're already pointing CDPs at the CA hostname? You add a new HTTP CDP value with the new namespace, but you keep the original CDP location responding too. Every cert already in your environment references the old URL. Revocation checks against those certs keep hitting it until they expire or get reissued with the new value in their extension list.

The old CDP dies by attrition. If your template lifetimes were considered appropriate 25 years ago — five, ten, fifteen-year certs — that attrition could take years.