Re: Idea for enabling LDAP SSL certificate checking
Den 12. aug. 2010 00:38, skrev Petter Reinholdtsen:
>
> 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,
I don't remember if I've tested with Squeeze specifically, but my
experience is that it works as long as the certificate Common Name
exactly matches the hostname you're connecting to.
In other words, if the certificate Common Name is "ldap", one has to
connect to the server using the hostname "ldap". I know that that worked
in lenny at least, I'll be very surprised if it doesn't in squeeze (but
at least in lenny ldapvi had a bug making it the only program not to
accept the certificate).
This said, one can make it possible to use both "ldap" and
"ldap.intern". Use e.g. "ldap.intern" as the Common Name, and put
"DNS:ldap" in the subjectAltName (google openssl subjectAltName for more
information).
Hope this helps,
John.
Reply to: