Trusting a Certificate

Contributor III

Hi all. I thought this one was going to be quite easy but it's turining into a challenge.

A mail hosting organization I work with chaged certificates today and I'm trying to get the new cert installed and trusted.

Using a Mac that has trusted this cert, I exported it as a .cer into /private/tmp/certs and packaged it with Composer. I will call this cert

I then created a test policy to install this .pkg and then run the script. The policy does install the cert in /private/tmp/certs but the script fails.


/usr/bin/security add-trusted-cert -d -r trustAsRoot -k "/Library/Keychains/System.keychain" "/private/tmp/certs/" srm "/private/tmp/certs/"

I've tried trustRoot as well as trustAsRoot, as well as taking away the quotations marks.

I've also tried removing the /usr/bin before security.

But I keep getting the following error:

Script exit code: 2 Script result: Usage: add-trusted-cert [] [certFile] -d Add to admin cert store; default is user -r resultType resultType = trustRoot|trustAsRoot|deny|unspecified; default is trustRoot -p policy Specify policy constraint (ssl, smime, codeSign, IPSec, iChat, basic, swUpdate, pkgSign, pkinitClient, pkinitServer, eap) -a appPath Specify application constraint -s policyString Specify policy-specific string -e allowedError Specify allowed error (certExpired, hostnameMismatch) or integer -u keyUsage Specify key usage, an integer -k keychain Specify keychain to which cert is added -i settingsFileIn Input trust settings file; default is user domain -o settingsFileOut Output trust settings file; default is user domain -D Add default setting instead of per-cert setting certFile Certificate(s) Add trusted certificate(s). Error running script: return code was 2.

My test Mac I'm using is running El Capitan.

Where have I run astray?


Release Candidate Programs Tester

@gskibum Can you push the cert out via a profile?

New Contributor II

I've done this on previous OS's. I'm wondering if SIP is causing an issue?
Can you do it on 10.10?
Can you try the same import into a user keychain instead of the system Keychain?

Contributor III

@bentoms I had the same result with another cert that I am able to push with a Configuration Profile (I know the password for this cert).

Maybe I'm wrong, but my understanding is that I would need to know the password that was used to create the cert to push out via a configuration profile. I don't know the password for this mail cert.

However, I changed the script a bit and now I have successfully run this one on the test box:

Credit @andyinindy

His Helpful Post



/usr/bin/security add-trusted-cert -d -r trustAsRoot -k ${SYSTEM_KEYCHAIN} ${CERT_PATH}/
rm -f ${CERT_PATH}/

exit 0

Contributor III

Well it seems that Apple Mail won't see this certificate when it's located in System.keychain. When I manually move the certificate to the user's login.keychain Mail does see the cert and it works as being trusted.

How can I target the user level login.keychain with a policy?

Contributor III

OK I was mistaken about the certificate not working in System.keychain and instead working in login.keychain,

What is keeping this certificate from working is the trust policy settings:

When I install the cert into System.keychain with the above policy & script the trust settings are all set to Always Trust.

However the mail server won't use the cert with the trust settings configured like this. If I manually install the cert by configuring a mail account the trust settings are set so that only (Secure Sockets Layer SSL) is set to Always Trust. The rest are set to "no value specified."

If I change the certificate that I install with a policy to match the trust settings set to always trust only SSL and the rest set to "no value specified", it works. So it appears I need to modify my script to allow trusting only SSL, but I have been unsuccessful in my attempts.

I'm thinking I need to replace the "-r trustAsRoot" to something like "-p ssl -s trust", but I have been unsuccessful. I probably just don't know what the -s key is supposed to be.

Any thoughts?

This is what is almost working for me.



/usr/bin/security add-trusted-cert -d -p ssl -s trustAsRoot -k ${SYSTEM_KEYCHAIN} ${CERT_PATH}/
rm -f ${CERT_PATH}/

exit 0

New Contributor III

I know this is quite an older thread, but I was able to get what I needed using simply trustRoot (the default option) or by removing the "-r trustAsRoot" altogether.

Were you able to try using the following for the add-trusted-cert options? 


/usr/bin/security add-trusted-cert -d -p ssl -k ${SYSTEM_KEYCHAIN} ${CERT_PATH}/ 

New Contributor

did you figure this out?

i just did this same thing but for "EAP"

my command was

/usr/bin/security add-trusted-cert -d -r trustAsRoot -p ssl -k ${SYSTEM_KEYCHAIN} ${CERT_PATH}/

i didnt include the -s portion of the command