LDAP over SSL

[Rich]

I am having fits making an AD Server (Windows Server 2003) do LDAP over
SSL. I've got a clean Server 2003 SP1 running as a Domain Controller, and
Certificate Services are installed. It's the only DC and CA in my domain,
and LDAP w/o SSL is working as expected.

There's a MS KB article that describes exactly what I'm trying to do
(http://support.microsoft.com/default.aspx?scid=kb;en-us;321051), and I've
followed it meticulously. I've created the Server cert, and installed it,
and all seems well. Except that I still can't connect to the DC over SSL,
on port 636.

LDP connects correctly on 389, and client apps can perform LDAP queries on
389 or 3268, no problem. But 636 and 3269 are no-gos.

I've double- and triple-checked the cert, and it looks correct in all
regards (in the DC's local computer store, has the right OID, has the DC's
FQDN as the CN in the Subject field, etc.); I've restarted the server
several times, and even just "waited a day" to see if some cached info or
whatever might have been flushed--no dice.

Any suggestions would be appreciated--I must have missed something, but
can't find what.

--Rich

 

[Eric Fleischman [MSFT]]

Hey Rich.
For the sake of testing, can you try to connect to SSL from the server
itself, rather than a client (you didn't say, but I'm assuming you are
testing from a client)?
If that doesn't work, we'll want to take a peak at the machine store to see
what certs are in there. Holler if this isn't working, and we can take it
from there.

~Eric

 

[Rich]

For the sake of testing, can you try to connect to SSL from the server
itself, rather than a client (you didn't say, but I'm assuming you are
testing from a client)?

I meant to mention that...in fact, I can connect via LDP on 636 and 3269,
from the server. (You are right that I'm generally testing from a client
system.)

If that doesn't work, we'll want to take a peak at the machine store
to see what certs are in there. Holler if this isn't working, and we
can take it from there.

As for the certs, there are two in the machine store: one that was created
automatically when the CA was installed, and one that was created by the CA
via a request file as described in KB article 321051. It appears to be an
appropriate cert--but I think if it were, this would be working?

A copy of the CA's cert (the one created automatically when the CA was
installed) is stored on the client system in the system's trusted root
certificate store--so the client trusts the server.

However, a sniff trace shows the client doing the SSL HELLO, and
certificate data being passed from server to client--then the client
terminates the connection. That looks to me like the server is attempting
to perform SSL, but client doesn't like the cert(s) that the server is
offering up, no? So maybe I'm looking for a problem on the server, when
the problem may be on the client end of things?

Thanks for your suggestions thus far, and further thoughts are welcome.

--Rich

 

[Eric Fleischman [MSFT]]

Yup, you got it. It is likely client side.
More often than not, when I've hit this it was due to the fact that the
client did not have the proper trusted root store entries. More
specifically, the cert was issued from a CA that the client does not trust,
but the server does.
It sounds like you went down this path.....

A copy of the CA's cert (the one created automatically when the CA was
installed) is stored on the client system in the system's trusted root
certificate store--so the client trusts the server.

Man, if only I were a cert guy! I'm really an AD guy. I can't fake ya out,
you took away my troubleshooting step.
Anyway, this is what I suspect is the problem. I suspect the client does not
properly trust the CA from which the server got the cert. Does someone else
out there have cert knowledge they can use to help Rich? I would suspect
this is a good starting point for this problem.

~Eric