Question about DEP and internal certificates

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

Hi.

The server use a self signed cert

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.

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...

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

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.

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 :-(

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?

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.... :-(

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?

@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.

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.

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...