So our first non-wizard type script has us attemptoind to deploy a trusted root certificate to our users that our WebFilter uses. I think I need to send certmgr.exe and the .cer to all the machines then run a .bat that runs cermgr.exe with the following: certmgr -add -c gmcs-websense.cer -s -r localmachine root. That being said, it is the first time Im using KACE to automate this and the scripting is not as intuitave as Ide like. Do I add the files ad dependencies? do I upload them to a netshare then just call the bat form each workstation, and how do I do that? noob here.

Rating comments in this legacy AppDeploy message board thread won't reorder them,
so that the conversation will remain readable.

0
This is not an easy problem for reasons entirely unrelated to the KBOX. There is an entire industry devoted to the secure distribution of certificates, but the KBOX should be able to do this task with some level of assurance the certificate that was installed is the one you expected.

Why is deploying a trusted root certificate in a secure way is tricky regardless of which tool you use? You will want to make sure that the certificate has not been tampered with on the client prior to the script running, and then verify that the proper certificate was installed. If this doesn't happen, the very purpose of the certificate is defeated.

In fact, there is a case to be made that there is no secure, automated way to deploy certificates without an actual human being verifying the certificate on each machine it's deployed to. If you are concerned about security to this extent, I encourage you to use the KBOX User Portal, in combination with KBOX Scripting, to actually have the user trigger the process and confirm the signature of the cert while it's being installed.

If you still want to keep end-users out of the equation, you're on the right track with a batch file, but you could just call certmgr from the "Launch Program" function as well. Having the certificate as the dependency to the script is also a good idea, but in your "verify" section you will not only want to verify that the file is there and exists ($(KACE_DEPENDENCY_DIR)/websense.cer is the path you'd use), but that some signature value of the file is what you expect. How you would do that is to run the signature program in the Verify section of your task--something like md5sum--in a batch file which is verifying the value for the md5 (or whatever you're using to confirm the identity of the certificate) to what you expect and creating a file (something like$(KACE_DEPENDENCY_DIR)/CERT_MATCHES)) if it's all right. You'd then having a subsequent test in the "Verify" section for that file's existence. Unfortunately, the KBOX doesn't check the exit values of batch files or programs you run using "Launch Program" in the "Verify" section, if you're thinking of just doing that. That's why you have to create some kind of semaphore for verification.

Here's what else I think you should do, off the top of my head.

- turn KBOX SSL on with a signed public certificate to ensure that the data is not modified in transit.
- Have some way of taking a signature of the certificate and comparing it to the value you expect. On a Unix box, I'd just use md5 or some sort of built-in command like that. You may need to deploy such a tool prior to doing the deployment.
- Create a custom field which takes inventory of the certificate in some way. KBOX 5.0 supports custom fields which are just the standard output of some command or batch file. I'd probably File Sync down a batch file which does something like

certmgr -put -c -n websense -s root "C:\Program Files\KACE\KBOX\websense.cer"
md5sum "C:\Program Files\KACE\KBOX\websense.cer"

and then create a Custom Field which runs the batch file, something like

ShellCommandTextReturn(C:\The\Path\to\my.bat)

And make reports to look for anomalous or missing values.

You may even want to have that batch file check for all the certs in a root store, because it's conceivable that your cert was installed, but so was another one which you didn't expect.

Messing with trusted root certificates is a tricky business, because you have to ensure the integrity of the certificate throughout the chain, as well as at the endpoints.

Good luck!