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

Code Signing Entitlements
peterkota OP
Created Jan ’21
Replies 12
Boosts 0
Views 15k
Participants 15
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
Replies  12
Boosts  0
Views  15k
Participants  15
DTS Engineer OP
Apple
Jan ’21

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"
0
DTS Engineer OP
Apple
Jan ’21
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"
0
peterkota OP
Jan ’21
Thank you @eskimo! 😃

I'll try it out!

Can I use Secitem and SecTrustSettings from terminal somehow?
0
DTS Engineer OP
Apple
Jan ’21

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"
2
peterkota OP
Jan ’21
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. :)
0
Erick_Hui OP
Jun ’21

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。

0
jamesaddyman-rantmedia OP
Jul ’21

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?

2
kwiatkm4 OP
Aug ’21

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)

0
dpotapov OP
Nov ’21

Apparently this command bypasses the GUI authorization check:

sudo security authorizationdb write com.apple.trust-settings.admin allow
3
DTS Engineer OP
Apple
Nov ’21

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"

0
InakyMartinez OP
Jan ’22

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

0
geexirooz OP
Nov ’22

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.

1
security add-trusted-cert asks password twice in some cases: The authorization was denied since no user interaction was possible
First post date Last post date
 
 
Q