RE: Load-Balanced LDAP Servers + TLS/SSL

["Howard Chu" <hyc@highlandsun.com>]

You should re-read section 3.6 of RFC 2830. In particular, you should look
into using the subjectAltName/DNSname extension in your server certificates.
This will allow you to list both the load-balanced name "ldap.example.com"
and the correct individual server name in the certificates. Your actual
solution will require you to create 3 individual server certificates,
instead
of the single one that you're sharing around right now. For each cert, the
certDN's cn should be the actual hostname (one.example.com, two.example.com,
and three.example.com) and the subjectAltName could just be "*.example.com".
If your domain has other members you don't want to worry about, you should
list both the specific name (e.g. one.example.com) and the balanced name
(ldap.example.com) in the subjectAltName.

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

> -----Original Message-----
> From: owner-openldap-software@OpenLDAP.org
> [mailto:owner-openldap-software@OpenLDAP.org]On Behalf Of
> lf+openldap@emyr.net
> Sent: Wednesday, October 10, 2001 8:24 PM
> To: openldap-software@OpenLDAP.org
> Subject: Load-Balanced LDAP Servers + TLS/SSL
>
>
> Suppose that there are three servers:
>   one.example.com - master (slapd, slurpd)
>   two.example.com - slave  (slapd)
>   three.example.com - slave  (slapd)
>
> Now suppose that I configure my DNS as follows:
>   one.example.com   IN A  192.168.1.1
>   two.example.com   IN A  192.168.1.2
>   three.example.com IN A  192.168.1.3
>   ldap.example.com  IN A  192.168.1.1 ; round robin
>   ldap.example.com  IN A  192.168.1.2 ; round robin
>   ldap.example.com  IN A  192.168.1.3 ; round robin
>
> This way, requests from LDAP clients will be balanced across all three
> LDAP servers.
>
> Now suppose that I wish to use TLS/SSL for all my LDAP connections. I
> generate an SSL certificate for the common name ldap.example.com and I
> load it onto the three servers: one, two, and three.
>
> This works well, and all the requests, indeed, are balanced across the
> three servers.
>
> Unfortunately, the master (one) can't connect to the slaves (two, three)
> for purposes of replication because the replica directives in one's
> slapd.conf need to use the unique fqdns two.example.com and
> three.example.com. To wit,
>
> replica
>         host=two.example.com      (can't use ldap.example.com here)
>         tls=yes
>         bindmethod=simple
>         binddn="uid=foobar,dc=example,dc=com"
>         credentials="secret"
> replica
>         host=three.example.com    (can't use ldap.example.com here)
>         tls=yes
>         bindmethod=simple
>         binddn="uid=foobar,dc=example,dc=com"
>         credentials="secret"
>
> So, the question is, how to use TLS/SSL for replication in this
> round-robin configuration?  I want to use TLS/SSL for all of the LDAP
> connections, both client-server (queries/updates) and master-slave
> (replication).
>
> I have a few possible solutions:
>
> (1) Use a couple of stunnels on one.example.com as follows:
>
>       stunnel -c -d 127.0.0.1:20389 -r two.example.com:389
>       stunnel -c -d 127.0.0.1:30389 -r three.example.com:389
>
>     and change the replica stanzas to read:
>
>       replica
>         host=127.0.0.1:20389
>         tls=yes
>         bindmethod=simple
>         binddn="uid=foobar,dc=example,dc=com"
>         credentials="secret"
>       replica
>         host=127.0.0.1:30389
>         tls=yes
>         bindmethod=simple
>         binddn="uid=foobar,dc=example,dc=com"
>         credentials="secret"
>
>     This solution will work, but seems inelegant. Basically, it relies
>     on the fact that stunnel does not verify the SSL certificate by
>     default.
>
> (2) Modify slapd so that it can use different certificates for different
>     ports.  For example, I could start slapd on the slaves as follows:
>
>     two# slapd -h ldap:/// ldap://0.0.0.0:10389/
>     three# slapd -h ldap:/// ldap://0.0.0.0:10389/
>
>     This would require the configuration file, slapd.conf, to be
>     modified to support different TLS directives for the different
>     ports. Better, the -h flag could be deprecated and the slapd.conf
>     file could be augmented to have Listen and VirtualHost directives
>     similar to those in apache's httpd.conf.
>
> I'm interested in hearing alternate suggestions. I'm sure that (1) will
> work for me, but I don't think I'm the only person who would like to use
> TLS/SSL exclusively and who would also like to do load balancing. I
> think that (2) is a better solution.
>
> Yours,
>
> Luca
>
> --
> Luca Filipozzi
> [dpkg] We are the apt. Resistance is futile. You will be packaged.
>