[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