security add-trusted-cert asks password twice in some cases: The authorization was denied since no user interaction was possible

I'd like to store x509 cert to keychain

Can I use SecItem and SecTrustSettings from terminal somehow?

use SecTrustSettingsSetTrustSettings also get this error . Maybe because I can't make my application root?

//      CFArrayRef trustSettings = (__bridge CFArrayRef)@[x509Settings, otherSettings];
      SecKeychainUnlock(NULL, 0, NULL, FALSE);
      OSStatus isTrustOk = SecTrustSettingsSetTrustSettings(certificate, kSecTrustSettingsDomainAdmin, NULL);
      if (isTrustOk == errSecSuccess) {
        CASLog(@"set trusting is OK");
      }else {
        CASLog(@"set trusting failed！");
        CFStringRef errormsg = SecCopyErrorMessageString(isTrustOk, NULL);
        NSString *errmsg = (NSString *)CFBridgingRelease(errormsg);
        CASLog(@"error:%@",errmsg);
      }
      SecKeychainLockAll();
//      CFRelease(x509Policy);

The authorization was denied since no user interaction was possible. i got this。

We're hitting against this same issue, except we're not trying to do it from an application, we're just trying to script the setup of a CI environment.

We need to add the cert, and we only have SSH terminal access, no GUI, so the add cert command hangs while it waits for the GUI password prompt that we cannot access. This is broken. As CameronP stated, no command line tool should require a GUI, that's insane.

Where do we go from here?

Fun fact: running security add-trusted-cert -d -r trustRoot -k ~/Library/Keychains/login.keychain-db file.crt inside a non-interactive environment actually adds the cert to the keychain, but it throws an error anyway (which stops the script from further actions)

Apparently this command bypasses the GUI authorization check:

sudo security authorizationdb write com.apple.trust-settings.admin allow

Apparently this command bypasses the GUI authorization check:

That’s a very heavy hammer. It allows anyone, or any code, on the system to add a trusted root certificate. I wouldn’t do that on a Mac that I care about.

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

Hi there

How could I revert the trust settings to the defaults? I was testing @dokimyj workaround but I agree that's a terrible idea for computers you care about.

Thanks in advance for any feedback.

Cheers, Iñaky

Thank you all for your responses. I am trying to add some trusted certificates to my keychain without prompting through Puppet.

I decided to share my solution which might be useful for you or anybody else who reads this page. Using @dpotapov approach was a bit dangerous but the only way to make the automation possible, so I used the approach and did my stuff afterwards and removed the permissions in the end as follows

sudo security authorizationdb write com.apple.trust-settings.admin allow ; Do your stuff here ; sudo security authorizationdb remove com.apple.trust-settings.admin

To be exact, this is what I ran:

security authorizationdb write com.apple.trust-settings.admin allow ; security add-trusted-cert -d -r trustAsRoot -p ssl -k "/Library/Keychains/System.keychain" /etc/ssl/ldap0.pem ; security authorizationdb remove com.apple.trust-settings.admin

and the following command for a .crt file:

security authorizationdb write com.apple.trust-settings.admin allow ; security add-trusted-cert -d -r trustRoot -k "/Library/Keychains/System.keychain" /etc/ssl/mycert.crt ; security authorizationdb remove com.apple.trust-settings.admin

@InakyMartinez hope this answered your question too in order to delete the permission you granted.

I am running into the same issue. The sudo security authorizationdb write com.apple.trust-settings.admin allow returns NO which caused me to enter the sudo password for my Mac multiple times. Since the script that I am running is installing 100s of certificates this is an issue I must fix. I am using macOS Sequoia 15.7.

I’m going to close out this thread. Lemme explain my rationale…

The primary issue being discussed here is installing a root certificate without explicit approval from the user such that it’s trusted system wide. There are two different cases:

• Doing this programmatically
• Doing this from Terminal or from a shell script

For the programmatic case, there’s no supported solution. This isn’t a bug but a deliberate security hardening, as I explained in this post.

For the Terminal and shell script case, DevForums isn’t the right place to have that discussion because:

• Our focus here is primarily on APIs, not device management.
• Many of the workarounds suggested on this thread rely on implementation details, which is counter to the forums’ focus on APIs.

If you want to continue exploring device management options, I encourage you to pop over to the Apple Support Community, run by Apple Support, and specifically the Business and Education topic area.

Finally, there’s one very clear path forward here: Install the root certificate as a com.apple.security.root payload using MDM. If you’re in a managed environment, that’s super easy. If not in a managed environment, consider whether making that switch is warranted.

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