From: Simon Walter <>
> Date: Thu, 26 Nov 2009 17:41:15 +0900

> Howard Chu wrote:
> No. Specifying the port number only does that, it doesn't turn on SSL
> at all. (Nor should it. The Microsoft tools are, as usual, playing
> fast and loose with the LDAP specs.) The way to get SSL is to use a
> URI, and stop using the old/deprecated -h and -p options. Read the
> ldapsearch(1) manpage.
>    ldapsearch -H ldaps://adserver:636

Thanks Howard. I've tried that as well and have read some of the man
page. However, I suspect that perhaps the server is not configured
correctly if the above should work. I still get:

ldap_sasl_interactive_bind_s: Can't contact LDAP server (-1)

Try it with -d7 and see what kind of network traffic shows up. It will also show you the SSL handshake, if the server actually answered.

I haven't installed the server's cert on the client.

I hope you mean "the CA cert". The server cert only needs to be on the server.

However, I would
think that I'd see a different error rather than the above if a missing
cert was my only problem. Say I manage to figure out how to get the cert
off of the AD server(someone else set up this server and says they have
all the certs configured correctly), I would then use TLS_CACERT and
TLS_CACERTDIR in the client's ldap.conf file to specify it's location.
Am I getting this?

You use only one or the other of TLS_CACERT or TLS_CACERTDIR, not both. In our docs we recommend only using TLS_CACERT because scanning a filesystem directory (TLS_CACERTDIR) is problematic in lots of situations. (E.g., in some versions of OpenSSL there was a file descriptor leak; it's not guaranteed to be thread safe, etc. etc. etc...)

Thanks for your advice - much appreciated.

  -- Howard Chu
  CTO, Symas Corp. 
  Director, Highland Sun
  Chief Architect, OpenLDAP

Reply via email to