ldap via TLS

Can someone point me to an idiots guide to ldap with TLS
I am about to throw stuff out of the window…

I have a Suse 11.1 box with a server certificate - if I enable TLS
on the ldap server and run the ldap browser on the local machine
with tls - it works ( if I set the log to pretty much everything I
get ‘tls established’ in messages )

I then exported to a file the server certificate and bunged it
on a web server and then on my client ( opensuse 11.3 )
download it and in ldap client specified the file. Now I the ldap
browser gives me connection error and the log on the server
says ‘tls negotiation failure’ - for this tests neither machine
has a firewall on

I am obviously doing something stupid … can someone point
me in the right direction and put me out of my misery ;-(

Ta

M

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

I’d be careful with the process you used to “[export] to a file the server
certificate” since there are multiple certificates. For example, there is
the one used for encryption which is signed by a trusted root. For each
there are actually two keys… public and private. Yes, you should be
exporting a certificate which contains the public key but then which
certificate (server or trusted root) did you actually get? You can use
openssl to see which certificate (along with its certificate chain
usually) is being sent from your LDAP server when your web server connects
to it as shown below, which MAY help you in verifying the one you have
exported is correct (assuming port 636 in this case):

openssl s_client -connect your.box.goes.here:636

It will send a bunch of data to your screen and then wait for your
input… just hit Ctrl+C. If you don’t get a nastygram before you need to
cancel out of openssl then your certificate is fine but now we’re into
PKI-land where trusts of certificates come into play, which is probably
what is causing your web server to be picky.

SSL/TLS vs. PKI is a difference of trust. Anybody can create a
certificate that is secure when used, but you need a trusted certificate
authority to have a certificate that is trusted by web browser and other
SSL-using clients all over the world (Digicert, Thawte, RapidSSL,
Verisign). In your case, if you didn’t get a “trusted” certificate from
some public CA then you have your own CA which is not trusted by everybody
all over the world, but is still valid for your own uses. The hangup is
that you need to tell your web server (Apache I presume) to trust that CA
so anything that CA mints (creates) will be trusted as well. Try the
following and post your output (hit Ctrl+C after each run to get back to a
prompt again):

openssl s_client -connect your.box.goes.here:636 -verify 0
openssl s_client -connect your.box.goes.here:636 -verify 1
openssl s_client -connect your.box.goes.here:636 -verify 2

The first one will probably have ‘Verify return code: 0 (ok)’ at the end,
and the other two will tell you that you’re using a self-signed CA with
‘Verify return code: 19 (self signed certificate in certificate chain)’.
Anyway, I’m still tinkering to figure out how to do some verification at
that point (openssl is great, but HUGE) and I’ll post back more when I
have it. Give the above a shot to see if you can narrow down the issue.

Good luck.

On 11/12/2010 07:36 AM, interele wrote:
>
> Can someone point me to an idiots guide to ldap with TLS
> I am about to throw stuff out of the window…
>
> I have a Suse 11.1 box with a server certificate - if I enable TLS
> on the ldap server and run the ldap browser on the local machine
> with tls - it works ( if I set the log to pretty much everything I
> get ‘tls established’ in messages )
>
> I then exported to a file the server certificate and bunged it
> on a web server and then on my client ( opensuse 11.3 )
> download it and in ldap client specified the file. Now I the ldap
> browser gives me connection error and the log on the server
> says ‘tls negotiation failure’ - for this tests neither machine
> has a firewall on
>
> I am obviously doing something stupid … can someone point
> me in the right direction and put me out of my misery ;-(
>
> Ta
>
> M
>
>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.15 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQIcBAEBAgAGBQJM3WJsAAoJEF+XTK08PnB5LKkQALNN6LhLBE/DMHx/HiblL0vn
bImf60HDtyVy3NaM78npXK40zNCH1GlwBc74AW++ipR93YdX/M3bxsPeituoSNQ3
YnQuYU/cmi1nB+Dz5Oo1ooxMFdjnMb65/vruh4g+f4FxeFN7Jbu4rpgCmMLDKecU
S8wK0wndZ3NNqbEQiOmBDjMj+Q1USoaGlnYWcIOi0QpAAioFlYhTa3kHnnAC944r
XfbSLFlcKH6P9slxg5WU4qQyo03HvYOpB3oNHZ5A5fJKfmPTBGZoRacf0fF8AkWT
WwgpuLnM+BOVoM+oGQeeHBiUUL/ovBP0SzBmyiin8iGnDsrg+wiz++HJk1ulAGsv
1NATRU+LLp9WXPLvEsbFQVExIGxw+AjtIP9mVHFVc1rqBP17DkH37XmsNpEgFIOF
qTPy9wGlntTIox0D4R//QfQr9MGM81B3XGY3byrlFHCeltv3NEU3qQFqDog3Rmnn
uvgyiizRowLUEyUcYSp/e9Y5OysS4ivWKxAHdd9cuiOrrrAMw6kF//Kx9ixteiGG
4zO/2YF0addGEMLJH/ZQcddA2eey0BfbqF4DHFc4NT38imd6J3LUlTdaTtimRcXD
SEDrjigK0jkcsUD6qvykVF2+O+k1Y+4sbJDrB5QF/Qe6D5NiedLs8xnH0dScjiHp
scNhKFCMyu471t8WpIrJ
=qOqp
-----END PGP SIGNATURE-----

Thanks for getting back… I’ve gone home now as my brains were
coming out of my ears trying to get this to work… I have a perfectly
working set up using ( non tls) ldap to do logins and autofs (via nfs4)
stuff for opensuse clients and a suse login/file server… but I thought
using tls would be more secure although within a school environment
it’s probably overkill but I would like to get it working.

Incidentally you might be interested in the background to this. We have
been testing an opensuse/suse client/server setup as opposed to our
current XP/2003 setup

  1. the time from starting a PC to login to getting one app running - the linux setup beats MS by a long, long way
  2. the students love linux
    … I am optimistic … :slight_smile:

M

I think I might have finally got somewhere
I used GQ as a ldap browser and it barfs with
‘self signed certificate in certificate chain’ which
is a little more helpful … :frowning:

M

Just some thoughts…
Where are you using TLS? - Typically TLS is implemented server<>server, much less commonly server<>client.
SSL is used commonly both server<>server and server<>client.
TLS is probably a bit more secure than SSL.
When setting up TLS, because it’s used rather infrequently, it’s common to use one machine to generate the pair of files (so that they share the same CA root authority), transfer one of the files to the other machine in any way possible, install in the local store, then setup your TLS connection. Should be very simple and straightforward.

Note that setting up any encrypted network connection(LDAP does not matter) does not actually require setting up a CA, certificate hierarchies, etc, you only need the two machines to each use certificates which are trusted by the other machine. A CA is recommended when you need to manage large numbers of certificates within an organization.

SSL connections are bit different depending on whether you’re setting up one way authentication (eg what you typically see on the Internet) or mutual authentication. Again, usually the key to avoiding invalid certificate errors is to generate all certificates using the same application on the same machine in your network (Treat your CA like another Domain Controller). The first Server certificate generated by your CA can and in a private network is self-signed. Every other certificate it generates for Servers and Clients in your network should not be self-signed, they should reference your CA (which will prove itself with its own certificate).

if you want some help configuring LDAP, one good resource I’d recommend is the OpenLDAP website. It’s very long but very good. Take your time going through it. Another thing you’ll probably need to do is to describe at least the main pieces of your LDAP configuration, LDAP is only a distributed lookup directory, nothing more… You also need to specify exactly what you’re configuring to provide Authentication and Authorization Services, eg Kerberos. I assume that you already have the other required pieces in place like integrated DNS and DHCP Servers that support LDAP and you’ve configured those LDAP objects already.

I agree if your clients are entirely within a protected LAN that Client encrypted network connections are overkill. Just encrypt your Server connections. So, if this is the case I’d recommend you re-direct your efforts to securing the network and if necessary any wireless, that’s the usual approach.

HTH and IMO,
Tony