Okay, I think I finally got somewhere.

Created the host for the load balancers:
# ipa host-add ipa.example.com

Added a LDAP service for it:
# ipa service-add LDAP/ipa.example.com

Added both IPA servers to the "managed by" attribute:
# ipa service-add-host LDAP/ipa.example.com --host ipa-11.example.com
# ipa service-add-host LDAP/ipa.example.com --host ipa-12.example.com

Then to get the certificate on each server...
on ipa-11 specifically:
# mkdir nssdb-test
# ipa-getcert request -d ./nssdb-test -n Server-Cert -K ldap/ipa-11.example.com -N CN=ipa-11.example.com,O=EXAMPLE.COM -D ipa-11.example.com -D ipa.example.com -g 2048

on ipa-12 specifically:
# mkdir nssdb-test
# ipa-getcert request -d ./nssdb-test -n Server-Cert -K ldap/ipa-12.example.com -N CN=ipa-12.example.com,O=EXAMPLE.COM -D ipa-12.example.com -D ipa.example.com -g 2048

I should then be able to replace the certificate that FreeIPA installed in each 389DS instance with the corresponding new certificate that adds the LB hostname as SAN, restart them, and it should just work I imagine? Is there any extra magic involved wtih replacing the existing certificates (special trust issues or whatever) due to being part of a FreeIPA installation or would it be the same as updating any old 389DS installation, just replace the existing certs? Also, will I need to be concerned that at some point FreeIPA is going to helpfully auto-renew the certificates and put the non-SAN ones back in (and if so, how do I get it to helpfully renew the SAN certs and auto install them instead) ?

On Tue, Aug 20, 2019 at 6:38 PM Jonathan Vaughn <jonathan@creatuity.com> wrote:
I've seen some guides for doing reverse proxy of SSL using Apache/Nginx which seem to side step the SSL issue by terminating SSL in the proxy but that only works for actual HTTPS connections to the FreeIPA UI, not for LDAPS.

I have got keepalived + HAProxy configured such that accessing ipa.example.com will go through HAProxy and on to FreeIPA for LDAP(S). LDAP works perfectly fine, LDAPS works if the client can ignore the SSL certificate name mismatch (since of course, the SSL certificate will be ipa-11.example.com or ipa-12.example.com or whatever the FreeIPA server actually is). 

We need this because Atlassian doesn't want to support multiple LDAP host names in configuration without paying for Crowd (which is a pretty redundant product when we have FreeIPA already). Additionally, I can't disable the hostname check for SSL either, which would at least work around the issue, so we need to get ipa.example.com into each FreeIPA LDAP server's SSL certificate.

How can I add ipa.example.com as SAN to the SSL certificate used by 389DS in FreeIPA?

At first I thought maybe I should start with adding HTTP/ipa.example.com as a principal alias to each HTTP/ipa-(server).example.com and then reissue the SSL but apparently I can only add the alias to a single principal (can't have it on multiple servers)...

The basic layout is this:

10.0.0.10 : ipa.example.com (virtual IP / VRRP)
10.0.0.11 : ipa-11.example.com
10.0.0.12 : ipa-12.example.com

HAproxy runs on both ipa-11 and ipa-12 and each instance of HAproxy is configured to sticky sessions.

Keepalived runs on both ipa-11 and ipa-12, both configured as master but with ipa-11 set as a higher priority so that nominally all requests go to ipa-11 unless ipa-11 is down, in which case the virtual IP moves to the other server.

When connecting to ipa.example.com, connection may end up at either of ipa-11.example.com or ipa-12.example.com, and we need them both to have ipa.example.com in addition to their real server name in the SSL certificate for LDAPS to work correctly. So the certificate for ipa-11.example.com should include in SAN both ipa-11.example.com and ipa.example.com, and the certificate for ipa-12.example.com should include in SAN both ip-12.example.com and ipa.example.com.