Yesterday, Jamf sent out the following notification in advance of the release of Jamf Pro 10.11.0:
One part of the message which caused some concern is this section:
Additionally, any LDAP server connections using LDAPS will require that the hostname of the LDAP server match the Common Name (CN) on the certificate that is uploaded to the Jamf Pro Server. A mismatch will prevent communication between the LDAP server and Jamf Pro Server.
What’s being referred to here is what’s known as an SSL hostname mismatch error, which is a sign that the SSL certificate being used to secure the connection isn’t configured correctly. But how can you tell with the SSL certificate used on an Active Directory domain controller? For more details, please see below the jump.
You can use the following openssl command to pull information about the SSL certificate used on your AD domain controller.
openssl s_client -connect servername_goes_here:636
You’ll need to replace servername_goes_here with the actual DNS hostname of your AD domain controller. For example, if your AD domain controller is named server.mycompany.local, you would use the following command:
openssl s_client -connect server.mycompany.local:636
When you run the command, you should get a block of text that looks similar to this:
Copy out the Server certificate section, between (and including) —–BEGIN CERTIFICATE—– and —–END CERTIFICATE—— and put the copied text into a text editor.
From there, save it as a .cer file.
Once saved as a .cer file, you’ll be able to check the certificate using QuickLook and see what the certificate’s common name (CN) is.
