SecTrustSettingsSetTrustSettings requires authorization?

It seems that the SecTrustSettingsSetTrustSettings API requires an alert panel asking for authentication on MacOS Big Sur even when the calling process is running as root.

This would mean the process calling this API must be in a GUI environment. Is there any way for our users to avoid this prompt and have the certificate we generated be inserted and trusted into the System Keychain running as a background daemon? What are some options / alternatives we have to address this issue? It would be ideal if we could set trust settings without requiring a prompt.

Are you deploying to a managed environment?

Share and Enjoy

Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

What are our options in a managed and non-managed environment?

I was asking that because I had assumed that you were trying to install a new trusted root, but your latest info suggests that’s not the case.

We also generate our private key and corresponding certificate after installation of the software.

I’m confused as to your goal here. Trust settings are usually used as a way to override the trust evaluation done by the system when you get a certificate from a remote peer (through a TLS connection, say). If you’re creating a digital identity (that is, a certificate and a private key that matches the public key in that certificate) locally then you generally don’t need to do trust evaluation on that. Rather, you send the certificate to the remote peer which does it’s own trust evaluation. And thus, because you don’t do trust evaluation, there’s no need to modify trust settings.

So can you walk me through how this digital identity is used?

Share and Enjoy

Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

So can you walk me through how this digital identity is used?

Apologies for the lack of information. Essentially we are developing a middlebox. We want to inspect and control HTTPS browser traffic. In order to do so we have a NETransparentProxyProvider intercept traffic. Our trusted root certificate would be used to generate site certificates that have the same fields as the certificates we receive from the server. In order for our "clones" to be trusted by browers our root certificate would need to be set to trusted since it issued them.

Ah, that explains it!

Essentially we are developing a middlebox.

So, my advice:

  • For managed deployments, prepare a document that explains to the site manager how their can deploy your custom root certificate using MDM to deploy a configuration profile.

  • For non-managed environments, provide instructions on how the user can install and trust your root certificate.

Trying to fully automate this is going to be an ongoing challenge as Apple continues to tighten security on our platforms.

Share and Enjoy

Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

Hello again, it seems that on macOS Monterey 12.0.1 this prompt for a password is no longer required when running as a root daemon. Is this intended behaviour and can we expect this behaviour going forward with newer versions of Monterey? Also, in the case of macOS Big Sur, are there intentions to remove the requirement for user interaction for this API when running as a root daemon?

SecTrustSettingsSetTrustSettings requires authorization?
 
 
Q