[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: SSL certificates, kerberos keytabs, and load balancing

--On Tuesday, April 13, 2004 8:27 AM +0200 Dieter Kluenter <dieter@dkluenter.de> wrote:


Quanah Gibson-Mount <quanah@stanford.edu> writes:

--On Friday, April 09, 2004 3:26 PM +0200 denis.havlik@t-mobile.at wrote:

Hi, folks

I'm trying to figure out what happens when one starts doing the load
balancing with LDAP servers. Don't really need it today, but it seams to
be a good day for such questions. :-)

So, we have N machines called ldapX.mydomain that all answer to requests
sent to "ldap.mydomain". As far as "certificates"/"keys" go, there are
two things that can go wrong:
2) ssl certificate

OK, which name is used here? ldap.mydomain on all the servers, or
different certificate (issued for ldapX.mydomain) for each of the

Btw, could someone point me to a piece of documentation explaining
step-by-step how to set up load balancing 4 LDAP?

Good question about what it will want cert wise. I do *not* suggest software load balancing and SSL. For that to work, you need a * cert. We currently use software load balancing, and are unable to use TLS because the call to "ldap.stanford.edu" will return the server's real cert (ldapX.stanford.edu). If I use a different cert for the server (ldap.stanford.edu), I get a host name mismatch. So you'll have to use hardware load balancing. I plan to test that with Stanford's directory servers in the future, but that is a future project. ;)

To solve the host mismatch problem in certificates you may addionally use the attribute subjectAltName, i.e. commonName=ldap1.example.com subjectAltName=commonName: ldap.example.com

Verisign charges you for *each* subjectAltName. As I recall from when I was trying to get this to work, the RFC says only honor the subjectAltName if it is present. That means every host that might be returned must be in the subjectAltName. Since we have 10 servers, that gets cost prohibitive. I only found one place that would issue me a "*" cert, and they can't even do it right -- the *.FQDN has to appear in subjectAltName, which they see as a "custom" attribute, which they don't support.


-- Quanah Gibson-Mount Principal Software Developer ITSS/TSS/Computing Systems ITSS/TSS/Infrastructure Operations Stanford University GnuPG Public Key: http://www.stanford.edu/~quanah/pgp.html