We handle HA LDAPS on Novell eDirectory, but the problem is similar. We've managed to solve the problem with subject-alternate-names on the certificates. Subject-alternate-names are, simply, alternate Subjects you can put on a certificate in order to give it more than one name. That's how you can (in theory) have a single certificate that is valid for pop3.organisation.org, imap.organisation.org, and webmail.organisation.org. They're fairly new, but not as new as Extended Validation certificates.
Most modern LDAP clients are smart enough to treat SAN's correctly. Also, we manage the certificate authority that minted the certificates so getting a SAN is simple for us. It isn't so simple if you're going to end up paying for a certificate, the CA's would rather you purchase multiple certificates. Unfortunately for a lot of people, some software packages can only load one certificate. This is where SAN's come in.
We use a hardware load-balancer (F5 BiP) and three LDAPS servers. When we first set it up we created certificates with just the network name of the load-balancer IP/DNS. Clients connecting directly to the LDAP servers got certificate errors, which proved to be an incentive to get people to use the load-balancer IP address like they should have been doing all along.
We've since moved to using the subject-alternate-names as it was having some negative side effects with the Novell software running on those servers. But we did get it running without SAN's for a while. Each certificate has three names on it:
- IP Address of the load-balancer IP
- DNS name of the load-balancer IP
- DNS name of the direct host
This does expose the back-end hostname to those who snoop, but we don't consider this a vulnerability. Others might.
That's what we do, and it works for us.