certificate trust failure for iOS DEP enrolment via Apple Configurator 2?

certificate trust failure for iOS DEP enrolment via Apple Configurator 2?

Before I describe the issue I'm seeing, I'll mention that this doesn't feel like a problem within Soti but instead a problem with the information being returned to the iPad from Apple's Device Enrolment Program.

I am attempting to use Apple Configurator 2 to enrol an iPad into our self-hosted Soti instance via the Device Enrolment Program.  I was able to configure this correctly earlier this year but am now seeing a problem when the device attempts to be managed by the MDM.

Our server configuration is hosted in our data center and looks like:

  • one management server (MS) that is internal access only
  • two deployment servers (DS1, DS2) that are public-facing; DS1 and DS2 are placeholders for the real FQDNs

I've completed the configuration in MS:

  • set up APNS
  • set up Apple Device Enrolment Program
  • set up Add Devices rule for iOS devices

I've completed the configuration in Apple Configurator 2:

  • Organization
  • Server
    • using URL of https://DS1 for URL
    • trust certificate automatically set up for MobiControl Root CA
    • manually added certificates for DigiCert Global Root G2 and GeoTrust TLS RSA CA C1

When I prepare the device, I use the following values:

  • prepare with Manual Configuration
    • Add to Device Enrollment Program
    • Supervise devices (checked and greyed out)
      • Allow devices to pair with other computers
    • Enable Shared iPad
  • the server that I configured earlier
  • the organization that I configured earlier
  • the defaults for Setup Assistant (MDM will control later)
  • a valid WiFi profile

There is no problem with the preparation of the device.  It appears in Apple Business Manager and I can assign it to our Soti server.  In Soti, I can sync the DEP devices and the device is properly assigned to my Add Devices rule.

However, I am running into a problem when I complete setup on the devices.  After sending a WiFi profile to the device, I can select language and country and the device then correctly shows the Remote Management screen.  When I proceed with the enrolment, I see an error on the device indicating that the action was 'cancelled'.

When I look in Console to see activity on the device, I see two things that look incorrect:

  • the SSL negotiation fails with the message "Handle challenge, trust evaluation failed: “DigiCert Global Root G2” certificate is not trusted"
  • the logged URL points to DS2 instead of DS1 from my server profile.  the URL looks like https://DS2/mc/dep/none/enroll

I had recently set up a server in Apple Configurator 2 for DS2 and did not include the trust certificates in its configuration.  This makes me wonder if something in the Apple infrastructure is caching the incorrect information and sending it to the device during its setup.

Of interest, I have set up a trial account with SimpleMDM and have been able to successfully enrol the device there.

I have also done the following to try to correct this problem:

  • removed all profiles and uninstalled/reinstalled Apple Configurator 2
  • removed the MDM server from Apple Business Manager and recreated it
  • updated the Apple Device Enrolment Program information in Soti
  • deleted and created a new Add Devices rule in Soti
  • attempted to enrol a second device
  • used the complete enrolment URL in the server configuration - e.g. https://DS1/Enrol/223

Any ideas about why my Soti enrolment is failing? 

8 Answers

Order By:   Standard | Newest | Votes
Adil Katchi | posted this 05 May 2020

Hi Steve,


Out of curiosity, why do you think that having the logged URL pointing to DS2 instead of DS1 would cause an issue?  Is your DS2 not configured to manage iOS devices?


I have played around with Apple Configurator in the past and have never understood the purpose of specifying the "Server" when you are enrolling using Apple Device Enrollment Program.  The device gets the profile from Apple, which contains all the necessary information to allow the device to enroll.  So, I do not believe the issue is related to your Server configuration.


I did notice that you checked the "Enable Shared iPad".  MobiControl doesn't support Shared iPad.  Have you tried unchecking that option to see if it helps?

  • 0
  • 0
Steve Gamble | posted this 05 May 2020

Hi Adil,

Thanks for the suggestions.

I have tried with Shared iPad both set and not set but that didn't affect things.

DS1 and DS2 are set up the same and are intended to be clustered.  We have 40k Android devices using these nodes, though that doesn't preclude there being a difference for iOS.  I would expect that using DS2 would be fine, though I am very confused as to why the device is trying to access that URL instead of the DS1 address that I specified in Apple Configurator.

The fact that the URL is wrong and that the certificate isn't trusted despite it being explicitly added to the list of trusted certs leads to be believe that the device isn't receiving the correct information.

Like you, I don't understand the exact role that the server plays in the Apple Configurator step.  My best guess is that something like the following is occurring:

  • Apple Configurator 2 associates the organization with the device, which allows it to show up in the correct account in Apple Business Manager
  • Apple Configurator 2 associates the server with the device, which is stored with the device information in Apple Business Manager
  • when the device starts setup, it contacts the Apple DEP infrastructure to determine if it is managed.  this infrastructure returns the server information set by Apple Configurator 2: the server URL + trusted certificates + plus some other metadata
  • the binding of Soti with the MDM server in Apple Business Manager is only used to allow Soti to interact with the list of devices that are assigned in Apple Business Manager; this is required to allow Soti to discover which devices it can manage through DEP

It is the third point above where I think things are failing on me.  It feels like the device is receiving old information.

I suppose one reason why the server url is needed in Apple Configurator is that the deployment server address may be different that what the management server knows about.  Because of mapping at our firewall, the external address and internal address of our deployment servers differ.

I am in the process of re-starting our test Soti environment so I will have a second instance to test this out on.  We have made this work in the past so I am struggling to understand what is different now.


  • 0
  • 0
Raymond Chan | posted this 05 May 2020

A multi-DS HA MobiControl implementation for iOS device platform should have all DS's behind a load-balancer, and only one FQDN for the whole HA system.   Also, such system should have only one "server" entry in your DEP account on ABM portal.


Apple Configurator 2 is only needed to add non-DEP devices to the virtual "Apple Configurator 2" group in your DEP account.   Once a device has been successfully added, it can be re-assigned to any real MDM server of any brand (added before or after the addition of the device of interest) on your ABM portal.  So your discussion topic linking "Apple Configurator 2" to "Enrollment" is fundamentally wrong and misleading.


The above of course assumed that the different aspects of each MobiControl DS in the HA system are properly installed/configured.    Please consult with Soti support team directly before you start with an HA system.  That will likely save you much time and effort.

  • 0
  • 0
Adil Katchi | posted this 05 May 2020

Hi Steve,

As Raymond suggested, the normal setup for a multi-server environment requires the use of a Load Balancer in order to optimize the use of your MobiControl servers. However, if you’re okay with all your iOS devices being managed by one server, it is possible to set up the environment without a load balancer.

The DEP profile (that contains the server and trusted certificate info) that gets pushed from Apple Business Manager to your device is actually created by MobiControl. The reason that your device is communicating with DS2 is because your MobiControl Administration Utility has set the Device Management Address to DS2. You can only have one Device Management Address, which is the reason why a load balancer is normally used to allow your iOS devices to be managed by all your servers. The same Device Management Address is used to create the enrollment URL for all your Add Device Rules.

Have you or anyone else changed the Device Management Address recently?

  • 0
  • 0
Steve Gamble | posted this 06 May 2020

The above of course assumed that the different aspects of each MobiControl DS in the HA system are properly installed/configured.    Please consult with Soti support team directly before you start with an HA system.  That will likely save you much time and effort.

Interesting.  I will need to discuss this with our data center team.  We did the initial set up of this system with Soti Professional Services and have not experienced any difficulties with our 40k Android devices.  Those devices have an mcsetup.ini file that lists both deployment servers, which may explain why it is working correctly.

So your discussion topic linking "Apple Configurator 2" to "Enrollment" is fundamentally wrong and misleading.

Are there any publicly available resources from Apple that explain the interaction between Apple Configurator 2, ABM/DEP, and the MDM?  My intent was not to mislead as I prefaced my comments with "my best guess".

Have you or anyone else changed the Device Management Address recently?

I don't think there will have been any configuration changes to our system since the last upgrade over a year ago.  The system is stable so there hasn't been any reason to make changes.  I will double-check though.


  • 0
  • 0
Steve Gamble | posted this 08 May 2020

We have our test MDM instance running and I am experiencing the same certificate trust issue with it when the device attempts to create the SSL connection to the enrollment URL. 

So far, I have results from 3 MDM servers:

  • our production Soti instance
    • MobiControl Root CA + DigiCert Global Root G2 + GeoTrust TLS RSA CA G1 certs
    • console logs shows 'Handle challenge, trust evaluation failed: “DigiCert Global Root G2” certificate is not trusted'
  • our test Soti instance
    • MobiControl Root CA + DigiCert Global Root CA + DigiCert SHA2 Secure Server CA certs
    • console logs shows 'Handle challenge, trust evaluation failed: “DigiCert Global Root CA” certificate is not trusted' 
  • SimpleMDM
    • *.simplemdm.com + Amazon + Amazon Root CA 1 verts
    • device can successfully enrol in MDM

For the two Soti instances, only the MobiControl Root CA is automatically added when setting up the Server in Apple Configurator 2.  I needed manually add the others by exporting the certificate information from the Chrome.

For the SimpleMDM instance, all three certs were automatically added when I created the server.

The SSL connection setup on the device is failing for URLs like https://DS1/mc/dep/none/enroll.  I have verified that the certificates listed above are the ones returned from the server.

I've also tried server configurations with just the MobiControl Root CA and also with no Trust Certificates and am getting the same result.  Oddly, we were able to get co-workers device to register once today after failing with the same trust error on the same server and on the other Soti server.

The other things that have changed in our environment is that my device is running iPadOS 13.4.1 instead of 13.3.1 and our version of Apple Configurator 2 changed from 2.11.1 to 2.12.1.

I am pretty well out of ideas.  Anything else I could be looking at to help?


  • 0
  • 0
Raymond Chan | posted this 10 May 2020

What is the current version and build numbers of your MobiControl server?


Has it been upgraded since the initial implementation via Soti Professional Services?  If so, what were the previous version and build(s) and your upgrade path taken?    Was the upgrade done by Soti support/professional service team? Or by you or your colleagues?


Was the initial implementation by Soti professional team a single server system?   Did you try to make an HA system yourself or by Soti support/professional service team?


Did you manage any iOS12 or earlier apple devices on your server?  Were they supervised and/or DEP devices?  Are there any iOS13+ device enrolled now? And have you been able to successfully enrol and fully control any iOS13+ devices to your DS1 in the past?   


I am not from Soti.  However, if I have a production MDM system with over 40K+ devices enrolled and large-scale reenrollments/device recalls cannot be tolerated,  I would not casually play with the system myself and perform any server version or architecture upgrades if I don't have the knowhow and experirence.  Don't think that taking snapshots/backup after every step is 100% safe and you can always fallback.  Sometimes, thngs done in the wrong order will render your enrolled device out-of-control forever, unless you recall or even re-enrol such device(s).  I guess no one on this forum has gone into your system to closely look into your server and device details,  I suggest you not to 100% trust what you hear from anyone (including me) on this forum. and take suggested action casually right away.  The answer/suggestion(s) given may not work because you have described something wrongly or missed out some crucial details, or there may be some mis-interpretations from your descriptions.   If Soti Professional/support team perform the changes for you, they have to fix it for you if they break anything.

  • 0
  • 0
Steve Gamble | posted this 11 May 2020

I appear to have solved the enrolment problem by adding the root certificate for our server's SSL certificate into the list of Trust Certificates in MobiControl Administration Tool.  To do this, go to the Certificates tab in that tool, click Import, read the warnings, and then select the root cert from the provided list.

We did not need to complete this step when we successfully enrolled iOS 13 devices in February and we are running the same server software as before.

A little background for our set up:

  • we are running 14.2.1
  • we upgraded from 13.4 in Sept 2018
  • the original installation was 13.1 or 13.2 from late 2016
  • all installations and upgrades were performed by Soti Professional Services; this includes our current HA configuration

This is our first foray into managing iOS devices so we have not managed iOS12 devices.  The test devices were purchased from the Apple Store with iPadOS 13 and we are using Apple Configurator 2 to add them to DEP.

Also of interest, although the enrolment URL was for DS2, I can see that the devices are connecting to both DS1 and DS2.

  • 1
  • 0

Give us your feedback
Give us your feedback