Root certificate import and change to "Always Trust"

[ds_support]

Hello, we have a root certification, since a few days I try to deploy it to a mac (At the moment I do it with a configuration profil) and change it then to "Trust Always".

How I can change the trust to "Trust Always"? Use all browser the keychain for the ssl certification? Because this certifcation are used on a website.

Many Thanks for help!
Christian

[kunkelb]

What I've done to install the certificate for our webfilter is as follows. I'm sure there's a cleaner, more graceful way to do it, but this is working for me just fine.

1. Put the certificate into a package with Composer.
2. Deploy that package to the computers on startup.
3. Create a script as follows:

#!/bin/bash

sudo security add-trusted-cert -d -r trustRoot -k /Library/Keychains/System.keychain /path/to/certificate.ext

1. Have that script run on login. Since it's a root certificate, you can have it run once per computer.

It breaks up the deployment of the certificate and the script to make sure the certificate has a chance to deploy before trying to install it on the computer.

Hope that helps!

(edit: you can put in a command to execute on the same policy that deploys the certificate, too -- I've just had less luck that way. I don't mind a quick extra step if it helps me make sure it ran correctly the first time.)

[ds_support]

Many Thanks for your help!

It works! I create a package with the certificate. After the certificate is deployed I start the script to install. Have anyone a idea how I can do this two steps in one policy? I try it but he deploy only the certficate and don't run the script...

many thanks

[mjsanders]

I have no time to test, but I think that any certificate in a profile sent by MDM will be 'trusted'.
Is it a self-signed root certificate? that may be different.
Is it a device or user profile? Maybe user profiles are not trusted?

[kunkelb]

Yeah, we had to go this way because our webfilter gives a .pem certificate which can't be installed via a configuration profile. At least, in no way that I've found.

c.knipping, you could add the command from the script (minus the "sudo") into the policy under Files and Processes -> Execute Command, but I've found that sometimes it tries to execute the command before the profile is in place, leading it to say "well, guy, that file just doesn't exist, now does it?" and then I feel bad.

[achristoforatos]

How do you find the path to cert after system.keychains?

[achristoforatos]

Any updates to this on computers running Mojave?

[nebakke]

How do you find the path to cert after system.keychains?

That's the cert that you're importing - it's assumed that you would know where that cert is as you would probably be placing it there yourself :)

Any updates to this on computers running Mojave?

Works the same on Mojave - well it does for us anyway.

[lpierce]

You should test marking them with full trust in the keychain, exporting to .cer, and then uploading them in the JSS with a configuration profile. My experience is they retain the full trust setting. Apple is adding some type of attribute to the .cer file, the security command is not necessary in my testing.

[cbd4s]

You should test marking them with full trust in the keychain, exporting to .cer, and then uploading them in the JSS with a configuration profile. My experience is they retain the full trust setting. Apple is adding some type of attribute to the .cer file, the security command is not necessary in my testing.

@lpierce I don't think this is the case. If the certificate is installed by Computer Level Configuration Profile, it just installs it into the system keychain. Setting this certificate to Always Trust in keychain requires the actual user credential as it is to make it trusted by that particular user, not any user on that machine. So it will only stay trusted for that same user if removing the certificate and redeploying it by the configuration profile.

The easy way to test this out is changing the certificate back to Use System Defaults (requires the user credential) and then remove the certificate (requires admin credential). Then deploy the certificate by the configuration profile again. The certificate will be imported with Use System Defaults rather than Always Trusted.

[sdagley]

@cbd4s My experience matches what @lpierce describes - if I export a Root CA that's marked as always trusted to a .cer, and then upload it to my JSS and deploy as a Computer Level Configuration Profile it installs in the System Keychain as always trusted.

[cbd4s]

Thanks, @sdagley , my understanding on how certificate works is limited. But I've done some more testing and here are the corrections to some of my previous comment and more details on my experience:

1. The certificate I'm trying to deploy to the system keychain is issued by an intermediate certificate authority. So it's my bad that I'm a bit off the OP's topic here as it is not a root certificate.

2. Even with that intermediate CA certificate is trusted, its issued certificate doesn't get automatically trusted after added to the keychain.

3. When System keychain is locked, manually importing the certificate requires local administrator's credential for keychain access to modify the system keychain. The certificate then is added to the system keychain with Use System Defaults trust settings. System keychain remains locked. Then making this certificate Always Trust requires local administrator's credentials for making changes to the System Certificate Trust Settings. Then if I try to delete this trusted system certificate, local administrator's credential is required twice (the first one for keychain access to modify system keychain which will also unlock the System keychain, the second one for removing the custom trust settings). After the deletion, the System keychain will be left unlocked. Obviously because the trust settings got reset to system default, reimporting the same certificate will have the same system default trust settings rather than Always Trust.

4. When Jamf deploys the same certificate (regardless if it was exported as trusted or not) through configuration profile, it initially gets added with Use System Defaults trust settings. I then manually make it Always Trusted. Then I remove the machine from the Jamf configuration profile deployment scope so let Jamf do the certificate deletion from the computer's system keychain. The certificate disappears from the system keychain automatically (without resetting the custom trust settings). Then I add the machine back to the configuration profile scope. This time the certificate is added back with the Always Trust setting retained. If I manually delete the trusted system certificate from keychain, redeploying it through Jamf configuration profile will still have just the system default trust settings.

5. So what I'm looking for is how to deploy a new certificate (not necessarily root certificate) with Jamf configuration profile and make it Always Trusted automatically.

Hope that makes sense.

[sdagley]

@cbd4s The short answer is you can't. For a certificate to be trusted you need the full chain to that certificate to be trusted. That's why installing an Intermediate CA without the corresponding Root CA doesn't work. When you install a Root CA that's trusted, the trust transfers to Intermediate CAs associated with that Root CA. If you just install the Intermediate CA there's no basis for trusting it.

[cbd4s]

@sdagley Thanks. That is interesting as we actually do have the root CA certificate deployed and it is trusted. But the intermedia CA certificate for whatever reason is not. I will do some more testing on this.

But coming back to the point 5 in my previous comment, I've now used the alternative Jamf policy approach to deploy the packaged certificate to a folder on the computer and a postscript in that package to import the certificate as trusted: sudo security add-trusted-cert -d -r trustAsRoot -k /Library/Keychains/System.keychain <.cer certificate file path>

It worked well.

[sdagley]

@cbd4s It's fortunate that avenue exists for certs installed via script, but it's not an option if you're pushing certs via Configuration Profile.

[pvcit]

Cannot really deploy with a script in big sur at all now, as they locked it down and require a user to put password in. I was able to get my first batch of certificates trusted by exporting them from keychain as trusted, but the newest one I tried does not work. They really just need to add trust settings (either jamf or apple).

[mschroder]

For Big Sur you need to install the Root Certificate via a Configuration Profile. This is even easier to implement than via a script. Just put in the certifcate into the Profile, scope it and you are done.

[Louie]

@mschroder , but with full trust and not just valid?

[mschroder]

Good point, I see them marked as 'valid' with trust 'System default'. But how do I know what the system default is? Seems I need these certs less than in the past, I have a hard time finding a server to test this against...

[JamieG]

Interested in the answer to this, certificates that I push from Jamf via Configuration Profile for both macOS and iOS (14) are still not trusted by the system. Clearly there is a means for doing this because the JAMF JSS self signed cert is indeed seen as trusted.

[sdagley]

@JamieG For a cert you're pushing via a Profile to be trusted you'll need the trust chain of that cert to be trusted as well.

[JamieG]

@sdagley that’s the weird thing - I already am pushing both the RootCA and the issuingCA. I haven’t bothered with individual sites I assumed they’d be OK. Is that not the case?

[sdagley]

@JamieG Are the Root and Intermediate CAs you're pushing showing as trusted?

[JamieG]

On iOS - I’m not sure how to check if they are trusted. I only see them in the MDM profile under certificates. But visiting any TLS site signed by them shows untrusted.

For MacOS (big sur) I have pushed by both computer scope and user scope, neither are trusted by the user by default. They have to manually change the trust. This might be a big sur thing. The iOS problem is the main blocker at the problem as I can’t find anywhere to trust them (and I shouldn’t have to...).

For IOS, The only cert in the ‘Trusted roots’ area of certificate trust settings is the self signed tenant JSS cert.

[sdagley]

@JamieG I can't offer any advice on iOS certificates, but I can tell you that the Computer Level Configuration Profile we push to Macs in my org with the org Root CA and a couple of Intermediate CAs works fine in Big Sur. The Root CA installs as Always Trusted, and the Intermedia CAs all receive Use System Defaults for Trust so the trust on the Root CA conveys to them.

[JamieG]

I can’t imagine what’s different with ours then. We are using configuration profiles, there are certificate payloads both with the base64 encoded certs, one for root, and the issuers.

We are using jamf cloud, and there is no integration with our ADCS.

Can you think of any reason why that would prevent the config profile from doing as expected?

[JamieG]

Another few bits - the certs are ECDSA (not RSA). I wonder if there’s some process that breaks if that’s the case.

[sdagley]

@JamieG Have you tried one configuration profile with a single certificate payload for all certs? Have you verified that Keychain Access can import the cert files used to create your certificate payload?

[JamieG]

Narrowing down on my issue - for some reason, our RootCA, is not recognised by macOS as a Root (e.g. the orange certificate), instead it's recognised as an Intermediate... (blue certificate)

I have no idea why this is happening, but that would make sense for the rest of the problems.

So what makes a root a root? It's seen as it's own issuer etc.. and we haven't seen any issues in our Microsoft AD world.

[sdagley]

EDIT: Removed non-useful suggestion

[JamieG]

Got to the bottom of the issue - turns out our RootCA was using specifiedECDSA which a lot of stuff doesnt like, changed it back to sha384ECDSA as it should have been (not the MIcrosoft frig on it)