fleetdm
BYOD iOS/iPadOS enrollment profile is signed but unverified
Fleet version: 4.57.0
Web browser and operating system:
💥 Actual behavior
The MDM enrollment profile that gets downloaded from https://<fleet-server-url/enroll?enroll_secret=<enroll_secret> is signed with that server's SCEP certificate. However, since the host isn't enrolled yet, the certificate does not come from a trusted CA. That causes the profile to appear as Unverified during enrollment.
🧑💻 Steps to reproduce
- In Fleet, navigate to Hosts > Add hosts > iOS & iPadOS. Copy the enrollment link, paste it in your browser, and download it.
- Inspect the enrollment profile in a text editor. Observe that the downloaded profile is signed.
- Double click the profile and navigate to System Settings to install it. The profile will appear as
Unverified, despite it being signed.
🕯️ More info (optional)
After a time-boxed investigation I found a couple of things.
You could install the CA root certificate on the device beforehand, in which case it will show up as validated.
There's real no clear way to provide Verified certificates without that step. Certificate authorities are not interested in handing out intermediate certificates, and even if some do, they don't advertise it online.
Hey @marko-lisica just a heads up that this bug was passed to you. Is this a bug?
We assigned this one to me during standup. I think this is expected behavior.
We also have a feature request to Bring your own configuration profile signing certificate.
Other MDMs do the same thing. It's unverified until user add 3rd party certificate that's trusted by Apple by default.
@noahtalerman Should we close this one?
cc @ddribeiro
@marko-lisica I think we can still make improvements to this workflow. Other MDMs have the end user download a profile containing the CA certificate before they download the enrollment profile so it doesn't show up as unverified. Is there any benefit to us signing the profile if it still ends up showing up as unverified?
I think it's a subpar experience for the end user to enroll their host in Fleet and see "Unverified" in red text when they install the profile.
Is there any benefit to us signing the profile if it still ends up showing up as unverified?
@ddribeiro The benefit is that profiles become verified after user enrolls to MDM, because we deliver configuration profile that sets Fleet's SCEP certificate as root CA. See this issue for more info.
I think we can still make improvements to this workflow. Other MDMs have the end user download a profile containing the CA certificate before they download the enrollment profile so it doesn't show up as unverified.
I agree that this can be improved, but I think it should be a feature request.
I'm wondering what kind of profile they send to the user? Can user install configuration profile if it's not enrolled to MDM?
I think better solution would be to add 3rd party certificate that's trusted by Apple, so users don't need to do anything prior to enrollment.
@ddribeiro what does this look like in Jamf? Does their enrollment profile show "Unverified"?
I think better solution would be to add 3rd party certificate that's trusted by Apple, so users don't need to do anything prior to enrollment.
@marko-lisica yes, I agree with this 100%
what does this look like in Jamf? Does their enrollment profile show "Unverified"?
@noahtalerman, Jamf's enrollment flow is they have a user download and install a configuration profile with the CA certificate first, then download and install the MDM enrollment profile. Since the CA certificate exists on the host when the enrollment profile is installed, it doesn't show as "Unverified." If the profile with the CA certificate isn't installed on the host when the enrollment profile is installed, it will appear as "Unverified" but Jamf has guardrails in place to try to keep the end user on the happy path.
Hey @ddribeiro, after looking back at the comments in the original issue where we implemented signing of configuration profile, this is expected.
We confirmed that Jamf also shows “Unverified” when the end user downloads and opens an enrollment profile.
If you think we should consider prioritizing an improvement to include an option for an end user to download a certificate in the manual enrollment flow please file a feature request for this.
Just my 2 cents, I prefer the way we handle it currently as its fewer steps for the end user. An end user is either:
- downloading a configuration profile with a certificate that they have to manually trust, then downloading an enrollment profile that shows as Verified (two-steps)
- downloading an unverified enrollment profile that gets trusted after enrollment once the CA cert is delivered via MDM (one-step)
The only way to make this cleaner would be having the enrollment profiles signed by a third-party verified CA that already has a certificate on the device (not something we should do but something the customer could configure).
Thanks @allenhouchins!
In believe the "one-step" approach is good enough. However, we might want to improve the copy on our enrollment page to better set expectations for the end user. @noahtalerman, what are your thoughts?
If we want any of the additional features such as "two-step" enrollment where the user needs to install cert before the profile, or option to upload 3rd party globally trusted cert, we should file a feature request.
@ddribeiro with that in mind, I'm closing this issue.
Unverified, yet Signed in trust, the profile Seeks a safe cloud home.
