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.
- SSL Certificate for Tomcat
- The built-in Jamf Pro Certificate Authority
- The built-in Jamf Pro Signing Certificate(s)
- Jamf Pro Device Certificates
- APNS Certificate
- 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.keychainSimilar 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
Apple ecosystem enthusiast, geek, tech gadget freak, Belgian living in the Netherlands
Manager Technical Support | Jamf
Our FileVault2Comm is expiring soon. I can’t find a way to renew this cert. What do we ed need to do in order to renew it? renew the JSS Built-In CA which is still valid for another 5 years, I am lost here. Please help?
All certificate signed by the “CN=JSS Built-In Signing Certificate” should autorenew. But what is “soon”?
Soon, meaning in 3 days. I got Jamf Support saying same thing , that will autorenew. I will wait and cross my fingers then, hopefully everything is going to be fine.
Thanks for the article BTW. Not many info about this out there.
Should be fine indeed! Thanks for the feedback. I may have too add some info on renewal etc! Adding to todo list lol, now find a loop in the time dimension to generate more hours in a day ?
Excellent article man ! 🙂
Thank you 🙂
Hi TTG,
Have you already made a post for On prem environments ?
What are you looking for exactly? Because that’s a bit vague as topic.
Hi TTG,
Im trying to setup SCEP proxy in our On Prem environment . The Configuration profile itself isnt delivering . it goes to pending in Jamf . Is there way to check if Jamf is making communication with SCEP server ?
Yes, have a look at the IIS inetpub logs on the ndes server (I presume you are using Ms ndes?). And the Jamf Pro logs should tell you more as well. If needed additional SCEP debugging can be enabled on JPS, but if jamf cloud that requires a support ticket.
Ah but your Jamf Pro is on-prem, check the IIS logs first for comms from
jamf pro and the normal jamf pro logs. If Jamf Pro 10.28 … contact support as there has been a hotfix for some issue (needs confirmation in the logs).
Thanks for your suggestions . will try to check the IIS logs and see if I could find something .
What about renewing a 3rd party cert? Does jamf automatically send this out to clients to keep them talking to jamf?
We are testing a load balancer to forward traffic over to our jamf server. It has its own cert. When enrolling we needed to add this cert as anchor cert in prestage or the client could not enroll. This cert expires after 1 year. Does that mean will need to send out a config profile to clients with the renewed cert before its implemented on the load balancer?
I would strongly recommend a publicly trusted cert so that whatever cert you put on the load balancer never causes any issues even if renewed.
What cert are you using now? Signed by an internal, not publicly trusted CA?
Our “JSS Built-in Signing Certificate” is expiring in a few days. but our CA doesn’t expire for another 5 years. Jamf Support has been almost zero help on this and I can’t get a direct answer. is there anything I need to do or will this renew on its own. One Jamf support person told me to renew the CA but why would I have to do that if it doesn’t expire for another 5 years? any information would be helpful.
Renewing the CA will renew the signing certs indeed but may not be needed yet as the CA is still valid for 5 years.
If you do it, since 10.23, it will renew the MDM profiles for all your devices.
However, it depends which signing cert you are talking about exactly. Look at Jamf Pro settings -> PKi —> build in CA ->
All… and go the last page. You’ll probably see more recent signing certs.
I would check on a Device which has been enrolled a while ago and check the details of the signing cert on the MDM profile.
Then, go to the inventory record of that device and check the manangement command “renew MDM profile”.
Then check the mdm profile and signing cert again on the Mac. Both should have been renewed.
Next, you can also check “MDM profile” settings in jamf pro settings to see what is set for autorenewals.
This all fits into the fact that when the jamf pro CA was initially created, we did not have a renewal process in place for the ca and the signing certs it issues, but last year we had to do something in view of avoiding device to have to re-enroll due to expired CA.
Ok, New enrollments have non-expiring signing cert. but older enrollments have the signing cert expiring in a few days. but they both have the FileVault2Comm cert that is expiring in a few days.
My MDM Profiles Settings are set to renew:
When the built-in certificate authority is renewed
180 days before the MDM profile expires
So will I have to renew MDM on devices that have the expiring signing cert?
The FileVault2Comm cert should autorenew, but there is a PI for that. Just create a new profile, scope that to all devices and remove the old one. It’s only used for escrow, so flipping it to a new cert does not change anything and fixes the renewal manually.
For the MDM profile and signing cert, the MDM profile should renew automatically when it reaches 180 days prior to expiry.
I would also crosscheck the MDM expiry in the inventory of Jamf Pro for those devices.
To why it is not renewing automatically… I’m missing some details which support can check with you, but:
https://docs.jamf.com/technical-articles/Enrolled_Devices_Stop_Communicating_after_5_Years.html
So I don’t have any MDM profiles expiring only the the signing cert that signed my earlier enrollments. I think my plan will be to recreate profile so that get signed by the new signing cert, and on devices that go “unverified” renew the MDM profile.
oh and wait for my FileVault2Comm to expire then recreate the profile.
Yeah, and the “unverified” is purely cosmetic. Does not break anything.
Just recreate the filevault profile and renwe the MDM if needed or if you want to get rid of the unverified
Hi TTG, very clarifying post as always, much appreciated!
We have Jamf Pro on premise on a Windows Server. Since last week, computers are only allowed to recon/policy if connected to our VPN. When not using the vpn we get that ‘An SSL connection failure has occurred…’
Haven’t heard back yet from Jamf support team. My lack of infrastructure understanding is making me suspect from some network issue, why computers communicate in the internal network and not the external? The infra team already renews the Tomcat cert, which wasn’t expired btw, but still no luck.
Any suggestions?
Thanks!
Do an openssl show certs command to on the full jamf pro url and port to see what cert is being returned. I suspect a different routing and a reverse proxy or so in between?
Hey TTG
Thanks for the article! Again it contained a little bit more insight than I was able to find in official resources (Jamf Pro Documentation, Technical Articles).
Do you have any pointers where I could get more info (deep-dive) on the different kinds of certificates signed by the Jamf Pro Built-in CA?
For my current situation, my main takeaway is that expiring Device Certificates do not need to be handled manually and that I can ignore the ones listed under Settings > Global > PKI certificates > Jamf Pro Built-in CA > Expiring. Thanks for that!
Do you know whether there’s a need to manually act on expiring “Self Service iOS” certificates (also signed by the Jamf Pro Built-in CA)?
Thanks again
Best