How to migrate from a self-signed certificate to a public certificate

lisanelson2
New Contributor III

So we have been running the same JAMF instance for 9 years and 51 weeks, and it turns out that the JAMF CA itself has to be renewed after 10 years, so I've got a week to sort out the problem I'm about to describe.

My problem is, we are still using a self-signed certificate, so JAMF support has told me that if I renew the CA, all my clients will no longer trust it and will have to be reenrolled. But I already know, from experimenting on my test instance over the winter, that switching over to a publicly-signed certificate *also* drops all my clients.

As far as I can tell, there is no way to migrate from a self-signed certificate to a publicly-signed certificate without dropping all your clients. I have googled and I cannot find any documentation anywhere discussing any such process. My JAMF support case seems to be languishing with people scratching their heads.

Can anyone point me to steps for migrating to a public certificate without dropping all my clients?

(Live JAMF instance is still 10.38.3; we were going to upgrade it, but when I tested the upgrade process first on my test instance, that's when I encountered self-signed certificates having been deprecated and dropped all the clients on the test instance. So I have been waiting until when I would normally be reinstalling all the machines anyway, for the start of next academic year; that would be a perfect time to drop all my clients because I wouldn't care, as they all need reinstalling anyway. At the moment it seems like my choices are between having to reinstall all my clients now, rather pointlessly, with last year's configuration to get them through the next eight weeks or so, or allowing the JAMF instance to drop them all and let them run orphaned for the next eight weeks.)

Thanks,
Lisa.

1 ACCEPTED SOLUTION

Miguelwatson
New Contributor

@lisanelson2 wrote:

So we have been running the same JAMF instance for 9 years and 51 weeks, and it turns out that the JAMF CA itself has to be renewed after 10 years, so I've got a week to sort out the problem I'm about to describe.

My problem is, we are still using a self-signed certificate, so JAMF support has told me that if I renew the CA, all my clients will no longer trust it and will have to be reenrolled. But I already know, from experimenting on my test instance over the winter, that switching over to a publicly-signed certificate *also* drops all my clients.

As far as I can tell, there is no way to migrate from a self-signed certificate to a publicly-signed certificate without dropping all your clients. I have googled and I cannot find any documentation anywhere discussing any such process. My JAMF support case seems to be languishing with people scratching their heads.

Can anyone point me to steps for migrating to a public certificate without dropping all my clients?

(Live JAMF instance is still 10.38.3; we were going to upgrade it, but when I tested the upgrade process first on my test instance, that's when I encountered self-signed certificates having been deprecated and dropped all the clients on the test instance. So I have been waiting until when I would normally be reinstalling all the machines anyway, for the start of next academic year; that would be a perfect time to drop all my clients because I wouldn't care, as they all need reinstalling anyway. At the moment it seems like my choices are between having to reinstall all my clients now, rather pointlessly, with last year's configuration to get them through the next eight weeks or so, or allowing the JAMF instance to drop them all and let them run orphaned for the next eight weeks.)   MyAccountAccess

Thanks,
Lisa.


Migrating from a self-signed certificate to a publicly-signed certificate in JAMF can indeed be a challenging task. The process typically involves reenrolling all your clients, as the trust relationship with the certificate changes. However, there are some steps you can follow to minimize the impact and streamline the migration process. Here's a general outline of the steps you can take:

Communication: Inform your users in advance about the upcoming changes and the need for reenrollment. Provide clear instructions and a timeline for the migration.

Prepare the new certificate: Obtain a publicly-signed certificate from a trusted Certificate Authority (CA). Make sure the certificate is in the appropriate format for JAMF (e.g., PEM or PKCS12).

Set up a test environment: Create a separate test instance of JAMF to perform a trial migration. This allows you to identify and resolve any issues before applying the changes to your live instance.

Test the migration process: In the test environment, reenroll a few test devices using the new certificate. Ensure that the enrollment process works correctly and that the devices can communicate with the JAMF instance.

Determine reenrollment strategy: Evaluate your options for reenrolling devices. You can choose to manually reenroll each device, use an automated enrollment method (e.g., Apple DEP or user-initiated enrollment), or a combination of both. Consider the number of devices and your available resources when making this decision.

Plan for device reenrollment: Based on your chosen strategy, create a schedule and allocate resources for reenrolling devices. Communicate the schedule to users to minimize disruption.

Reenroll devices: Begin reenrolling devices, following the established schedule and enrollment method. Provide clear instructions to users on how to initiate the process.

Monitor progress: Keep track of the reenrollment progress and address any issues or questions that arise during the process.

Update JAMF settings: Once all devices have been reenrolled, update the JAMF settings to reflect the new certificate. This includes updating any references to the old certificate, such as URLs or server configurations.

Decommission the old certificate: Once you have successfully migrated all devices and updated the JAMF settings, you can safely decommission the old self-signed certificate.

It's important to note that the specific steps and considerations may vary depending on your JAMF version, infrastructure, and other factors.

 

 

 

View solution in original post

3 REPLIES 3

sdagley
Esteemed Contributor II

@lisanelson2 Since it seems like you're using an on-prem instance you might also consider standing up a new JSS instance that's starting off with a public cert and use https://github.com/jamf/ReEnroller to migrate machines from your old instance to it (if that can be done before your old cert expires). You can use https://github.com/jamf/JamfMigrator to move your configuration from your old instance to a new one.

Miguelwatson
New Contributor

@lisanelson2 wrote:

So we have been running the same JAMF instance for 9 years and 51 weeks, and it turns out that the JAMF CA itself has to be renewed after 10 years, so I've got a week to sort out the problem I'm about to describe.

My problem is, we are still using a self-signed certificate, so JAMF support has told me that if I renew the CA, all my clients will no longer trust it and will have to be reenrolled. But I already know, from experimenting on my test instance over the winter, that switching over to a publicly-signed certificate *also* drops all my clients.

As far as I can tell, there is no way to migrate from a self-signed certificate to a publicly-signed certificate without dropping all your clients. I have googled and I cannot find any documentation anywhere discussing any such process. My JAMF support case seems to be languishing with people scratching their heads.

Can anyone point me to steps for migrating to a public certificate without dropping all my clients?

(Live JAMF instance is still 10.38.3; we were going to upgrade it, but when I tested the upgrade process first on my test instance, that's when I encountered self-signed certificates having been deprecated and dropped all the clients on the test instance. So I have been waiting until when I would normally be reinstalling all the machines anyway, for the start of next academic year; that would be a perfect time to drop all my clients because I wouldn't care, as they all need reinstalling anyway. At the moment it seems like my choices are between having to reinstall all my clients now, rather pointlessly, with last year's configuration to get them through the next eight weeks or so, or allowing the JAMF instance to drop them all and let them run orphaned for the next eight weeks.)   MyAccountAccess

Thanks,
Lisa.


Migrating from a self-signed certificate to a publicly-signed certificate in JAMF can indeed be a challenging task. The process typically involves reenrolling all your clients, as the trust relationship with the certificate changes. However, there are some steps you can follow to minimize the impact and streamline the migration process. Here's a general outline of the steps you can take:

Communication: Inform your users in advance about the upcoming changes and the need for reenrollment. Provide clear instructions and a timeline for the migration.

Prepare the new certificate: Obtain a publicly-signed certificate from a trusted Certificate Authority (CA). Make sure the certificate is in the appropriate format for JAMF (e.g., PEM or PKCS12).

Set up a test environment: Create a separate test instance of JAMF to perform a trial migration. This allows you to identify and resolve any issues before applying the changes to your live instance.

Test the migration process: In the test environment, reenroll a few test devices using the new certificate. Ensure that the enrollment process works correctly and that the devices can communicate with the JAMF instance.

Determine reenrollment strategy: Evaluate your options for reenrolling devices. You can choose to manually reenroll each device, use an automated enrollment method (e.g., Apple DEP or user-initiated enrollment), or a combination of both. Consider the number of devices and your available resources when making this decision.

Plan for device reenrollment: Based on your chosen strategy, create a schedule and allocate resources for reenrolling devices. Communicate the schedule to users to minimize disruption.

Reenroll devices: Begin reenrolling devices, following the established schedule and enrollment method. Provide clear instructions to users on how to initiate the process.

Monitor progress: Keep track of the reenrollment progress and address any issues or questions that arise during the process.

Update JAMF settings: Once all devices have been reenrolled, update the JAMF settings to reflect the new certificate. This includes updating any references to the old certificate, such as URLs or server configurations.

Decommission the old certificate: Once you have successfully migrated all devices and updated the JAMF settings, you can safely decommission the old self-signed certificate.

It's important to note that the specific steps and considerations may vary depending on your JAMF version, infrastructure, and other factors.

 

 

 

Well. I think that pretty conclusively demonstrates that there is, in fact, no straightforward way to just switch over to a public certificate. Which, really, is what I needed to know.

In the end I crossed my fingers and renewed the CA; there were some shenanigans, but in the end most stations have in fact picked it up, so catastrophe has been averted.

Thanks for taking the time to make clear what we would need to do to switch over to a public certificate. That'll be an exercise for September.

Thanks,
Lisa.