[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Re: TLS problems with openldap
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