Certificates verify. That's a neat tool, put that information somewhere useful. I had been trying to prove that the certificates were good for a long time.
I changed from nscd, to nslcd by installing via yast, nss-pam-ldapd That wasn't too bad. I configured nslcd with: Uri ldap://nightmare.dark.net:389/ Base "dc=dark,dc=net" Ssl start_tls Tls_req never Tls_cacertfile /var/lib/ldap/cacert.pem Tls_cert /var/lib/ldap/server.pem Tls_key /var/lib/ldap/server.key Ldapsearch still works .... With -ZZ But su - jtobin Gets the same error message this time from kdeinit: nightmare:/var/log # tail -f messages |grep tls Nov 1 11:48:11 nightmare kdeinit4: nss-ldap: do_open: do_start_tls failed:stat=-1 Nov 1 11:48:11 nightmare kdeinit4: nss-ldap: do_open: do_start_tls failed:stat=-1 I guess I am wondering if I configured something wrong.... Why am I seeing nss-ldap in here... I installed nslcd, configured it, and didn't change any thing in ldap.conf or nsswitch.conf, should anything else be changed? tob nighttrain:~ johntobin$ On 10/28/11 12:08 PM, "Christopher Wood" <[email protected]> wrote: > Cheap advice inline. > > On Fri, Oct 28, 2011 at 11:44:25AM -0400, John Tobin wrote: >> 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 > > Always test starttls with -ZZ, so if your starttls isn't working the > connection will fail. > >> 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 > > Augh. If you can stop using nscd all this will be much easier for you. I > personally like nslcd rather than nss-ldap, but each to their own. > > If not, restart nscd before you start every troubleshooting round. > >> 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) > > First I would test that all the CA certs and server certs in use are > understandable by each other. Does the server cert on the machine running > slapd validate against the CA cert on the machine running ldapsearch? Does the > server cert on the machine running slapd validate against the CA cert on the > client machine? > > openssl verify -CAfile cacert.pem servercert.pem > > If the output says "ok" then the actual cert part is fine. > > At this point I would crank up the slapd debug level (run it in the > foreground) and match it again your ldap client debug logs. See if you can > reproduce the error above using a client like ldapsearch, using the same > search parameters as the nss-ldap client would use. > >> [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 [1]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. > > I'm getting a puppetized starttls working with 2.4.26/openssl on debian, but > much the same thing. > >> Thanks in advance. >> tob >> >> References >> >> Visible links >> 1. http://www.openldap.org/faq/data/cache/185.html >
