Problems importing cert via terminal

[hkabik]

So I've run into an issue that is driving me batty... I run the standard terminal command:

security add-trusted-cert -d -r trustAsRoot -k /Library/Keychains/System.keychain /path/to/cert.cer

and I get:

SecTrustSettingsSetTrustSettings: One or more parameters passed to a function were not valid.

If I go to keychain access, it added the cert... but not as "Always Trust". Which is essential for this cert. It's set to use system defaults and just says "This root certificate is not trusted."

I have re-exported the cert from the windows server and I get the same thing every time. No matter what, it won't import as Always Trust.

Any ideas folks?

Additional note... when I go to delete the imported cert from keychain manager it throws up an error that says:

"An invalid record was encountered."

I have to restart Keychain Access 1 or 2 more time for it to allow me to delete it.

[mm2270]

I haven't done this kind of operation before myself, but I just took a quick look through the security man page, and I believe you're supposed to be using add-trusted-cert and not add-certificate At least, when I look up some of the flags you used, such as -r trustAsRoot, I only see those references under the "add-trusted-cert" section, not any others.

[hkabik]

You are correct. I actually meant add-trusted-cert, I had add-certifcate in there because I'm trying basically everything at this point to force it through. Thanks for the catch, I'll update my original post so it's correct.

[nessts · Accepted solution]

you might try doing trustRoot instead of trustAsRoot, there are different certificates that require the other flag. I have not spent the time to figure out what causes it, I just know sometimes one works and the other does not.

[gachowski]

I have seen issues with 4096 bit certs and the setting on how they were created. Some 4096 bit certs worked no issue and some 4096 bit certs failed.

I have no idea what the setting were as I didn't create the certs ...

Sorry I don't have any more info..

C

[hkabik]

trustRoot instead of trustAsRoot worked. I don't know why, but it did. Does anyone have any insight so I know which to use in the future.

[hkabik]

This is going to sound dumb... but I'm guessing I was misinterpreting the function of "trustAsRoot" I'm guessing that is a command to define and intermediary, where as trustRoot defines a root CA. I was assuming it meant Root as in the user, not the CA type.

[bentoms]

@hkabik if you're deploying this to 10.7+ clients, then you can use a profile with the Cerificate payload.

That will add the cert as a root cert & set it to always trust.

If it's an intermidiary cert, you will do better to deploy the root cert. Then all certs signed by that root will be trusted.

I'm guessing from the above that is was an intermediary, so trustRoot was setting the OS to trust the whole chain (including the root signing cert).

Whereas trustAsRoot is more commonly used for internal CA certs.

[ArmchairDeity]

I found this post invaluable... I do a lot of product testing and apparently one of our Chrome policies prohibits Chrome from automating the process of downloading and activating invalid certificates. So I've been trying to find a way to make this happen for a whole directory full of *.cer files because we use self-signed certs for the initial configuration of our products. After a TON of researching this little-discussed subject, I managed to come up with this that adds them to the admin keychain in a fully trusted configuration! SWEET!!

You guys are the bomb, and I hope that being able to add this to the discussion helps someone who wants the lazy man's way to install a whole directory full of browser certs into the Keychain at once!

find . -name '*.cer' -exec sudo security -v add-trusted-cert -r trustRoot -d -k /Library/Keychains/System.keychain ./{} ;

There's a couple key issues here...
1. -name '*.cer' has to be in quotes or {} tries to evaluate it before accessing the file and will fail with an invalid symbol error
2. -r trustRoot NOT -r trustAsRoot or you'll get the dreaded SecTrustSettingsSetTrustSettings error
3. security -v is helpful to ensure they've all been processed and show the commandline that was run, otherwise you get no output