Hi all,

Let’s talk about “certificates”!

No, I’m not a certificate expert, just a guy who needs them from time to time, no way around it! So I decided to dedicate this post to the different certificates you might come across when using Jamf Pro. The goal of this post is mainly to differentiate the variety of certificates, and their purpose, not to give you a full in-depth discussion of each of one.

Depending on how you use Jamf Pro, what functionality you use and the different integrations you add to the JPS, the types of certificates which cross your path may vary. But one way or another you are using a good set of different types of certificates, whether you are aware of it or not. Let’s start with listing the different types you may use or need before we dive into discussing each of them. As you’ll see, I’ll elaborate some certificates a bit more in depth then some other types of certificates. This in view of the importance of the specific cert and it’s purpose, as well as keeping the length of this post within limits.

  1. SSL Certificate for Tomcat
  2. The built-in Jamf Pro Certificate Authority
  3. The built-in Jamf Pro Signing Certificate(s)
  4. Jamf Pro Device Certificates
  5. APNS Certificate
  6. Specific certificates for integrations like LDAPs, SCEP Proxy, SCCM, GSX…

SSL Certificate for Tomcat

This might be the most straight forward one to discuss. However, there might be some confusion regarding its importance in view of device communication.

I presume that it’s safe enough to assume we all understand the importance of HTTPS and SSL. However, without the intend to state the obvious, what does the SSL Certificate on Tomcat actually do? Well, nothing more than providing proof of the identity of the server. Whether that is a certificate for the specific FQDN or a wildcard cert, it doesn’t matter. Someone, trusted by the entire world, has verified the identity of this server and issued a certificate to proof it. In my case the DST Root CA, aka Let’s Encrypt:

But, when we, as a human being, see the below (when attempting to login to Jamf Pro, or when a user tries to enroll a device via User Initiated Enrolment), we know there is something wrong!

All straight forward I guess, but what about devices interacting with Jamf Pro? Well, exactly the same. Whenever a Mac or iOS device contacts the Jamf Pro server it also verifies the SSL certificate. Just like with every possible HTTPS/SSL connection you can imagine. SSL cert not valid? No communication! See what happens for instance with a ‘sudo jamf policy’ or ‘sudo jamf recon’ if the SSL cert of the Jamf Pro server is expired or invalid (wrong FQDN for instance):

I’ve seen situation where people panic when suddenly all communication with their (on-prem) Jamf Pro server stopped. Unless something bad happened to Tomcat, it’s often related to the SSL certificate. Especially when a new certificate was uploaded.

Note: although issues like this might be related to the SSL certificate itself, it's also possible that the uploaded SSL cert is missing an Intermediate CA or Tomcat was not rebooted after uploading he new cert.

The good news for all Jamf Cloud users is that all this is taken care of by some Cloud wizards at Jamf:

But wait a second, do I really need to upload my own SSL cert to Jamf Pro when I’m using an on-prem server? Do I have to buy one?

Well, while it is definitely recommended, in theory it’s not mandatory. When you install a new Jamf Pro server, the installation automatically creates a built-in Certificate Authority (see below). This certificate authority can be used to issue an SSL cert for Tomcat via the Jamf Pro settings:

Note: when installing a new Jamf Pro server, this step (if not uploading a publicly trusted SSL certificate) is mandatory! The installation process does create the built-in Certificate Authority, but does not automatically use it to issue a Tomcat certificate. Instead it generates a temporary self-signed certificate which is NOT ok for device communication as there is no way the devices could automatically trust this cert. A Tomcat reboot is needed after each change of the SSL cert.

But wait, how can a built-in CA be trusted by devices and users trying to communicate or login into Jamf Pro?

Well, for the users, it’s simple. The’ll need to trust the Jamf admin or IT team telling them to manually trust the SSL certificate of the Jamf Pro server. As the built-in CA is obviously not a publicly trusted CA, each browser will (or should) warn the user about a potential SSL issue. Hence they will need to manually overrule the warning and force the connection to the Jamf Pro GUI.

For devices it’s another story, because, like we discussed here above, there is no communication possible if the devices do not trust the SSL certificate of the server. Yes, during the enrolment process, Jamf Pro will install the Jamf Pro built-in Certificate Authority root cert on the devices to allow communication, but what about allowing the enrolment process to start with? Well, luckily there is an option in the Jamf Pro settings to ignore the SSL check during enrolment. This option needs to be selected when using the built-in Certificate Authority for the SSL cert.

Finally, good to know: whatever happens to the SSL certificate, potentially breaking the communication with the devices, it is never a permanent roadblock. Whatever the issue with the SSL certificate is, you can always upload a new one or if needed, temporarily, revert back to a SSL certificate issued by the built-in CA. It does not break enrolment.

The built-in Jamf Pro Certificate Authority

As discussed above, the installation process of each Jamf Pro server creates a built-in Jamf Pro Certificate Authority. This CA gets installed on each device during the enrolment process.

One purpose of this CA was discussed here above: to issuing a SSL certificate for Tomcat (when not using a publicly trusted cert), in order to allow trusted communication between Jamf Pro and the devices / users.

There are however other purposes for which this CA is used. First of all we have the MDM profile. We all know that each device, macOS or iOS, requires a MDM profile to allow communication via remote commands and the Apple MDM framework (Apple Push). This MDM profile needs to be signed by a trusted Certificate Authority.

By default the MDM profile is signed by the Jamf Pro built-in Certificate Authority, or to be more accurate, signed by a ‘signing certificate’ issued by the built-in CA (see below).

Note: larger companies may have security policies in place which require all certificates in use to be issued by an internal CA under their control. This is why Jamf Pro has an option to have the MDM profile signed by an 'external CA'. See screenshot below. I'm not going to position myself on thin ice here by giving any advise outside of my skill set, but I do want make one very important statement. If you do decide to sign the MDM profiles with an 'external CA' and something, unrecoverable, happens to that CA (unlikely, but still), there is no option to switch to another CA or revert back to MDM profiles signed by the built-in Jamf Pro CA without re-enrolling all the devices!

Just to avoid any confusion, enabling this option signs all MDM profiles via the ‘external CA’, and this has NOTHING to do with the Tomcat SSL cert!

This compared to a MDM profile signed by the built-in Jamf Pro CA:

The built-in Jamf Pro Signing Certificate(s)

So, we covered the built-in Jamf Pro CA, and discussed it’s main purpose: signing the ‘signing cert’ which signs the MDM profiles.

There are however other ‘signing certificates’ which are automatically generated by Jamf Pro:

As you can see there is a ‘signing certificate’ for macOS and another-one for iOS, as well as different ‘signing certificates’ for other pieces of the Jamf Pro functionality such as DEP, Education Support, JSON, Config Profiles, etc…

In view of remaining within the scope of this post (and hopefully finish writing this post before the Sun decides to raise above the horizon again or my 1 year old to decide that the night is over), I’ll not elaborate this further. I hope it’s safe to assume that their purpose is clear. If not, don’t hesitate to leave a comment down below.

Note: the FileVault2Comm 'signing cert' is used for the FileVault Recovery Key escrow functionality, but let's stay away from FileVault in this post or I will for sure see the Sun come up before the end of this post.

Jamf Pro Device Certificates

To allow communication between devices and Jamf Pro, the devices need to provide their identity for Jamf Pro to allow the communication. Just like Jamf Pro does with its Tomcat SSL certificate.

To do so, each devices is issued a ‘Device Identity Certificate‘, which is embedded into the MDM profile:

For iOS you’ll see this certificate on the MDM profile:

For macOS you’ll see this certificate on the MDM profile and in the System Keychain:

In Jamf Pro you’ll find these certificates when clicking on the numbers next to the built-in CA in the PKI Certificates settings:

If needed these certificates can be revoked:

Note: revoking these certificates in Jamf Pro, or deleting/corrupting them on the devices will BREAK all MDM communication with the device!

As said, the above certificates (Device Identity Certificates) are used for MDM communication only. However, on macOS we also have something call ‘the Jamf Binary’ which does everything else Jamf Pro has to offer on top of MDM (Policies, Patch Management, Inventory updates, …) . For this additional functionality, the Macs also need to proof their identity to Jamf Pro to allow the communication. Hence another ‘identity’ certificate is issued: ‘the device certificate’.

This certificate can be found in the Jamf.keychain (not the default System/Login Keychain) at:

/Library/Application Support/JAMF/JAMF.keychain

Similar to the ‘Device Identity Certificate’, the ‘device certificate’ can be found in the PKI settings of Jamf Pro, and revoking, deleting or corrupting this certificate on the device will cause the Jamf binary communication to BREAK (provided that certificate-based authentication is enabled in Jamf Pro Settings > Computer Management > Security > Enable certificate-based authentication):

IMPORTANT NOTE: both the 'device certificates' as the 'devices identity certificates' are valid for 5 years after enrolment. You might have come across discussions regarding issues with those certificates not being renewed automatically. Well, good news!

Jamf Pro 10.23 now allows to renew the 'device identity certificates' (and the MDM profile) via remote (mass) commands. Additionally, the 'device certificates' used for the Jamf Management Framework / Binary will also be automatically renewed.

APNS Certificate

Jamf Pro requires a valid push certificate to communicate with Apple Push Notification service (APNs). This communication is required to do the following:

  • Send macOS configuration profiles and macOS remote commands to computers.
  • Distribute Mac App Store apps to computers.
  • Enroll and manage iOS devices.

Although maybe the most important certificate of all, please allow me to consider this as being so mainstream and straight forward in view of managing Apple Devices via MDM, and allow me to limit further discussion at referring to the following documentation on the topic:

https://docs.jamf.com/jamf-pro/administrator-guide/Push_Certificates.html

https://support.apple.com/en-euro/guide/server/apde0e927ee/5.9/mac/10.15

There is however one other ‘push certificate’ which can be configured in Jamf Pro: the Push Proxy certificate.

The Jamf Push Proxy enables communication between the Jamf Pro server and devices with Jamf Self Service installed. This communication allows you to send Notification Center notifications to computers and mobile devices with Self Service installed. This certificate is automatically renewed.

https://docs.jamf.com/jamf-pro/administrator-guide/Jamf_Push_Proxy.html

Specific certificates for integrations like LDAPs, SCEP Proxy, SCCM, GSX…

Last but not least there are additional integrations which can be added to Jamf, which will require you to provide a specific certificate.

As those topics deserve a full post on their own, and in view of the imminent awakening of the 2 potential events mentioned earlier in this post, I’ll leave that for another day.

That’s it for now! As always, if you liked the post, hit the like button, tell your friends about it and leave a comment down below!

Brgds,
TTG

Print Friendly, PDF & Email