For additional security we would like to avoid keeping generated certificates (their private keys) on our server after installing them on a device, but still be able to reference them in later installed configuration profiles via MDM. However, it seems that for a configuration profile's payload to use a certificate (e.g. VPN payload), the certificate payload must be present in the same profile.
Are we missing anything, perhaps it's already possible somehow?
Ideal workflow for us would be:
- our MDM server generates a certificate (private+public keys) for a given device
- our MDM server sends this certificate to the device as configuration profile and saves PayloadUUID of the certificate's payload
- our MDM server deletes the generated private key from its storage. At this point the private key is present only on the device.
- at some point in the future our MDM server sends a configuration profile that references the certificate from step 2 via the saved PayloadUUID (e.g. using key PayloadCertificateUUID in a VPN payload)
Current result: device responds to MDM server with error "The profile “VPN” could not be installed. Certificates needed for the VPN service “VPN” are invalid."
Desired result: device is able to find the previously installed certificate via its PayloadUUID. Alternatively, it could be certificate fingerprint or something similar.
One more alternative could be to replace steps 1-3 by an app on the device that obtains a certificate (in any way), installs it to device as a configuration profile, passes the certificate's PayloadUUID to our MDM server and then doing step 4.
For additional security we would like to avoid keeping generated certificates (their private keys) on our server after installing them on a device,
This is a very good goal for security. However it still involves the movement of private keys, which is inherently less secure than a system where the private key never moves. Apple devices offer support for ACME and SCEP. With those protocols the private key is generated on the device and never moves. In addition Apple's support for ACME includes support for hardware-bound keys, which offer very strong protections against exporting private keys. Considering your attention to the security of your architecture, I would strongly suggest adopting ACME instead of identities generated by your MDM server.
That aside, configuration profiles require that (in nearly all cases) when one payload references another payload, both payloads must be in the same configuration profile. That requirement applies to all identity types (PKCS12, ACME and SCEP).
Declarative Device Management does not have this requirement. Identities are assets, and configurations reference assets. Because configurations and assets are independent, configurations can be installed, updated or removed without affecting the assets, and vice-versa.
Currently not everything that is configurable using configuration profiles is configurable using Declarative Device Management. Apple is continuing to expand its capabilities. If it does not yet meet your needs, I suggest filing feedback with Apple to request additional support.