We are receiving a "Tomcat SSL Certificate Expiring in 20 days" warning.
Apparently, we are using the built-in Certificate authority but since we updated this a long time ago, we aren't sure what to do.
Do we need to choose the first option, since we don't want our clients to lose their connection?
And if so, how and where do we obtain (download) this SSL Certificate Keystore for uploading into the JSS?
Your help is appreciated.
Creating or Uploading an SSL Certificate Log in to Jamf Pro. In the top-right corner of the page, click Settings Click System Settings. Click Apache Tomcat Settings Click Edit. Select Change the SSL certificate used for HTTPS and click Next. Follow the onscreen instructions to upload or create an SSL certificate. Restart Tomcat for the changes to take effect. For instructions on how to restart Tomcat, see the following Knowledge Base article: Starting and Stopping Tomcat
hope this helps
You can just generate a built in certificate from the jamf pro's built in CA (the second option) in your second screenshot, but that's not really advised anymore. Mobile devices won't trust your Jamf server by default, and any modern browser will throw warnings when you try to navigate to your jamf server.
I'd strongly advise following the links @Hugonaut posted, and moving to a 3rd party SSL cert. It's a little scary to do, but if you contact Jamf support they have a 3rd party utility called Simple SSL along with documentation on how to use that. It makes generating and importing the SSL cert really easy. In the long run, the move is well worth it, so I'd suggest taking the time to do this.
@DeployAdam If the built-in certificate is what has been used in the past and that is what exists on the already enrolled device, go ahead and renew that one.
To regenerate the tomcat certificates for "Built-in Certificate Authority" ONLY.
Let's go to Jamf Pro Settings > Apache Tomcat Settings: 1. Click Edit 2. Check "Change the SSL Certificate for HTTPS" and click Next 3. Check "Generate a certificate from the JSS's built-in CA and click Next 4. Click Done
Now we have to restart Tomcat: https://www.jamf.com/jamf-nation/articles/117/starting-and-stopping-tomcat
NOTE: What @float0n mentioned above is correct that Jamf recommends using a 3rd party/globally trusted SSL certificate vs the built in if possible.
Thank you all for your response
@ryan will the trust on the iMac clients automatically update themselves without a user accepting them? We have something like 2500 clients which need to keep working ;)
@blackholemac will change this in the near future
@Felipe.hernandez will migrate away from OS X Server for jamf Pro to a Linux environment, then we certainly will move away from the build-in CA
To all, still not bold enough to press the renew button...
will the trust on the iMac clients automatically update themselves without a user accepting them? We have something like 2500 clients which need to keep working
@DeployAdam I can understand the fear involved.
I’ve actually been in your boat and the switch to a third party cert went off without a hitch.
Basically what you are doing is replacing the Tomcat cert on the server. Certs do expire at some point even if you are on a third party one.
I’m assuming you are on self signed now. As long as you are providing a cert that is fully trusted by your server and clients, it doesn’t matter which cert it is the trust will be there.
That is why you would choose a third party signed one that Tomcat and clients both trust. You are just adding an additional new unexpired cert to your existing key store.
You get to decide but you should be fine going third party signed. If you want to confirm, call jamf but you should be good.
I'm in the same boat now and in the middle of device roll out.
If I want to proceed as is for now, can I select option 2: "Generate a certificate from the Jamf Pro's built-in CA" and address this properly when I have some downtime?
We have an SSL through DigiCert that we are having issues renewing because of IP re-routing issue and new "SSL Police" rules.
We have a domain consolidation that we had to work with when we rebuilt our server and made sure we did not have to re-enroll all f our devices.
We are kinda stuck