If you’re using a publicly trusted certificate with your JSS, you might have trouble with DEP enrollments failing with the ever so helpful error “Failed to contact Mobile Device Management server.” But is that really what’s happening here? The Mobile Device Management server is reachable (because of course that’s the first thing we check when we see this kind of error), so what’s causing this failure? The explanation is actually quite simple, but not very obvious.
First, a quick refresher on how certificates work. A certificate is signed by a certificate authority. Computers trust that a certificate is valid because they trust the authority that issued it. If a certificate doesn’t match a trusted authority, the computer won’t trust it unless otherwise explicitly told to do so.
Each JSS has its own certificate authority (referred to as the JSS Built-in Certificate Authority), and by default the certificate that Tomcat uses is issued by this authority. This works because at enrollment time computers and mobile devices have the JSS Built-in Certificate Authority added to their trust stores. When an HTTPS request is made to the JSS, the certificate matches the JSS Built-In Certificate Authority, so the computer knows that it’s taking to a legitimate server.
In some cases, a 3rd party publicly trusted certificate is used for Tomcat. Instead of being signed by the JSS Built-in Certificate Authority, the certificate is signed by a trusted 3rd party like Verisign. Even though this certificate was not signed by the JSS Built-in Certificate Authority, the computer will still trust this certificate because it was issued by an authority that it trusts.
In DEP however, things function a bit differently. When setting up your pre-stage enrollment, the JSS tries to be helpful and add your JSS Built-in Certificate Authority as an anchor certificate to the DEP payload. Unlike a typical HTTPS request where the certificate can be issued by any trusted authority, DEP requires that the certificate must be issued by the anchor certificate authority. When using a certificate issued by a 3rd party, there is a mismatch and the enrollment will fail.
Luckily, the fix is easy. When setting up your DEP pre-stage enrollment, make sure you remove the anchor certificate, as shown below.
Once you get rid of this anchor weighing down your pre-stage, your DEP enrollments will soar.
I’ve created a feature request on JAMF Nation to change this behavior.
Update: It appears that this only affects JSS environments where SSL is terminating at a load balancer. With a 3rd party certificate installed directly on the Tomcat server(s), the JSS correctly omits the Built-in Certificate Authority from the pre-stage enrollment.
Update 2: It appears that commenting out the HTTPS connecter in Tomcat’s server.xml will also yield the desired behavior of not having the JSS Built-in Certificate Authority inserted into new pre-stage enrollments.