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

Hey devs,

I have a really weird issue and at this point I cannot determine is it a Big Sur 11.1 or M1 issue or just some macOS settings issue.

Short description

programatically (from node, electron) I'd like to store x509 cert to keychain. I got the following error message:

SecTrustSettingsSetTrustSettings: The authorization was denied since no user interaction was possible. (1)

I could reproduce this issue on:
  • a brand new mac mini with M1 chip and Big Sur 11.1

  • another brand new mac mini with M1 chip and Big Sur 11.1

  • a 2018 MacBook pro with Intel chip and Big Sur 11.1

I couldn't reproduce this issue on:
  • 2020 MacBook pro with intel i9 chip and Big Sur 11.1

  • 2020 MacBook pro with intel i9 chip and Big Sur 11.0

How am I trying to store the cert

Code Block bash
node test.js


Code Block javascript
const { exec } = require('child_process')
`osascript -e 'do shell script "security add-trusted-cert -d -r trustRoot -k /Library/Keychains/System.keychain /Users/kotapeter/ssl/testsite.local.crt" with prompt "Test APP wants to store SSL certification to keychain." with administrator privileges'`,
(error, stdout, stderr) => {
if (error) {
console.log(`Error code: ${error.code}`)
console.log(`Signal received: ${error.signal}`)
console.log(`STDOUT: ${stdout}`)
console.log(`STDERR: ${stderr}`)


Code Block text

Code Block text

What I've already found

If I run the following command from terminal It asks my password first in terminal and after that It asks my password again in OS password prompt.

Code Block bash
sudo security add-trusted-cert -d -r trustRoot -k /Library/Keychains/System.keychain /Users/kotapeter/ssl/testsite.local.crt

It looks like I'm getting the above error message because osascript hides the second password asking dialog.

The cert always gets stored in keychain but when I get the error message the cert "Trust" value is not "Always Trust".


StackOverflow question:

opened issue on sudo-prompt electron package:


I'd like to store x509 cert to keychain

The security tool is not considered API and I strongly recommend against you using it as such. Fortunately, macOS has APIs for adding keychain items (<Security/SecItem.h>) and configuring trust settings (<Security/SecTrustSettings.h>).

Share and Enjoy

Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + ""
Also, it’s likely that this problem is being triggered by the change discussed in the Security > New Features section of the macOS Big Sur 11.0.1 Release Notes. That change means that add-trusted-cert is triggering user interaction and then the user interaction is failing because of the way you’re running the security tool. If you were calling the trust settings API directly from your app the system would know that it was being called in a standard GUI context and thus would present the authorisation UI.

Share and Enjoy

Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + ""
Thank you @eskimo! 😃

I'll try it out!

Can I use Secitem and SecTrustSettings from terminal somehow?

Can I use SecItem and SecTrustSettings from terminal somehow?

Well, kinda. That’s what the security tool uses. You could also use some sort of programming environment, like the Swift REPL. However, this isn’t a useful test because the execution environment within Terminal is very different from that of your main app.

If I were in your shoes I’d create a small native test app to do this. Once you’ve got that working, you can integrate it into your main Electron app. That’ll avoid any Electron entanglements while you wrestle with this thorny issue.

Share and Enjoy

Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + ""
  • I normally avoid this forum because of the clumsiness of the interface and certainly never comment, but I'm making an exception because this has to be one of the more upsetting changes to macOS. No administrative command-line tool should ever require a GUI. While this specific user was doing this via JavaScript, I'm using ssh to Administer several dozen build servers and adding our company certificates to the keychain. If you have 'Full Disk Access' enabled for SSH and are an administrator sudo should be good enough.

    sudo security -i add-trusted-cert -d -r trustRoot -k /Library/Keychains/System.keychain /Users/admin/Documents/Company.cer SecTrustSettingsSetTrustSettings: The authorization was denied since no user interaction was possible.

    This should be escalated as a serious bug. The sales point of macOS is built on UNIX. Developers like macOS precisely because it has the power of the UNIX command-line and a first-class GUI. So when offered built-in SSH remote access you should not be required to connect via VNC, login, launch Terminal and execute the exact same command so that you can get a GUI prompt to log in.

  • This appears to have changed with 11.5.2. By chance today I discovered that security add-trusted-cert no longer creates a GUI prompt. I checked it on a machine with 11.5.1, and it still creates a GUI prompt.

  • @likeuntomurphy I have 11.5.2 and still get this annoying message...

Add a Comment
Thank you so much! I'll try to create a native solution and integrate it into Electron as you suggested. I'll get back to you soon. :)

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);
//      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 allow
  • Works fine on Big Sur 11.6(20G165)! Thanks a lot, this comment saved my whole week! :D

  • Can also save then restore the rights:

    sudo security authorizationdb read > rights sudo security authorizationdb write allow

    Do your stuff

    sudo security authorizationdb write < rights

    Default appears to be basically entitle and authenticate-admin, not sure how to set both of those via the command line arguments.

Add a Comment

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" + "@" + ""

  • I assume it is just a matter of configuring a proper rule in the authorization db by exporting/importing plist.

    Allowing all users to access keychain works for my CI use case.

  • So the solution would be "stick to the GUI because we didn't get to build up a secure procedure for the system administrator to do this stuff via command line"?

    Useful, indeed

  • Solution to this security concern:

    sudo security authorizationdb read > /tmp/security.plist; sudo security authorizationdb write allow; sudo security add-trusted-cert -d -r trustRoot -k /Library/Keychains/System.keychain <CERTIFICATE>; sudo security authorizationdb write < /tmp/security.plist; rm /tmp/security.plist

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 allow ; Do your stuff here ; sudo security authorizationdb remove

To be exact, this is what I ran:

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

and the following command for a .crt file:

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

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