Ldap is up, trying to get tls working.

[John Tobin <jtobin@po-box.esu.edu>]

Title: Ldap is up, trying to get tls working.

Folks,

I have openldap up, it supports vsftpd, sshd, and 5 client linux machines for remote login.

I would like to get tls working. I would support either ldaps [port 636], or the tls available on port 389, I am aware of the differences in implementation, and the fact that an administrator effectively has to make a decision to support one or the other in most cases.

Currently:
I have slapd running configured for tls under ldap [std port 389].
I am testing it on the slapd machine, with a client on the same machine.
I am pointing to the same cacertificate in slapd.d [cn=config.ldif] and ldap.conf.

With that in  place, and the ldap.conf below:
nightmare:/etc # cat ldap.conf

base    dc=dark,dc=net
uri    ldap://nightmare.dark.net
# scope   sub
# binddn    "cn=admin,dc=dark,dc=net"
# bindpw    jackie
bind_policy    soft
# The user ID attribute (defaults to uid)
pam_login_attribute uid
pam_lookup_policy    yes
pam_password    exop
nss_schema    rfc2307bis
tls_reqcert    never
pam_filter    objectClass=posixAccount
ldap_version    3
nss_map_attribute    uniqueMember uniqueMember
ssl    start_tls
tls_cacert    /var/lib/ldap/cacert.pem
tls_cert    /var/lib/server.crt
tls_key            /var/lib/ldap/server.key


I have run ldapsearch:
nightmare:/media # ldapsearch -v -x -H ldap://nightmare.dark.net:389/ -b "dc=dark,dc=net" -Z
ldap_initialize( ldap://nightmare.dark.net:389/??base )
filter: (objectclass=*)
requesting: All userApplication attributes
# extended LDIF
#
# LDAPv3
# base <dc=dark,dc=net> with scope subtree
# filter: (objectclass=*)
# requesting: ALL
#

# dark.net
dn: dc=dark,dc=net
dc: dark
o: dark
objectClass: organization
objectClass: dcObject

# admin, dark.net
dn: cn=admin,dc=dark,dc=net
objectClass: organizationalRole
cn: admin

# Default Policy, dark.net
dn: cn=Default Policy,dc=dark,dc=net
objectClass: namedObject
objectClass: pwdPolicy
cn: Default Policy

# People, dark.net
dn: ou=People,dc=dark,dc=net
objectClass: organizationalUnit
ou: People
description: People is used in mapping the /etc/passwd entries

# jtobin, People, dark.net
dn: uid=jtobin,ou=People,dc=dark,dc=net
uid: jtobin
cn: John C. Tobin
objectClass: account
objectClass: posixAccount
objectClass: top
objectClass: shadowAccount
loginShell: /bin/ksh
uidNumber: 5000
gidNumber: 100
homeDirectory: /home/jtobin
gecos: John C. Tobin

# defaultDNS, dark.net
dn: cn=defaultDNS,dc=dark,dc=net
cn: defaultDNS
objectClass: top
objectClass: suseDnsConfiguration
suseDefaultBase: ou=DNS,dc=dark,dc=net

# DNS, dark.net
dn: ou=DNS,dc=dark,dc=net
objectClass: top
objectClass: organizationalUnit
ou: DNS

# search result
search: 3
result: 0 Success

# numResponses: 8
# numEntries: 7

nightmare:~ # 
#####

So I am assuming the ldapserver on ldap://nightmare.dark.net:389/ with tls works.
[I looked through the message output in /var/log/message and see the “STARTTLS” and “TLS established tls_ssf=256”]
I have done a number of similar ldapsearches. This appears to work correctly.

On the client machine I now do :

nightmare:/media # su - jtobin
su: user jtobin does not exist
nightmare:/media # 


/var/log/message - output......

nightmare:/var/log # tail –f |grep –I tls

Oct 28 11:29:01 nightmare slapd[11118]: conn=1217 op=0 STARTTLS
Oct 28 11:29:01 nightmare worker_nscd: nss-ldap: do_open: do_start_tls failed:stat=-1
Oct 28 11:29:01 nightmare slapd[11118]: connection_read(14): TLS accept failure error=-1 id=1217, closing
Oct 28 11:29:01 nightmare slapd[11118]: conn=1217 fd=14 closed (TLS negotiation failure)
Oct 28 11:29:01 nightmare slapd[11118]: conn=1218 op=0 STARTTLS
Oct 28 11:29:01 nightmare worker_nscd: nss-ldap: do_open: do_start_tls failed:stat=-1
Oct 28 11:29:01 nightmare slapd[11118]: connection_read(14): TLS accept failure error=-1 id=1218, closing
Oct 28 11:29:01 nightmare slapd[11118]: conn=1218 fd=14 closed (TLS negotiation failure)

[if you want more of the log, I can obviously get it, but these appear to be the important parts.]

This is probably a configuration error, or a logical / architecture misunderstanding, ok, I ‘m a newbie.
Do I have certificates incorrectly generated? [certificates were generated via http://www.openldap.org/faq/data/cache/185.html].
What did I do wrong?

This is running openldap 2.4.26 off of Suse 12.1 milestone 5.

Thanks in advance.
tob