Skip to main content

Hello all. Has anyone had experience in setting up a JSS with a partial hostname, (server.name) with DHCP providing the search domain, so that a client acquiring a DHCP address has company.com in its search domain and requests for server.name correctly complete to server.name.company.com?



I find that 10.11.5 respects this configuration for everything except DEP. I have more testing to do, but it seems like the ManagedClient process on a newly set up mac refuses to trust an MDM server with a partial hostname, even though the OS should be 'completing' the hostname with the search domain set by DHCP.



Debug log from the ManagedClient process below;



Device Enrollment server connection returning error = 500 (The MDM server for your organization returned an unexpected status (500).)
Jun 28 18:39:39[268:0]:+MIG_CloudConfiguration mcxUsr_cloudconfiguration returned error: 500 (The MDM server for your organization returned an unexpected status (500).) domain = CPProfileManager


Relatedly, I had tested reconfiguring the JSS to use the FQDN and regenerating the Tomcat SSL cert. For good measure I also redid the DEP token exchange.
DEP does not like this change either but for a different reason. It seems that if your JSS URL doesn't match the hostname set in the JSS's internal CA that the device will not accept SSL trust chain up to the CA.



Jun 28 18:16:23[307:0]:* Device Enrollment server connection returning error = -218 (The server certificate chain for your organization’s MDM server was not properly set up.)
Jun 28 18:16:232267:0]:+MIG_CloudConfiguration mcxUsr_cloudconfiguration returned error: -218 (The server certificate chain for your organization’s MDM server was not properly set up.) domain = CPProfileManager


It looks like even though you change the JSS URL and regenerate the Tomcat SSL cert, this does not create a new public key. Inspecting the public key both before and after shows the same 'shortened' hostname I used originally. I had seen that before in another installation but saw no problems because we were enrolling clients with a quickadd package. I'm going to try just recreating a new DB and setting the URL up properly from the start to see if there's a change, but thought I'd write in this morning to see if anyone had gone down the same path already.

Long story short, rebuilt the DB from scratch with a fully qualified hostname and this particular issue has gone away.

@psliequ Gald you got it sorted.



FWIW, I imagine DEP was only ever intended with a FQDN.



There was a RFC for Certs that means certs signed by an external CA cannot use local names & always FQDN.



So, as DEP contacts Apple.. It'll probably adhere to that standard.

I believe we are running into this issue. Simple question @psliequ : How do I inspect the public key to verify it has an incorrect domain name?

You can use Certificate Assistant in Keychain Access. @asims9 If you can, post back your findings. It'd be interesting to see another variation on the problem.

@psliequ When going through certificate assistant, I do get a hostname mismatch error when checking against FQDN. Not sure how to see what hostname the public key is pointing towards though to verify its just the shortname.

@asims9 What do you see under the CRL Distribution Point Extension? There should be a URI there with the wrong hostname if you're seeing the same thing that I was.

@psliequ I do indeed see the incorrect hostname, but not the shortened of our JSS URL. Looks like our public key is pointing towards an internal only server and not the FQDN of our externally available server. Sorry I wasn't able to verify your experience, but thank you so much for helping me find ours!



So at this point to get a correct public key to allow proper DEP enrollment in our environment I need to rebuild the database? Does this mean a complete rebuild of our current JSS server? Would it be easier to just spin up another JSS instance and enroll all current machines in new JSS by sending quickadd via policy?

When you have multiple JSS web apps, just keep in mind that the master web app will be the one interfacing with Apple's services (DEP, VPP, APNS.) That said you also have to make sure that DNS resolves either web app to the same hostname. Without knowing much about your situation I'd say keeping the current web apps in place, squaring away their DNS, and just creating a new database might be the most efficient.

Terms & ConditionsCookie settings