On Wed, 11 Dec 2013, vidya bharadwaj wrote:
have to implement a 2 way SSL mechanism on a LDAP connector in our
product. In order to test the implementation, we have chosen openLDAP2.4
as the data source.
You should *first* get SSL working without client certs. Once you have
that working, *then* add client certs to the config.
Next: is your intent to do
a) "upgrade from cleartext to SSL" (i.e., make an ldap:// connection and
then use the StartTLS extension to negotiate TLS),
b) "SSL on connect" (i.e., make an ldaps:// connection where SSL is
negotiated immediately after connecting)
I ask, because your config bits mix the two, which won't work: port 636 is
reserved for ldaps (choice (b)), but you used the -Z option to ldapsearch
(choice (a)). You must pick one.
If you want to do (a), then you should be using ldap:// on port 389 with
the -Z (or -ZZ) option.
If you want to do (b), then you should be using ldaps:// on port 636 and
*not* use the -Z option.
6. Following changes
were made in sldap.conf
So you want to be completely insecure? Why bother enabling SSL if you're
going to permit SSLv2 and even ciphers that DON'T ENCRYPT.
$ openssl ciphers -v MEDIUM:+SSLv2:+SSLv3:RSA | grep Enc=None
NULL-SHA SSLv3 Kx=RSA Au=RSA Enc=None Mac=SHA1
NULL-MD5 SSLv3 Kx=RSA Au=RSA Enc=None Mac=MD5
You should yell at the person or documentation that suggested using that
line and stop trusting them for anything involving security.
On the client side:
1. Following changes were made in ldap.conf
Do not use the HOST and PORT options. Use the URI option, as that lets
you specify the schema (ldap vs ldaps) in the same line. Next, in order
for the server certificate to be validated, the hostname you connect to
(in the URI) must match what's in the certificate, which should be an
FQDN. I.e., something like: