Confluence, Active Directory and SSL: Worked around
At least in the 5.8.9 on-premises installation of Atlassian’s (otherwise quite handy) Wiki replacement, called Confluence, Windows Domain owners face an issue which at least I would locate somewhere between “strange”, “paranoid overkill” and “counterproductive nagging” although it is most likely but something they have imported with some Java SSL library.
When trying to connect to our local AD DC via SSL on default port 636, and after having imported the local CA certificate into Confluence’s keystore (using the keytool thingy shipped with the installer package), and even after cloning the keystore from the Jira machine (we have a dedicated KVM host set up for each service for better separation and to avoid any mix-mox issues) and setting Confluence’s User directories entry for a new Active directory to exactly the same settings we use successfully with our Jira 6.4.something installation, testing the connection would fail with
Connection test failed. Response from the server:
our.ad-server.internal:636; nested exception is javax.naming.CommunicationException: our.ad-server.internal:636 [Root exception is javax.net.ssl.SSLHandshakeException: java.security.cert.CertificateException: No subject alternative names matching IP address 188.8.131.52 found]
where 184.108.40.206 represents our AD DC’s actual IP.
Since not even Atlassian’s own documentation on “how-to Active Directory” mentions an IP SAN attribute at any point, I suspect this is something that came in with an updated (“security hardened”) Java library they simply did not test thoroughly (why would they, with Crowd in place for their own hosting). Also it seems like a strange idea to have an IP in an SAN attribute anyway, once we talk private net ranges. But while I can somehow empathize with the general security-improvement idea, the overall of such actionism here is entirely the opposite of “more secure” in most cases: You start googling, you find recommendations to disable cert checking in total, or to hack some additional plugin to always-TRUE those checks and so forth. (Reminder: Please, do not do “something” in order to “at least do someting”, regardless of how many are yelling. This applies to anyone, at all time. Thank you.)
I quickly decided not to touch any of our AD CA settings, since they work just fine with any service so far, even with Jira. And there may also be some consideration in the fact that MS has not set any IP SAN attribute to be part of default Windows PKI server behaviour. Also, a related issue (I looked it up and forgot it quickly due to two years of nothing and “minor” consideration) is still open and unresolved.
At least if you have a Jira server at hand, and some network perfomance in reserve, the workaround is rather simple.
First, make sure your Jira machine integrates fine with your LDAP/AD. Then, add an application account for your Confluence instance, this happens on the Jira machine at User management > JIRA user server (other than still published in all official docs I found, this could use some rework, too).
Second, add the Atlassian Jira directory type on your confluence instance, instead of the “MS AD” option. Use the credentials you just set up and make sure they pass a test.
Third, you’re done. You may want to check External user management at Users & Security > Security Configuration, at least if you do not want to be able to edit any users or groups from within Confluence anymore. I left it unchecked; both now works fine. We can manage local users (handy if you’re dealing with externals) and also groups across both systems, from either system. We can even take all existing AD objects into account for our complex configurations (this is why we are here on this page) - great.
However, Atlassian, finding out on all this has been quite some unpaid hassle. I were much more satisfied if I had found a better-working out-of-box solution; keep in mind that on-premises users still do pay your valued services, even if not on a monthly base. Even more, as the solution I finally chose is not the one you recommend explicitly during setup (instead, you encourage standalone LDAP connection, which was quite unsatisfying here).
Thanks for reading, also hoping I could be helpful to somebody.