Re: Client says Can't contact LDAP server, but it can!

[Howard Chu <hyc@symas.com>]

John Oliver wrote:
> On Mon, Jul 28, 2008 at 09:20:23AM +0200, Buchan Milne wrote:
> > Or, ensure that the "CA certificate" that the clients use contains the
> > certificates of the issuer of both of the server certificates, and that the
> > value of the subject CN on both certificates matches the name you use to
> > connect to the servers.
>
> I've tried:
>
> openssl req -newkey rsa:1024 -x509 -nodes -out server.pem -keyout
> server.pem -days 3650
>
> That should create a file with keys and certs all in one, right?  No
> possible misunderstanding about which is where.

Have you tried actually reading the OpenLDAP documentation? It appears you 
haven't. Start here and read the whole chapter:
http://www.openldap.org/doc/admin24/tls.html

It's a really stupid idea to keep the key and cert in the same file. The point 
of public-key cryptography is that you generate two pieces, and allow one 
piece to be distributed publically while requiring the other piece to be kept 
private.

> For the OU, I put the domain name.  I have also tried using the FQDN in
> a few variations.

Irrelevant, the software will only look at the CN in the DN.

> For the CN, I put the FQDN.
>
> I pointed TLSCertificateFile, TLSCertificateKeyFile, and
> TLSCACertificateFile at that file in slapd.conf, and restarted the LDAP
> service.
>
> And it doesn't work.

What "it"?

> On my test client, ldap.conf has:
>
> host 10.99.16.7
> base dc=mydomain,dc=com
> url ldaps://unix-services2.mydomain.com:636
> timelimit 120
> bind_timelimit 120
> idle_timelimit 3600
> ssl yes
> tls_cacertdir /etc/openldap/cacerts
> tls_checkpeer no
> pam_password md5

The above is not valid for an OpenLDAP ldap.conf. (See the ldap.conf(5) 
manpage for what's valid.) It appears to be a PADL nss_ldap config file, but 
it's still invalid for that purpose. Make sure you're actually looking at the 
correct config file...

> If I change the "host" and "url" to the other LDAP server, it works
> perfectly.
>
> On the working server, in slapd.conf I have:
>
> TLSCertificateFile /etc/ssl/ldap.pem
> TLSCertificateKeyFile /etc/openldap/ssl/ldap.pem
> TLSCACertificateFile /etc/ssl/ldap.pem
>
> Those files were created with:
>
> openssl req -new -x509 -nodes -out /etc/ssl/ldap.pem -keyout
> /etc/openldap/ssl/ldap.pem -days 3650

> I created a second set of keys with that line on the non-working server
> in the same directories (/etc/ssl and /etc/openldap/ssl).  That didn't
> work either.
>
> On both servers, I can do:
>
> openssl s_client -connect localhost:636 -showcerts
>
> And get identical results (except for the FQDNs, of course, and the
> jumble of characters in the certificate).

That tells you that the server was able to use the certs you specified, but it 
doesn't tell you if the client is correctly configured. (Which it obviously is 
not.)

> On a client pointed to the non-working server:
>
> [root@localhost ~]# ldapsearch -x
> # extended LDIF
> #
> # LDAPv3
> # base<>  with scope sub
> # filter: (objectclass=*)
> # requesting: ALL
> #
>
> # search result
> search: 2
> result: 32 No such object
>
> # numResponses: 1
>
> Supposedly, that means "it works", even though it doesn't.  I don't know
> what to make of that.

What exactly do you think "ldapsearch -x" was *supposed* to do? It looks like 
it's working perfectly well, given that you haven't fully configured the client.

> I just don't know where to go from here.  I've created certificates over
> and over and over again.  Even if by accident, I'd have had to have done
> it right at least once.  On the other server, I did it once, and it
> worked.
>
> It looks like there must be some other variable... a config file,
> something, that has something else to do with this.

--
  -- Howard Chu
  CTO, Symas Corp.           http://www.symas.com
  Director, Highland Sun     http://highlandsun.com/hyc/
  Chief Architect, OpenLDAP  http://www.openldap.org/project/