freeipa ssl ldap and round robin dns

Solution 1:

You should issue new certificates with subjectAlternitiveNames and point the dns record for that name at a load balancer.

• A) Turning off certificate checking does open you up to MITM. The advantage is that an encrypted channel can't be passively eaves dropped. It's more work to MITM an encrypted channel, but it's not much more. If you're not high value and don't operate across Wireless or open internet (as opposed to a VPN link), then turning off the certificate checking isn't very risky, but don't to it. Doing things the right way is just about as easy.
• B) Yes, the servers will need an subjectAlternitiveName or (and don't do this) a wildcard subjectName. However, FreeIPA does its own PublicKeyInfrastucture (PKI), which is to say you have your own self-signed Certificate Authority (CA), rather than a collect of self-signed certificates. This means that you only need to generate and replace the certificates for the FreeIPA servers (the ones used by LDAP). The CA certificate used for signing (that's the cert that's deployed across all your machines) stays the same, so there's no need to touch any other machines. Also, you don't need the servers private keys, just the public certificates.
• C) See the top, A and B are justification.

Solution 2:

Round robin dns is not necessarily going to give more availability in the case of server failure unless you're pulling the A/AAAA record from dns as the client will randomly try to connect to one of the servers, including the failed one. If the application doesn't attempt to reconnect, or is unlucky and gets the same record enough times in a row that it fails. Adding a load balancer in front adds extra complexity but does mean this possibility is lessened. If you're happy with the round robin for load sharing then I'd look at whether entering a subjectaltname in the certificate would satisfy the clients to ldaps, or failing that a wildcard might be suitable. Preventing man in the middles could also be achieved by running your own internal PKI and deploying this as a trusted CA in your client machines. This has the added advantage of being a central place you can see expiring or expired certificates rather than having to manage this on each host/service that has its own certificate.

Solution 3:

If all you are after is HA, I would do something a bit simplistic, but useful:

Set up an HA cluster for IPA (to avoid trouble - just run it in a VM, where the libvirt service is the protected process) and use that IPA instance for all those limited apps, while the other IPAs tend to user auth. IPA works great on KVM, I've run quite a few instances with zero issues over years