On Thu, 22 Mar 2012, Borresen, John - 0442 - MITLL wrote:
Right now, we have two OpenLDAP servers running in Delta-syncrepl and
talking fine. All the clients are connecting to the primary over port
636. The question is on the best (practices) way of getting the
secondary server into the certificate without re-hashing all the clients
to the failover server's certificate.
1) Should I set up a Wildcard certificate?
2) Should I put both systems in the "subjectAltName" line and create the
certifiate, etc?
3) DNS Round-Robin?
Not 100% sure in which direction to go.
First, I'll explicitly say what you're alluding to -- OpenLDAP itself
won't care (and delegates this all to the TLS library, any decent one of
which should handle any of these options). So this is really a practices
discussion only.
I believe you'll find a lot more qualms about wildcard certs than with
subjectAltNames or "sharing" certs across nodes. They'll work, but
inherently they don't follow least-privilege philosophy, which has
well-discussed pitfalls.
subjectAltName is certainly an extremely obvious/intended treatment. It's
also nice that it can work without any additional technology involved.
I'm not a big fan of DNS round robin, in a traditional sense, for modern
deployments. If ldap.example.com. holds records for ldap{1,2} and ldap2
dies, you've got 50% visible failure under many DNS implementations.
That's...ugly.
I'll take the liberty of re-reading #3 as "sharing" a cert, i.e. install a
certificate for ldap.example.com. on servers that are "really" ldap{1,2}.
The plus here is that that cert should serve you "as is" until its
expiration, even if you rearchitect into ldap{3,4,5} at some later time.
You might like the fact that less of your infrastructure is detailed (i.e.
the cert only shows ldap.example.com. in all fields). The negative -- and
it's big -- is that you'll need some sort of smoke and mirrors in the way
to make this work. Nowadays that probably means some flavor of load
balancer/proxy and perhaps some trickery on the individual servers (think
/etc/hosts) as well.
One should also consider that it's a fascinating (ab?)use of the model, so
it might not be as intuitive to an outside observer as subjectAltNames
should be.
