[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Idea for enabling LDAP SSL certificate checking



Todays squeeze-test version of Debian Edu fail to make sure LDAP
clients verify that they are talking to the correct LDAP server.  This
is a security risk and should be fixed before the release.

I do not really know all the hairy details of SSL certificate
checking, but thanks the very useful TLS error messages from ldapvi, I
have been able to get an idea for how to be able to enable SSL
certificate checking for the LDAP connections in Debian Edu/Squeeze.

ldapvi claim the certificate do not match the name of the server being
contacted.  The name in the certificate is specified in
/etc/ldap/ssl/slapd-cert.cnf to "ldap", and the warning made me
suspect that perhaps the LDAP clients require the certificate to use
the FQDN now instead of the short name.

This would force those trying to use a different DNS domain name for
their Debian Edu installation to create a new certificate for the LDAP
server, but I suspect that is unavoidable.

This patch in debian-edu-config would change the certificate name:

Index: etc/ldap/ssl/slapd-cert.cnf
===================================================================
--- etc/ldap/ssl/slapd-cert.cnf (revision 68196)
+++ etc/ldap/ssl/slapd-cert.cnf (working copy)
@@ -13,7 +13,7 @@
 L=Skolen
 O=Ldap server
 OU=Automatically-generated Ldap SSL key
-CN=ldap
+CN=ldap.intern
 emailAddress=postmaster@ldap.intern


I tested this, and with I got 'ldapsearch -ZZ -x' working with
tls_certreq demand in /etc/ldap/ldap.conf and ldap://ldap.intern as
the URI in ldap.conf.  'ldapvi -ZZD '(cn=admin)' worked too, but nslcd
did not.  To get nslcd working, I had to add 'tls_cacertfie
/etc/ldap/ssl/ldap-server-pubkey.pem' to /etc/nslcd.conf.  Not quite
sure how to do that with preseeding, so perhaps we have to add a new
cfengine rule for this.

Anyone know if I am on the right path with this, or that the LDAP
certificate problems should be solved in a different way?

If I am on the right path, I believe all clients using LDAP need to
connect to ldap.intern and not just ldap, and it will also require
adjustments to the client autoconfiguration and preseeding to make
sure FQDN names is always used.

Happy hacking,
-- 
Petter Reinholdtsen


Reply to: