Managing Trust Settings for Enterprise Root CAs on macOS via MDM

Question

Created 6d

Replies 3

Boosts 1

Participants 3

This post is from the WWDC26 Business & Education Q&A.

Enterprise security products often need to establish trust for a locally generated root CA in order to implement features such as web filtering, traffic inspection, data loss prevention, or compliance controls.

Our solution generates a unique CA certificate and private key on each managed Mac. The application then issues leaf certificates as needed and signs them with the device-specific CA. Using a unique CA per device helps avoid the security risks associated with deploying a shared CA private key across all managed endpoints.

However, since macOS Big Sur, modifying trust settings for certificates in the System keychain (for example, setting a root CA to Always Trust) requires user interaction and administrator authorization. Even privileged processes cannot silently establish trust for a newly installed root CA. This creates deployment challenges in enterprise environments, particularly when:

End users do not have administrator privileges.
The CA must be unique per device.
The private key must remain accessible to the security application while being protected from other applications.

We have considered several approaches, but each appears to have significant limitations:

Shared CA across all devices: introduces risk because compromise of the private key affects the entire fleet.
Per-device PKCS#12 deployment with private key accessible: other local processes may be able to use the key.
Per-device PKCS#12 deployment with private key protected: application access may require additional user approval, reducing deployment automation.

Questions:

Is there an MDM-supported mechanism for establishing trust for a device-specific root CA without requiring local administrator interaction?
Are there recommended enterprise deployment patterns for applications that need both: a device-specific CA private key, and trusted root status for the corresponding CA certificate?
Are there plans to expand MDM capabilities related to certificate trust management or keychain trust settings for managed Macs?
What is Apple's recommended approach for enterprise security products that need to deploy device-specific trusted CAs while maintaining strong protection of the associated private keys?

Answered by Device Management Engineer in 891424022

You want your solution to generate a CA and protect the private key, and have the Mac trust the CA.

If the device is not managed, trusting the CA requires user interaction and administrator authorization as you point out. This requirement is not likely to change because it is critical for security.

If the device is managed, the MDM server can install and trust the certificate silently. I can imagine a couple different architectures where this would work. I think in practice this may be difficult for your use case because this would require some custom integration between your solution and the MDM server. Does your solution involve managing the devices? Do you have a device management service partner? If so, I can describe some options.

Either way, I suggest filing feedback describing your solution and the problem you're running into.

Answer 1

Device Management Engineer OP

Apple

6d

Recommended

You want your solution to generate a CA and protect the private key, and have the Mac trust the CA.

If the device is not managed, trusting the CA requires user interaction and administrator authorization as you point out. This requirement is not likely to change because it is critical for security.

If the device is managed, the MDM server can install and trust the certificate silently. I can imagine a couple different architectures where this would work. I think in practice this may be difficult for your use case because this would require some custom integration between your solution and the MDM server. Does your solution involve managing the devices? Do you have a device management service partner? If so, I can describe some options.

Either way, I suggest filing feedback describing your solution and the problem you're running into.

Answer 2

LaRubin OP

6d

The current MDM/payload behavior prevents administrators from executing fully remote installations of security and DLP solutions. Admins must manually enable trust settings on each host. This task cannot be delegated to end-users, as they typically lack local administrator privileges.

Answer 3

Device Management Engineer OP

Apple

5d

I would suggest avoiding any options that involve private keys moving around. No PKCS #12 files.

Here's one option that requires MDM integration:

The MDM server installs and manages your app.
The MDM server uses declarative app configuration to give it a URL and authentication material (access token or identity) so it can contact the MDM server's API.
Your app uses ManagedApp framework to receive the URL and authentication material.
Your app generates the key pair and self-signed CA.
Your app uses the configured URL and authentication material to contact the MDM server and upload the CA's certificate.
The MDM server uses MDM or DDM to install the certificate on the device, which automatically grants it full trust.

There's potentially other ways for the MDM server to configure your app with the URL and authentication material, like managed preferences or the old managed app config, but declarative app configuration / ManagedApp framework is secure and built for exactly this kind of use case.

Also a note about the URL: It needs to somehow identify the device so the MDM server knows to which managed device it should send the certificate. However this shouldn't be the serial number, UDID, or some other persistent device identifier. That's because if an attacker gets access to the URL and authentication material, they could replace the device identifier with a different one and cause any other device that the MDM server manages to install and trust an attacker-controlled CA. So the URL should probably contain a single-use opaque token that the MDM server later looks up to determine the target device. Or better, this device identifier is encoded in the authentication material, and the API only allows installing the certificate on that one device.