Question about DEP and internal certificates

glpi-ios
Contributor III

Hi everybody,

I would like to have your opinion, and help if you can, about DEP issue I have.

I can't use DEP for now.
it never worked and nobody seems to find a solution.

My computers are register in DEP and everything is configured on Jamf (PreStage Enrollments).
When I prepare a computer, DEP seems to be ok but enrollment is not done.

For enrollment to occur, our computers must have internal certificates (root and intermediate).
The problem is that as long as we do not install these certificates, communication with JSS will not happen and therefore by possible enrollment.

If you have to install the certificates manually, the interest of the DEP disappears.

In addition, the settings of "PreStage Enrollments" are not done (creation of an admin account for example).

If you know a solution, I take it with pleasure :-)

13 REPLIES 13

easyedc
Valued Contributor II

So question - Does your server use a self signed cert, or is it issued by a trusted authority?

glpi-ios
Contributor III

Hi.

The server use a self signed cert

easyedc
Valued Contributor II

What's your DEP configuration? There's a number of posts around The Certificates payload and an Anchor Certificate. Do you have that configured? A number of posts indicated that having that payload causes issues, removing it fixes things. f14bf15c9b80483896a727fcf29a5890

glpi-ios
Contributor III

If I let empty, I have a message "Failed to contact Mobile Device Management server".

When I put my internal root and intermediate certificates, it's ok.

But I have to create manually the first admin account and then no enrollment...

myronjoffe
Contributor III

@glpi-ios Remove all payloads within the pre-stage bar the certificates and see if anything changes...

ryan_ball
Valued Contributor

If you use a self signed cert on the server, and you have no load balancer with a third-party cert, you need your jss cert in there.

Try to create a brand new prestage, it will have your self signed cert in the certificates section by default. Then scope a device to that prestage, COMPLETELY WIPE THE DEVICE, then try to enroll it. If you take a device and attempt to enroll it, and make a change to the cert in prestage, you have to wipe the device in order for that change to take effect.

glpi-ios
Contributor III

Thanks for your help.

So, I wiped the device.
I deleted and created a new prestage.
I uploaded my certificates (root and intermediate) in certificates payload.

When the system is installed and at first boot, the DEP connection is fine.
I don't have wizard assistant windows, it asks me to create a local account and then ... nothing.

No enrollment.
I wait 30mn, I reboot multiple times but nothing...

If I force enrollment with a "sudo profiles renew -type enrollment", I have the profile preference pane open with the message "Allow device enrollment?"

Sincerely, Apple does not make life easier with DEP :-(

ryan_ball
Valued Contributor

How do you know that it did not enroll? Can you check a policy that is run at enrollmentComplete and see if the device ran the policy? I believe on 13.4 or after you might have to "approve" the mdm profile in some circumstances but that should not impact the device in such a way where it looks like it is not enrolled.

Do you have a /var/log/jamf.log on the device at all?

glpi-ios
Contributor III

I don't have /var/log/jamf.log
I don't have Profile Pane in Preferences System

And yes, I have a policy configured with enrollment trigger but the policy never run.... :-(

alexjdale
Valued Contributor III

I'm running into something similar and am pretty confused here.

I'm using an SSL cert issued by our internal PKI. No matter what I put in the Certificates payload of the pre-stage (no certs, our root, or our root and intermediate), the enrollment fails during setup. It either says it cannot reach the MDM server or that there was a problem downloading the automatic settings.

When I bypass DEP during setup and run "profiles renew -type enrollment" it gives me the error about the certificate chain not being correct. If I manually add our root and intermediate certs to the keychain and trust them and try the profiles command again, it works.

Am I just banging my head against the wall because of a Jamf PI? I can't use the certificates payload, but can't do this without it?

djrich29
New Contributor III

@alexjdale, I had the same questions that you have about a week ago since i also use an internal ssl cert and was getting nowhere with DEP and the certificates payload, i kept getting "unable to contact the scep server" error when doing DEP, I opened a support ticket with JAMF and also talked to a few admins at the jamfnation slack channel and they pretty much confirmed that internal certs do not work/ not supported by Apple DEP, JAMF's support recommendation was to get a publicly trusted cert or possibly use the jamf built-in cert to avoid any issues. I'm in the process of moving our JAMF server to a public cert now that i know this information.

alexjdale
Valued Contributor III

Yeah, I can't get the self-signed to work either, I'm going to get a third-party cert to move forward on this. It's one of those areas where they really need better documentation to reflect the reality of the situation, I think.

support-mg
New Contributor II

can I like @alexjdale comment here more than once? =P Things are changing so fast in the security models for MacOS and documentation isn't adequate for the real-life reality of a number of the features. Knowing how Apple likes to roll out changes and document them a year later I expect a lot of the pain originates there. Gratefully we've found simple success with he built-in JAMF signing cert and yet, I just had a machine enrolled via dep. Load the policies. Then the NEXT DAY - the machine isn't taking changes. The cert was 'unverified' - re-enrolled to download the cert again and it's been fine since. WTF. Anyhow - upvote for documenting the REALITY and not the Theory so much. Admining to theory makes for some really wonky and unexpected experiences that I'd be OK with if I knew to expect them. Time is just too short to chase stuff the little wonky stuff we can work around though support channels... Though I've seen it working, the practical reality of "one click and done" feels a long way away...