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

test.js

Code Block javascript
const { exec } = require('child_process')
exec(
  `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.stack)
      console.log(`Error code: ${error.code}`)
      console.log(`Signal received: ${error.signal}`)
    }
    console.log(`STDOUT: ${stdout}`)
    console.log(`STDERR: ${stderr}`)
    process.exit(1)
  }
)

testsite.local.crt:

Code Block text
-----BEGIN CERTIFICATE-----
MIIDUzCCAjugAwIBAgIUD9xMnL73y7fuida5TXgmklLswsowDQYJKoZIhvcNAQEL
BQAwGTEXMBUGA1UEAwwOdGVzdHNpdGUubG9jYWwwHhcNMjEwMTE3MTExODU1WhcN
NDEwMTEyMTExODU1WjAZMRcwFQYDVQQDDA50ZXN0c2l0ZS5sb2NhbDCCASIwDQYJ
KoZIhvcNAQEBBQADggEPADCCAQoCggEBANM08SDi06dvnyU1A6//BeEFd8mXsOpD
QCbYEHX/Pz4jqaBYwVjD5pG7FkvDeUKZnEVyrsofjZ4Y1WAT8jxPMUi+jDlgNTiF
jPVc4rA6hcGX6b70HjsCACmc8bZd+EU7gm4b5eL6exTsVzHc+lFz4eQFXgutYTL7
guDQE/gFHwqPkLvnfg3rgY31p3Hm/snL8NuD154iE9O1WuSxEjik65uOQaewZmJ9
ejJEuuEhMA8O9dXveJ71TMV5lqA//svDxBu3zXIxMqRy2LdzfROd+guLP6ZD3jUy
cWi7GpF4yN0+rD/0aXFJVHzV6TpS9oqb14jynvn1AyVfBB9+VQVNwTsCAwEAAaOB
kjCBjzAJBgNVHRMEAjAAMAsGA1UdDwQEAwIC9DA7BgNVHSUENDAyBggrBgEFBQcD
AQYIKwYBBQUHAwIGCCsGAQUFBwMDBggrBgEFBQcDBAYIKwYBBQUHAwgwHQYDVR0O
BBYEFDjAC2ObSbB59XyLW1YaD7bgY8ddMBkGA1UdEQQSMBCCDnRlc3RzaXRlLmxv
Y2FsMA0GCSqGSIb3DQEBCwUAA4IBAQBsU6OA4LrXQIZDXSIZPsDhtA7YZWzbrpqP
ceXPwBd1k9Yd9T83EdA00N6eoOWFzwnQqwqKxtYdl3x9JQ7ewhY2huH9DRtCGjiT
m/GVU/WnNm4tUTuGU4FyjSTRi8bNUxTSF5PZ0U2/vFZ0d7T43NbLQAiFSxyfC1r6
qjKQCYDL92XeU61zJxesxy5hxVNrbDpbPnCUZpx4hhL0RHgG+tZBOlBuW4eq249O
0Ql+3ShcPom4hzfh975385bfwfUT2s/ovng67IuM9bLSWWe7U+6HbOEvzMIiqK94
YYPmOC62cdhOaZIJmro6lL7eFLqlYfLU4H52ICuntBxvOx0UBExn
-----END CERTIFICATE-----

testsite.local.key:
Code Block text
-----BEGIN RSA PRIVATE KEY-----
MIIEpQIBAAKCAQEA0zTxIOLTp2+fJTUDr/8F4QV3yZew6kNAJtgQdf8/PiOpoFjB
WMPmkbsWS8N5QpmcRXKuyh+NnhjVYBPyPE8xSL6MOWA1OIWM9VzisDqFwZfpvvQe
OwIAKZzxtl34RTuCbhvl4vp7FOxXMdz6UXPh5AVeC61hMvuC4NAT+AUfCo+Qu+d+
DeuBjfWnceb+ycvw24PXniIT07Va5LESOKTrm45Bp7BmYn16MkS64SEwDw711e94
nvVMxXmWoD/+y8PEG7fNcjEypHLYt3N9E536C4s/pkPeNTJxaLsakXjI3T6sP/Rp
cUlUfNXpOlL2ipvXiPKe+fUDJV8EH35VBU3BOwIDAQABAoIBAQDDGLJsiFqu3gMK
IZCIcHCDzcM7Kq43l2uY9hkuhltrERJNle70CfHgSAtubOCETtT1qdwfxUnR8mqX
15T5dMW3xpxNG7vNvD/bHrQfyc9oZuV6iJGsPEreJaV5qg/+E9yFzatrIam0SCS7
YL6xovPU58hZzQxuRbo95LetcT2dSBY33+ttY7ayV/Lx7k6nh0xU6RmTPHyyr8m7
yHpoJoSxdT/xv5iBSZ8mM9/2Vzhr14SWipVuwVVhDSfbn8ngHpIoQDkaJLMpWr+m
4z3PqfftAwR6s6i96HnhYLnRir618TQh4B9IEngeEwCMn4XAzE3L+VTaKU1hg9el
aMfXzPERAoGBAPa+sJ2p9eQsv0vCUUL8KeRWvwjDZRTd+YAIfpLMWrb0tMmrBM4V
V0L2joF76kdDxt1SAlHoYCT/3Rn8EPmK0TN3MEskiXQ7v57iv+LZOZcpe0ppG/4A
ZihF9+wUjFCDw4ymnRQD463535O6BgZV+rcZksFRD2AwvEjt1nYm93VXAoGBANsh
AYM+FPmMnzebUMB0oGIkNkE9nVb9MPbQYZjEeOeHJqmt1Nl6xLuYBWTmWwCy7J4e
QPtnuMCdO6C1kuOGjQPBFIpeyFMzll+E3hKzicumgCpt5U8nTZoKc/jZckRD7n3p
lbYYgHOR3A/3GCDK5L3rwziWpSRAGMSCQylvkOC9AoGBAKLfZL3t/r3LO8rKTdGl
mhF7oUYrlIGdtJ/q+4HzGr5B8URdeyJ9u8gb8B1Qqmi4OIDHLXjbpvtFWbFZTesq
0sTiHCK9z23GMsqyam9XbEh3vUZ082FK6iQTa3+OYMCU+XPSV0Vq+9NPaWGeHXP5
NTG/07t/wmKASQjq1fHP7vCpAoGBAK4254T4bqSYcF09Vk4savab46aq3dSzJ6KS
uYVDbvxkLxDn6zmcqZybmG5H1kIP/p8XXoKCTBiW6Tk0IrxR1PsPHs2D3bCIax01
/XjQ1NTcYzlYdd8gWEoH1XwbJQWxHINummBTyowXguYOhVhM9t8n+eWbn1/atdZF
2i+vS3fhAoGAYKw6rkJfTSEswgBKlQFJImxVA+bgKsEwUti1aBaIA2vyIYWDeV10
G8hlUDlxvVkfwCJoy5zz6joGGO/REhqOkMbFRPseA50u2NQVuK5C+avUXdcILJHN
zp0nC5eZpP1TC++uCboJxo5TIdbLL7GRwQfffgALRBpK12Vijs195cc=
-----END RSA PRIVATE KEY-----


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".

References


StackOverflow question: https://stackoverflow.com/questions/65699160/electron-import-x509-cert-to-local-keychain-macos-the-authorization-was-deni

opened issue on sudo-prompt electron package: https://github.com/jorangreef/sudo-prompt/issues/137
Up vote post of peterkota Down vote post of peterkota
13k views
Posted by
peterkota
Reply
Add a Comment

Replies

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" + "@apple.com"
Posted by
eskimo
Up vote reply of eskimo Down vote reply of eskimo
Add a Comment
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" + "@apple.com"
Posted by
eskimo
Up vote reply of eskimo Down vote reply of eskimo
Add a Comment
Thank you @eskimo! 😃

I'll try it out!

Can I use Secitem and SecTrustSettings from terminal somehow?
Posted by
peterkota
Up vote reply of peterkota Down vote reply of peterkota
Add a Comment

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" + "@apple.com"
Posted by
eskimo
Post not yet marked as solved Up vote reply of eskimo Down vote reply of eskimo

  • 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.

    —
    CameronP

  • 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

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

    —
    kwiatkm4
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. :)
Posted by
peterkota
Up vote reply of peterkota Down vote reply of peterkota
Add a Comment

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。

Posted by
Erick_Hui
Up vote reply of Erick_Hui Down vote reply of Erick_Hui
Add a Comment

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?

Posted by
jamesaddyman-rantmedia
Post not yet marked as solved Up vote reply of jamesaddyman-rantmedia Down vote reply of jamesaddyman-rantmedia
Add a Comment

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)

Posted by
kwiatkm4
Up vote reply of kwiatkm4 Down vote reply of kwiatkm4
Add a Comment

Apparently this command bypasses the GUI authorization check:

sudo security authorizationdb write com.apple.trust-settings.admin allow
Posted by
dpotapov
Post not yet marked as solved Up vote reply of dpotapov Down vote reply of dpotapov

  • Works fine on Big Sur 11.6(20G165)! Thanks a lot, this comment saved my whole week! :D

    —
    dokimyj

  • Can also save then restore the rights:

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

    Do your stuff

    sudo security authorizationdb write com.apple.trust-settings.admin < rights

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

    —
    opoplawski
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" + "@" + "apple.com"

Posted by
eskimo
Up vote reply of eskimo Down vote reply of eskimo

  • 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.

    —
    dpotapov

  • 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

    —
    domesantoro

  • Solution to this security concern:

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

    —
    Andy_G

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

Posted by
InakyMartinez
Up vote reply of InakyMartinez Down vote reply of InakyMartinez
Add a Comment

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.

Posted by
geexirooz
Post not yet marked as solved Up vote reply of geexirooz Down vote reply of geexirooz
Add a Comment