Adding A Certificate To The System Keychain Set To Always Trust

[mottertektura]

Greetings!

Having a bit of trouble with a host name mismatch on a ceritificate that's causing an issue with Outlook on startup.

So far, I've added and exported the certificate in Keychain Access, uploaded it to the JSS in a configuration profile, and then tried to deploy it to a test computer but the problem here is that the trust settings are set to Use System Defaults.

Then, I tried packaging the certificate up with composer and copying it to /tmp and installing it with this command:

/usr/bin/security add-trusted-cert -d -r trustAsRoot -k /Library/Keychains/System.keychain /tmp/certificate.cer

Which does add it and set to Always Trust...

However, I still see the Verify Certificate message when Outlook is opened and Use System Defaults as the Trust settings even though the certificate is marked trusted for all users.

Any thoughts on what I might be doing wrong or another way to go about adding this certificate to the keychain and setting it to Always Trust?

Thanks!

[mottertektura · Accepted solution]

Apparently I just need to try harder when searching. :(

I found the the answer here:

https://www.jamf.com/jamf-nation/discussions/16669/office-2016-and-certificates

[AVmcclint]

The original problem of getting certificates to be Always Trusted when installed from a Configuration Profile is still a valid one that needs a solution. I'm not having the problem with Outlook, but I am having the same problem with other servers we have. Is this doable or does it have to be packaged and scripted?

[mottertektura]

@AVmcclint I have had inconsistent results deploying certificates with Configuration Profiles as Always Trusted. Our root CA seems to install correctly, but there have been times they do not install as Always Trusted (such as this problem with Outlook). I have also tried creating a Profile in the JSS with the certificate payload and downloading it, then striping out the signing and re-signing with our Developer ID Installer certificate. When I examined the certificate in Keychain Access, I found that it did install the certificate and set the trust settings to Always Trusted, but I was still seeing the "A secure connection cannot be established..." message when opening Outlook. It was only when I packaged up the certificate and used this command from the thread above that I was able to install it with the correct trust settings.

/usr/bin/security -v add-trusted-cert -r trustAsRoot -e hostnameMismatch -d -k /Library/Keychains/System.keychain /tmp/SOME_CERTIFICATE.cer

[AVmcclint]

How about approaching it from a different angle... Is it possible to change the System Default to always trust? That way if you have a handful of certs, you don't have to change the trust on each one - they would all fall into the default of Trusted.

[gabester]

Hey this is great - I was having the exact same problem with Outlook 2016 prompting the user on a host name mismatch of the server's certificate due to it being hosted on a distributed platform.

The solution is to either trust the cert at each workstation or issue a new cert with the mismatched domain as the subject alternative domain, per https://support.microsoft.com/en-us/help/3066652/certificate-warning-in-outlook-2016-for-mac - which did you do? I'm guessing it may have been easier to package and deploy the certs with a postinstall script than it is to persuade those responsible getting that newly trusted cert? That's the method I'm going with.

[jhbush]

Be careful with Always Trust settings. I've run into issues where Sierra will stop evaluating certificate chains properly. I use a Profile to deploy our Root and Chain certificates. Previously we had used a .pkg that ran a number of security commands to set the trust.

[mottertektura]

@Sterritt Yes, exactly. We eventually resolved the hostname mismatch issue with the cert but I also packaged and deployed the hostname mismatch cert with a postinstall script to trust it for good measure in the meantime.

All of our other certs are deployed with Configuration Profiles, the problem here was that the hostname mismatch isn't trusted using a profile.

[bmack99]

Sorry to dig up an old thread but have a similar question:
In essence we are needing to deploy a machine cert from our ADCS. The root CA cert is deployed as well as the cert from our RADIUS server(this is for 802.1x TLS wireless, as well as for another application)

The problem: The machine cert that is issued is installed without "Always Trust" set, thus forcing the end user to change manually(which requires an administrator password).

I've seen others in this thread solve the "Always Trust" issue by exporting the cert, utilizing composer to package and install in a temp location and then using a script to set the trust settings.

Each machine certificate is issued individually and is specific to that machine so I can't really "package it up" and deploy to a temp location.

Has anyone found a workaround to this or can anyone tell me if the command that mottertektura posted will work with an already installed machine certificate?

[rl2k05]

We are seeing the same thing as well...certs deployed by a configuration policy and they automatically are set to "System Default" instead of Always Trust...

[bradtchapman]

Resurrecting an old thread, because I started playing around with the "security" tool this evening to work on a related issue.

As it turns out, we are having this same issue where private company root / issuing certificates are already in the keychain, but with improper trust settings. In that case, you can just add them again using security add-trusted-cert . Just build a package, use the existing .cer files in a local folder, and run the same commands to import and trust them. They are now marked with the familiar blue & white cross symbol.

sudo security add-trusted-cert -d -k /Library/Keychains/System.keychain -r trustRoot ACME-Root-CA-1.cer 
sudo security add-trusted-cert -d -k /Library/Keychains/System.keychain -r trustRoot ACME-Root-CA-2.cer 
sudo security add-trusted-cert -d -k /Library/Keychains/System.keychain -r trustAsRoot ACME-Intermediate-CA-1.cer
sudo security add-trusted-cert -d -k /Library/Keychains/System.keychain -r trustAsRoot ACME-Intermediate-CA-1.cer

Note the difference in the -r flag for roots vs. intermediates.

What prompted this post and my research is that analysts have been reaching out with steadily increasing frequency because users can't renew their wireless certificate. What we've discovered is that the private root and intermediate CA's are being marked as 'not trusted' (system default). We have both root certificates and intermediate certificates. We do not use machine level certificates for network access, but we do have user certificates for things like email and VPN, and these are issued by a certificate manager (after the user supplies authentication) and are validated against the Root / Intermediate chain at time of deployment. Unfortunately there is no error message displayed when the trust chain fails, so the user and the analyst have no clue what's happening until they call us.

When we enroll a Mac, the enrollment calls a script that loads the certificates. You'd expect to be distributing a package with the certificates to a new Mac, but our file distribution points require HTTPS and are using certificates signed by our internal roots, which the new machines don't have yet and will therefore be denied a connection by the DP. Classic chicken-and-egg problem. Therefore, we need another way to load these certificates. Enter "cat" : embed the certs as base64 and cat to a temp folder, then add each one into the keychain, like so:

#!/bin/sh
certLocation="/tmp/pki/"
declare -a rootCerts=('ACME-Root-CA-1.cer' 'ACME-Root-CA-2.cer' );
declare -a intermediateCerts=('ACME-Intermediate-CA-1.cer' 'ACME-Intermediate-CA-2.cer' );
cat <<EOF | base64 -D > /tmp/pki/ACME-Root-CA-1.cer
MIIIG...           // the rest goes here
EOF
cat <<EOF | base64 -D > /tmp/pki/ACME-Root-CA-2.cer
MIIIG...           // the rest goes here
EOF
# ... and so forth ...

for cert in "${rootCerts[@]}"
do
    sudo security add-trusted-cert -d -k /Library/Keychains/System.keychain -r trustRoot "$certLocation$cert"
echo "installed Root Certificate: $cert"
done

for cert in "${intermediateCerts[@]}"
do
    sudo security add-trusted-cert -d -k /Library/Keychains/System.keychain -r trustAsRoot "$certLocation$cert"
echo "installed Intermediate Certificate: $cert"
done

[easyedc]

Throwing in my 2¢...

FWIW, I had routine issues keeping certs trusted (to the point of caching a copy of my certs locally and doing a weekly import/always trust policy). After migrating to the method of deploying via a config profile built with Profile Manager in the Server.app, my issues cleared up. I did this a few years ago and haven't looked back. I highly suggest that method.

[mkalayaboon]

@easyedc - I've been living in the old world mate. Thanks for your comment as it's a game changer for us! Cheers

[MarcusHolland]

Without deploying a computer configuration profile, I found that I was able to toggle "Always Trust" at the parent level on an imported CA certificate by using all policy constraint options in the command line e.g.

security add-trusted-cert -d -r trustRoot -p ssl -p smime -p codeSign -p IPSec -p eap -p basic -p swUpdate -p pkgSign -p pkinitClient -p pkinitServer -p timestamping -u -1 -k /Library/Keychains/System.keychain /etc/$ca.pem
security add-trusted-cert -d -r trustAsRoot -p ssl -p smime -p codeSign -p IPSec -p eap -p basic -p swUpdate -p pkgSign -p pkinitClient -p pkinitServer -p timestamping -u -1 -k /Library/Keychains/System.keychain /etc/$ca.pem

We were previously only using a few policy constraints, which would always result in the "custom" trust level. It took me a while to click to this so I thought I would share it here. Obviously MDM profiles are a more "official" way to crack this nut, and policy constraints should be set appropriately.

Thanks all!

[lfcsatech]

I've found what is working for me, don't know if it will keep working. I'm using a Comodo wildcard, so I'm sending the .ca-bundle as well (had to change the extension to .cer for it to upload). It shows up as trusted.

[amosdeane]

Just reviving this thread again.... @bradtchapman that is an interesting solution to deploy certificates.

Just to clarify. I am thinking that you’re running a command on the original certificate to get them into a format to embed them in? e.g. EOF will not be able to parse a pasted version of the encrypted certificate as visible in textWrangler etc, so the certificate has to be processed via openssl or similar, first and then inserted as below?

cat <<EOF | base64 -D > ./new_certs_folder/ACME-Root-CA-1.cer
My Embedded certificate text goes here
My Embedded certificate text goes here
My Embedded certificate text goes here
EOF

[bradtchapman]

Yes. The certificates must be in base64 encoding for transport within a script.

To get them into this format just use the base64 command:

base64 -i <in-file> -o <outfile>

Here, “in-file” is your DER (binary format certificate), and “out-file” will be the resulting text.

[amosdeane]

Many thanks @bradtchapman for clarifying! (since posting the original query I've managed to forget all about this but I will go over my notes and I'm sure this will be very helpful! :) )

[amosdeane]

I've now revised this and it makes perfect sense. Thanks again as this is a very helpful solution for deploying certificates without packaging.

[dswitmer]

I'm having a little trouble following. I am able to deliver the cert with the configuration profile. What's my best option to make it trusted after the fact? Or should I go about it a completely different way? thanks for the help.

[achristoforatos]

@dswitmer In the same boat as you. Running Mojave and can't seem to get it trusted. Let me know if you come across a solution please!

[achristoforatos]

@dswitmer Found that my script should have had trustAsRoot instead of trustroot

[ArmchairDeity]

This thread was so helpful I created an account just to say thank you! I have a script of my own that I'll link here because it's very much based on your work and I want it to be in a place where it can help people. Still in moderation, I'll share it as soon as I have the link. :)

[jweiss]

Our ClearPass Radius expires at the end of the month. We've not deployed this via Jamf before. When I joined the org it was setup to be user initiated. I wanted to change this with the cert expiring to make it seamless to our users. However we I deploy the cert via a config profile whether it be at the user or system level it is not imported as trusted therefore requires the user to trust the cert upon entering AD credentials. I am trying to follow this thread on what to do next but honestly I am lost!

[user-nrEKyEeSDZ]

How deploy this for "Device cert sepcific" Always Trust option

[pvcit]

Well you can no longer do it cmd line in mac os 10.15+ without the user prompted and putting in username and password. You are supposed to do it from a config profile with someone mentioning that you should first import the certificate into your keychain and mark it as trusted, then export that "trusted" certificate and upload that one to jamf and deploy with a configuration profile. Mine used to work when I did this but after a certain jamf upgrade a few version ago it does not seem like it works. Wish a checkbox just existed.

[Jason33]

@pvcit Having the same issue, with a wireless cert that I want to deploy - export the trusted cert, add to config profile and deploy to a machine, and the user has to trust it. A different cert that I deploy, ironically, still gets trusted when deployed to machines via config profile.

[jamserver]

Few years down the line but this issue still exists.