Kerberos ldaps subject alternative DNS name

[#1]

I'm setting up kerberos with an existing Active Directory as KDC and having an issue communicating to the ldaps server. We have a cluster of servers for AD. let's say server1.example.com,server2.example.com,server3.example.com and the company just uses example.com to connect. I've setup ldap integration with amabri for user access to the portal via the ambari-server setup-ldap, but did it without ssl and I can use ldap://example.com as the ldap server and it works fine. With ldaps, however, ldaps://example.com:636 doesn't work. I get an error in the ambari-server.log: "java.security.cert.CertificateException: No subject alternative DNS name matching example.com found". I have imported the CA cert and each individual server's certificate into my keystore and put the ca in /etc/pki/ca-trust/source/anchors/activedirectory.pem, but I still can't get it to work for example.com. I can get it to work for server1.example.com and all the others individually, but I can't get it to work for the example.com dns name. I don't have control over the certificate creation on the AD ldaps side. These certs were self-signed by the AD server and each server has it's own certificate. Is there anyway to tell ambari to accept invalid certs for the kerberos wizard, or any other way to get the broader domain name to work? Thanks in advance for any help.

[#2]

Adding to this.....

Obviously, the reason that I would want to use the example.com DNS instead of a specific server's FQDN is for fault tolerance, but out of curiosity what would happen to our environment if we setup the ldaps kereros using one of the AD server FQDNs and the one that we used was removed from the cluster or crashed later on down the road?

[#3 · Accepted solution]

As far as I know there is no way around the issue except to get the example.com name added to the certificate as a subject alt name. TLS implementations have become more strictly enforced over the years. As anyone who has configured against NiFi will attest. Adding the subject alt name shouldn't be an issue except for the fact that the certificates are self signed instead of having a issuer chain. This means that all relying applications would need to update their trust stores with the new certificate/s. Your AD team should be using a chain rather than self signed because this will also cause problems when the self signed certificates expire.

[#4]

Thanks Andrew. I thought that was probably the answer. Hoping there was a work around