On Mon, 27 Oct 2008, LÉVAI Dániel wrote: ...
Slapd starts with these settings gladly, and with a client (eg. ldapsearch) without requesting TLS connection, I can get to the invalid credentials error (which is what I'm expecting now, this is just testing.). But with requesting TLS:
...
$ ldapsearch -d 1 -ZZWx '(objectclass=*)' \ -H ldap://fileserver.digiszfv:636
There are two ways to use LDAP with TLS/SSL: 1) start the connection in cleartext and then use the StartTLS extended-op to initiate a TLS layer, or 2) negotiate a TLS/SSL layer immediately after connecting.
The former is requested using the "ldap://" schema with the -Z option and is normally run on port 389. The latter is requested using the "ldaps://" schema and is normally run on port 636. These are distinct protocols: the client and server have to be talking the same one or it just won't work.
Your ldapsearch tried to do the former (LDAP w/StartTLS) on the port reserved for the latter (ldaps). The server was expecting to see a TLS client-handshake as the first data but instead got an LDAP extended-op and it all goes off the rails after that.
So, don't mix them. If you want to do the former, then drop the bogus ":636" from the URL: ldapsearch -d 1 -ZZWx '(objectclass=*)' \ -H ldap://fileserver.digiszfv
If you want to do the latter, then set the schema correctly, drop the -Z options, and drop the ":636" (because that's the default for ldaps): ldapsearch -d 1 -Wx '(objectclass=*)' \ -H ldaps://fileserver.digiszfv
(If you're using the default ports, then you don't need to specify them for the OpenLDAP clients, as they'll use the right default for the schema. I hear that was broken in the obsolete slurpd daemon for replication URLs, but you shouldn't be using that anyway.)
Philip Guenther