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

Question

Created Jan ’21

Replies 12

Boosts 0

Views 17k

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  bashnode test.js

test.js

Code Block javascriptconst { 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-----MIIDUzCCAjugAwIBAgIUD9xMnL73y7fuida5TXgmklLswsowDQYJKoZIhvcNAQELBQAwGTEXMBUGA1UEAwwOdGVzdHNpdGUubG9jYWwwHhcNMjEwMTE3MTExODU1WhcNNDEwMTEyMTExODU1WjAZMRcwFQYDVQQDDA50ZXN0c2l0ZS5sb2NhbDCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBANM08SDi06dvnyU1A6//BeEFd8mXsOpDQCbYEHX/Pz4jqaBYwVjD5pG7FkvDeUKZnEVyrsofjZ4Y1WAT8jxPMUi+jDlgNTiFjPVc4rA6hcGX6b70HjsCACmc8bZd+EU7gm4b5eL6exTsVzHc+lFz4eQFXgutYTL7guDQE/gFHwqPkLvnfg3rgY31p3Hm/snL8NuD154iE9O1WuSxEjik65uOQaewZmJ9ejJEuuEhMA8O9dXveJ71TMV5lqA//svDxBu3zXIxMqRy2LdzfROd+guLP6ZD3jUycWi7GpF4yN0+rD/0aXFJVHzV6TpS9oqb14jynvn1AyVfBB9+VQVNwTsCAwEAAaOBkjCBjzAJBgNVHRMEAjAAMAsGA1UdDwQEAwIC9DA7BgNVHSUENDAyBggrBgEFBQcDAQYIKwYBBQUHAwIGCCsGAQUFBwMDBggrBgEFBQcDBAYIKwYBBQUHAwgwHQYDVR0OBBYEFDjAC2ObSbB59XyLW1YaD7bgY8ddMBkGA1UdEQQSMBCCDnRlc3RzaXRlLmxvY2FsMA0GCSqGSIb3DQEBCwUAA4IBAQBsU6OA4LrXQIZDXSIZPsDhtA7YZWzbrpqPceXPwBd1k9Yd9T83EdA00N6eoOWFzwnQqwqKxtYdl3x9JQ7ewhY2huH9DRtCGjiTm/GVU/WnNm4tUTuGU4FyjSTRi8bNUxTSF5PZ0U2/vFZ0d7T43NbLQAiFSxyfC1r6qjKQCYDL92XeU61zJxesxy5hxVNrbDpbPnCUZpx4hhL0RHgG+tZBOlBuW4eq249O0Ql+3ShcPom4hzfh975385bfwfUT2s/ovng67IuM9bLSWWe7U+6HbOEvzMIiqK94YYPmOC62cdhOaZIJmro6lL7eFLqlYfLU4H52ICuntBxvOx0UBExn-----END CERTIFICATE-----

testsite.local.key:

Code Block text-----BEGIN RSA PRIVATE KEY-----MIIEpQIBAAKCAQEA0zTxIOLTp2+fJTUDr/8F4QV3yZew6kNAJtgQdf8/PiOpoFjBWMPmkbsWS8N5QpmcRXKuyh+NnhjVYBPyPE8xSL6MOWA1OIWM9VzisDqFwZfpvvQeOwIAKZzxtl34RTuCbhvl4vp7FOxXMdz6UXPh5AVeC61hMvuC4NAT+AUfCo+Qu+d+DeuBjfWnceb+ycvw24PXniIT07Va5LESOKTrm45Bp7BmYn16MkS64SEwDw711e94nvVMxXmWoD/+y8PEG7fNcjEypHLYt3N9E536C4s/pkPeNTJxaLsakXjI3T6sP/RpcUlUfNXpOlL2ipvXiPKe+fUDJV8EH35VBU3BOwIDAQABAoIBAQDDGLJsiFqu3gMKIZCIcHCDzcM7Kq43l2uY9hkuhltrERJNle70CfHgSAtubOCETtT1qdwfxUnR8mqX15T5dMW3xpxNG7vNvD/bHrQfyc9oZuV6iJGsPEreJaV5qg/+E9yFzatrIam0SCS7YL6xovPU58hZzQxuRbo95LetcT2dSBY33+ttY7ayV/Lx7k6nh0xU6RmTPHyyr8m7yHpoJoSxdT/xv5iBSZ8mM9/2Vzhr14SWipVuwVVhDSfbn8ngHpIoQDkaJLMpWr+m4z3PqfftAwR6s6i96HnhYLnRir618TQh4B9IEngeEwCMn4XAzE3L+VTaKU1hg9elaMfXzPERAoGBAPa+sJ2p9eQsv0vCUUL8KeRWvwjDZRTd+YAIfpLMWrb0tMmrBM4VV0L2joF76kdDxt1SAlHoYCT/3Rn8EPmK0TN3MEskiXQ7v57iv+LZOZcpe0ppG/4AZihF9+wUjFCDw4ymnRQD463535O6BgZV+rcZksFRD2AwvEjt1nYm93VXAoGBANshAYM+FPmMnzebUMB0oGIkNkE9nVb9MPbQYZjEeOeHJqmt1Nl6xLuYBWTmWwCy7J4eQPtnuMCdO6C1kuOGjQPBFIpeyFMzll+E3hKzicumgCpt5U8nTZoKc/jZckRD7n3plbYYgHOR3A/3GCDK5L3rwziWpSRAGMSCQylvkOC9AoGBAKLfZL3t/r3LO8rKTdGlmhF7oUYrlIGdtJ/q+4HzGr5B8URdeyJ9u8gb8B1Qqmi4OIDHLXjbpvtFWbFZTesq0sTiHCK9z23GMsqyam9XbEh3vUZ082FK6iQTa3+OYMCU+XPSV0Vq+9NPaWGeHXP5NTG/07t/wmKASQjq1fHP7vCpAoGBAK4254T4bqSYcF09Vk4savab46aq3dSzJ6KSuYVDbvxkLxDn6zmcqZybmG5H1kIP/p8XXoKCTBiW6Tk0IrxR1PsPHs2D3bCIax01/XjQ1NTcYzlYdd8gWEoH1XwbJQWxHINummBTyowXguYOhVhM9t8n+eWbn1/atdZF2i+vS3fhAoGAYKw6rkJfTSEswgBKlQFJImxVA+bgKsEwUti1aBaIA2vyIYWDeV10G8hlUDlxvVkfwCJoy5zz6joGGO/REhqOkMbFRPseA50u2NQVuK5C+avUXdcILJHNzp0nC5eZpP1TC++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  bashsudo 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

Boost

Answer 1

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

Answer 2

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

Answer 3

peterkota OP

Jan ’21

Thank you @eskimo! 😃

I'll try it out!

Can I use Secitem and SecTrustSettings from terminal somehow?

0

Answer 4

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

Answer 5

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

Answer 6

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。 SOBEAU AOIFUNtCk， Sestruntatstngstettrunfbeteinas(ee Fskracate. x3eorrustsettirotovankokasin. M).png

0

Answer 7

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

Answer 8

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

Answer 9

dpotapov OP

Nov ’21

Apparently this command bypasses the GUI authorization check:

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

3

Answer 10

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

Answer 11

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

Answer 12

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

	// 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);