Deploying certificates

You do not mention where you want the certificate to end up, but you should look at the following commands:

security add-trusted-cert

security add-certificates

The process would be two steps. One would be to copy the certificate to the machine using ARD. I would copy it somewhere like /tmp/certs/ (not sure if ARD will make the directory if it does not exist already). You could also do that via Composer and a package.

The second would be to send a Unix command from ARD to load that certificate into the correct keychain. You could also add that as a script into the policy that pushes down the certificate, and have the script run 'after'.

If you are using Configuration Profiles at all you can also add certificates that way. Configuration Profiles would be a lot easier.

Ideally, in the System Keychain or something that would be system wide. with the trust settings to Always trust, which didn't seem to get passed down when doing a test deploy.

Also, the certificates are .pem (we have 4 different ones).

Right now the tools we have until our set-up is; Composer, ARD, and OS X Server.
So I'm unfortunately limited, but you've been helpful in explaining this. so i appreciate that very much.

you could try something like this in the command part of ARD, of course fix the cert name and the path to it.

security add-trusted-cert -d -r trustAsRoot -k /Library/Keychains/System.keychain "/.installfiles/Cert/mycert.pem"

thanks Nessts, the only error I come across is this: SecCertificateAddToKeychain: write permissions error

ran as Root in ARD

yes, i am sorry i assumed too much, if you are sending the command from ARD you need to do it as root. if you are running locally in a terminal you should preface the command with sudo, sorry about that.

excellent, thanks for that. solved that issue. and its throwing the keychain in there, with the exception of maybe this is a manual process...to switch the Trust carrot to Always Trust instead of Use System Defaults in Keychain.

*thanks again for your help, our casper deployment can't come soon enough, a config profile would have been way cleaner and easier*

Looks like you already have it sorted but in future perhaps you could build a config profile with IPCU or similar, load the certs you need in there and then use tim suttons awesome profile to package tool and deploy the package

https://github.com/timsutton/make-profile-pkg

so far it isn't completely sorted, still not sure on the always trust configuration, its just using System defaults. which I'm not sure if that will enable the cert or not fully.

but thanks for the link and info

Easiest way is to deploy Certs via a config profile, that was they are trusted.

If you're using profiles, all you need to do is create one with the security payload.. Upload the cert & deploy.

is there an easy way to 'always trust' and existing certificate?

Can someone help me in a step by step process to get the certificate installed please.

I presume i'd need to get the certificate onto all the clients first then runs a script to install?

@jwojda:

There is not really an "easy way" to always trust an existing cert, but it is possible. You can set the certificate(s) to "always trust" and then use the security command to export the trust settings to a plist:

bash-3.2# security trust-settings-export -d /Users/Shared/trust_settings.plist

Be aware that this will include ALL trust settings for items in your System keychain, so you may want to do this on a machine that has only the certs that you want to edit. Once you have the plist, you can copy it to your client systems and import the trust settings like so:

bash-3.2# security trust-settings-import -d /Users/Shared/trust_settings.plist

So yeah, kind of a pain in the a$$, but doable.

--Andy

Or just redeploy the cert via config profile.

@bentoms

That seems to work for root certs but not for others. I deployed a non-root cert via a profile this morning and it didn't have have any trust settings specified.

@g1za][/url

Yes, that is correct. The process that we have used is to lay down the cert in a temp location via a package, use a postinstall script to install the cert, and then clean up afterwards. Something like this:

#!/bin/bash

CERT_PATH="/private/var/tmp"
SYSTEM_KEYCHAIN="/Library/Keychains/System.keychain"

/usr/bin/security add-trusted-cert -d -r trustAsRoot -k ${SYSTEM_KEYCHAIN} ${CERT_PATH}/radius01.pretendco.com.cer
/usr/bin/security add-certificates -k ${SYSTEM_KEYCHAIN} ${CERT_PATH}/DigiCert\ SHA2\ Secure\ Server\ CA.cer
rm -f ${CERT_PATH}/radius01.pretendco.com.cer
rm -f ${CERT_PATH}/DigiCert\ SHA2\ Secure\ Server\ CA.cer

exit 0

Or you could just deploy them via a profile as @bentoms][/url suggests :)

--Andy

What am i doing wrong?

I've put the certificate in the / path and via ARD am trying to install with:

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

quote marks missing?

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

@g1za, honestly. Try via a profile.

A configuration profile will install this certificate for you. If there's something not working, let's talk about that.

Let the big expensive box do the work for you. :-)

I'm trying to deploy a new internal root CA & intermediate cert, and they are not coming down (via Config Profile) as trusted.

I added new certificates to our existing Cert deployment profile, but these new certs install and show up in keychain with the error "This certificate could not be verified" - Ok I just looked at it again and my root is showing up as an intermediate cert, not a root.

What am I doing wrong?

If a configuration profile isn't signed, it will install the certs using "system default" trust settings. If you want the certs to install using "always trust" trust settings, you need to sign the configuration profile. A self-signed cert will suffice, such as the one created when you set up profile manager on OS X Server.

@JDHatman good to know. Thanks!

When using the configuration profile method (ones built by OS X Server profile manager) is the default that the setting is applied to the User and you can't configure to apply to the Computer? I'm testing out @JDHatman's method and not seeing that as an option.

...and I may have found my own answer....

@JDHatman I am confused by your post regarding signed profiles. Doesn't the JSS sign all profiles by default? If so, shouldn't all certs that are delivered as a part of config profiles from the JSS be set to "Always Trust" (they are not)? Or is this only the case for profile manager?

sorry to resurrect this old thread,but still is helpful in a new environment I'm at.

When i initially requested this we had no access to Casper or anything, even Server was limited and didn't test much. but once we deployed Casper and got these systems on a domain setting they seemed to be okay, the certs were delivered via Config profile and whatever we used at the time for signing certs (in the JSS?) seemed to do the trick.

But what I'm understanding is that you could ultimately use Server to build a config profile, and send that out via ARD or something and it work the same way?

@SQR i think i know the issue

security add-trusted-cert -d -r trustAsRoot -k "/Library/Keychains/System.keychain" "/private/tmp/certs/certificate.cer"

it should be trustRoot not trustAsRoot

The correct syntax is without the first set of quotes. The quotes only go on the path to the certificate you want to install.

security add-trusted-cert -d -r trustAsRoot -k /Library/Keychains/System.keychain "/private/tmp/certs/certificate.cer"

This thread helped me a lot while troubleshooting my own Root Cert issue. Here is a suggestion from my experience. It might help someone who is in the same situation as mine.

My Situation: - I had a bunch of Root Certs and Intermediate Certs that needed to be added in the system Keychain as trusted certs
- I have found that my Root Cert Server doesn't issue certs. It's turned off. So, only trusting them is not helpful.
- My Intermediate cert servers are acting as root cert. So, these certs need to be trusted as well

My solution:
1. I have packaged up all the certs (.cer files) in the composer.
2. Wrote a script to add the certs after extracting the .cer files 3. Created a policy to deploy the certs.

The most useful info is: While deploying the Root Cert use this command: /usr/bin/security add-trusted-cert -d -r trustRoot -k /Library/Keychains/System.keychain "/private/tmp/certs/RootCertificate.cer"

While deploying the Intermediate Cert, use this command:
/usr/bin/security add-trusted-cert -d -r trustAsRoot -k /Library/Keychains/System.keychain "/private/tmp/certs/IntermCertificate.cer"

If you don't use "trustAsRoot" for intermediate certs while the root cert server is turned off, You won't get them as "Always Trust"

Hope it helps thanks.

Hi All,

This thread has certainly helped me understand what is going on and what it takes to get this going.

But i'm running into an issue when issuing a new CA. First I tried to create a new Configuration Profile that housed the new intermediate certification authority, it pushed to the machines and installed in the system keychain. Problem is, it's not trusted. I read that because the Configuration Profile isn't signed, it's going to be set to system defaults.

So i fired up Apple Configurator and created a Configuration Profile there and singed it with our Apple Worldwide Developer Relations Certification Authority cert. Still not setting the trust settings to always trust.

Is there anyway i can do this without building a package and scripting the trust settings changes?

Thanks in advance!

Edit:
I suspect that this is happening because it's not a root certificate?

@LovelessinSEA you need the full chain of trust. Is your intermediate cert signed by a public CA or an internal one? If the intermediate cert that you are installing is signed by an untrusted root CA, then the intermediate will show up as untrusted. You will need to make sure that the root is in the system keychain and trusted if you want the intermediate to be trusted. No need to manually install trust settings unless you cannot deploy the root ca.