dherder
commented
3 months ago @zwass Having an API endpoint for delivering a signed enrollment profile for the use case of custom web views during enrollment is another use case for this FR. It would be great if this endpoint returned a signed enrollment profile. This is also a requirement for prospect-rosner
For additional context please see:
https://github.com/fleetdm/fleet/issues/18391 - Create signing tool for customer-preston https://github.com/fleetdm/fleet/issues/10418 - Sign macOS enrollment and configuration profiles
@marko-lisica summary of this issue per a meeting with the customer 20240418 -
Currently customer is:
The customer would like to also sign the profile so it appears as verified on-device.
Initially the customer wanted to do this on their own but they didn't succeed in generating a trusted certificate signing workflow. What is required is signing profiles with certs in a trust chain tied to top-level pre-installed System Root certs that validate on-device certs delivered via MDM as trusted / verified.
@roperzh has created a workflow for creating trusted profiles so the customer can build a signing feature on their side for the enrollment profile, but, they would PREFER a new API endpoint where Fleet can ingest a custom profile (with a user's email address added by the customer's enrollment workflow) that will output a signed profile that is validated as trusted / verified on-device.
A problem I forsee with this approach is that in my opinion this API endpoint should not be public if we are returning a signed entity from it. It seems like it should be secured with a token or some kind of authentication to securely identify the requestor.
Problem
The customer's preferred solution for automating their enrollment workflow has not been implemented.
Potential solutions