Checking the SSL certificate used by an Active Directory domain controller
Yesterday, Jamf sent out the following notification in advance of the release of Jamf Pro 10.11.0:
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| This message is to inform you of security enhancements coming in Jamf Pro 10.11.0 that affects the Jamf Infrastructure Manager and LDAPS. | |
| Effective in the upcoming release of Jamf Pro 10.11.0, Jamf Infrastructure Manager instances will need to be re-enrolled in order to continue to function with Jamf Pro Server 10.11.0 and later. If you are on 10.9.0 or earlier, you will need to upgrade to version 10.10.1 and re-enroll Infrastructure Manager instances before upgrading to 10.11.0. | |
| Re-enrollment can be accomplished using the following methods: | |
| For Infrastructure Manager on Windows, run the installer | |
| For Infrastructure Manager on Linux, run the command to re-enroll | |
| 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. | |
| For additional assistance with this process, please contact Jamf Support via Jamf Nation or support@jamf.com. |
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.
Leave a comment
Recent Comments
 | Ben LeRoy on Losing a giant |
 | Peter-Erik on Downloading installer packages… |
 | nathanhaggard on Losing a giant |
 | andras0602 on Disabling login window clock d… |
 | Jeff on Losing a giant |
Der Flounder 
I think that message was limited to those enrolled in the 10.11 beta. If you want to check this in a one-liner, this would work.
echo | openssl s_client -showcerts -servername gnupg.org -connect server.mycompany.local:636 2>/dev/null | openssl x509 -inform pem -noout -text | grep "Subject:"Rich, thank you so much for this. We are currently having an issue with our LDAP and Jamf Pro 10.10.1. It keeps saying the cert doesn’t match the name of the server. We have about 10 Domain Controllers. It only works when I point it directly to one of the DC’s. I would rather not have to specify a DC because then I would only have a single point of failure.
Great work, as always.