Mass deployment of certificates and marking it as trusted

I have the exact same issue on Sequoia, so you are not alone. I think I will open a support case with Apple and see if they have an updated method of doing this.

Apple intentionally changed the behavior of the security command. Adding a certificate to the trust store without user action or user disclosure is a security issue. It's exactly the kind of thing that malicious software would want to do.

I would suggest using MDM to manage the devices. With MDM you can automatically and remotely add certs to the trust store. You can also manage them on an ongoing basis: You can list certs, remove them, and rotate them when expiration nears.

If you still want to use a script to automatically add a cert to the trust store you still can, however there's a very large downside. You can disable System Integrity Protection (SIP). When SIP is disabled the security add-trusted-cert command can modify the trust store without user interaction. Of course, disabling SIP is very disruptive and requires user interaction, so this probably doesn't solve your problem. And most of all, disabling SIP significantly lowers the security posture of the device. It is not recommended to leave SIP disabled, so the full workflow would be: disable SIP, add the cert to the trust store, re-enable SIP. Because you'd have to do that workflow each occasion that you change the trusted certs, it's much more disruptive to the user than enrolling the devices in MDM.

@Device Management Engineer,

Thank you so much for your quick response.

I tried to achieve the same using an MDM solution (namely : JAMF) without success. Here is what I experienced : 1.: Importing a root CA can be done through JAMF, and it is marked as trusted 2.: Importing a non-root CA is also possible, but it cannot be marked as trusted using JAMF.

Would you happen to know of any MDM solutions that could support this functionality?

Thank you for your help in advance!

First let me provide some background. When a process running on an Apple OS does trust evaluation, there's roughly five sources of trust:

1. Custom implementation. This is what Chrome does. It does not use OS services to do trust evaluation, so trusting a cert would have to be something specific to Chrome.
2. Built-in trusted root certificates that Apple includes in its OSes. They are listed here and cannot be modified.
3. CAs (self-signed) certificates added to the trust store via configuration profile or MDM. These can have partial trust or full trust as described here.
4. Trust exceptions. This is visible when the user browses to a site in Safari and the cert isn't trusted. The user can visit the site anyway, which adds the site's leaf cert to a list of certs that are trusted anyway. This is also what a user can modify in Keychain Access in the Trust section of a cert.
5. Customized trust evaluation. This is where the process requesting trust evaluation is using OS services (unlike the first category), but it's explicitly telling the OS to trust some certs it's providing. These only affect that one trust evaluation. This is typically used for cert pinning.

1, 2 and 3 only apply to CAs. 4 applies to leaves, and 5 applies to both. In order for a trusted CA to affect the result of a trust evaluation, the device must be able to build a valid chain from the leaf to that CA, so sometimes you also end up installing intermediates.

All the above explains why why importing a non-CA through Jamf doesn't work. It's using that third category, which only applies to CAs.

So with that background out of the way, I need to ask what benefit you're expecting to come from signing the script? That will help determine what is doing the trust evaluation, which of these categories will help, and how to best use them.

Keep in mind: Gatekeeper is involved with ensuring that potentially untrusted content that end users manually download themselves from the internet or outside of the App Store is safe to open:

https://support.apple.com/en-us/102445

Enrolling in MDM creates a more trusted management and content delivery channel, offering organizations additional ways to get content onto macOS.

If you're not already delivering these scripts via MDM, I'd suggest trying it out and seeing if you still run into the same problems.

If you continue to see the same Gatekeeper prompts as before, even when the scripts are delivered via MDM, I'd recommend reaching out to your MDM vendor's support for additional help - or filing a Feedback via Feedback Assistant with an attached sysdiagnose from the device where you're experiencing this.

Thank you for the detailed background!

Currently, our system performs signature verification on scripts before execution, ensuring the following condition is met: The script originates from a specific trusted source.

When this checks is successful, we consider the script safe for execution   We provide a B2B solution to our customers, with an agent on all devices, which (among other things) enables e.g. L1 and L2 IT teams to execute (only) pre-written quality controlled and signed scripts. Our current implementation is similar to your point “4. Trust exceptions”, except that the customer remotely (ideally through MDM) marks the leaf explicitly as trusted, without interaction from the customer’s employees (device users). The leaf certificate for script signing comes from a public root CA trusted by Apple (as in “2. Built-in trusted root certificates”), so that parties untrusted by us and our customers can also request leaf certificates. For remote script execution, we only trust specific leaf certificates deployed on the device.

We are planning to move towards the approach you described as category "1. Custom implementation.". However, we didn't anticipate the need to expedite this change due to Sonoma's new limitations on mass-deploying non-root CAs and marking them as trusted without user confirmation. We have customers that already rely on the solution based on the KeyChain. We would like to provide them with a temporary workaround they can use immediately.

Is there a temporary workaround we could go with until we update our product to do "1. Custom implementation." ?

Your advice would be very helpful.