LDAP+TLS problems

[Smoot Carl-Mitchell]

On Fri, 2008-09-05 at 10:23 -0400, Michael S. Peek wrote:

> I'm trying to set up slapd and I'm having some problems getting TLS to 
> work.  Without TLS everything connects just fine, but I would like to 
> configure things to only allow TLS connections.  I'm hoping someone out 
> there is an LDAP guru and can spot my problem.

Make sure your private key is readable by the "ldap" user.  I assume
that the server is running as the user "ldap". 

I also have the following TLS and SSL configuration options set in the
slapd.conf file:

# TLS Configuration
TLSCipherSuite HIGH:MEDIUM:+SSLv2:+SSLv3:RSA:+TLSv1
TLSCertificateFile /usr/share/ssl/certs/ldap.pem
TLSCertificateKeyFile /usr/share/ssl/certs/ldap.pem
TLSCACertificateFile /usr/share/ssl/certs/ca-bundle.crt
TLSVerifyClient never

The TLSVerifyClient is important because if it is not set to "never",
then the server expects the client to present a client certificate.  The
default may be "never", but I set it explicitly.


Also your client (if it is an openldap client) needs to not check the
server certificate name.  I usually set the option in the ldap.conf file
to:

TLS_REQCERT never

The default is to check the server certificate name against the DNS name
of the LDAP server.  If the name does not match, the session is
terminated. This is a common problem, if the Common Name in the
certificate does not match the server DNS name.  Be aware that setting
this option to "never" does allow someone to spoof your LDAP server and
fool a client into thinking they are connected to the real LDAP server.
So either set this option to "never" on your clients or make sure the
Common Name in the certificate matches your server's DNS name.

Also note that the URI ldaps://hostname

listens by default on port 636 and expects the connection to be
encrypted.  It appears you are trying to listen on port 389 for both an
unencrypted and encrypted (SSL) session.  If TLS works properly, you
only need to use the ldap://hostname URI, since TLS gets negotiated over
the initially unencrypted connection.

Also turn on "conns" logging.  It may show you the source of the error
when your server trys to negotiate TLS.
-- 
Smoot Carl-Mitchell
System/Network Architect
smoot at tic.com
+1 480 922 7313
cell: +1 602 421 9005