For testing KBOX, I have a couple workstations not in use and joined to my production domain. In order to test the remote agent install, software deployment, etc I need to use privileged credentials. Why would you guys disable SSL for the trial version? (openssl -> open source)

This creates an unnecessary hassle of working around this because the communication to the KBOX admin page is insecure.
0 Comments   [ - ] Hide Comments


Please log in to comment

Rating comments in this legacy AppDeploy message board thread won't reorder them,
so that the conversation will remain readable.
Answer this question or Comment on this question for clarity


When you turn SSL on for a KBOX, you not only turn it on for the console, you turn it on for all the agents. This means that each agent's operating system has to trust the certificate installed on the KBOX. The means either buying a trusted-CA-signed certificate, or installing a self-signed certificate on every computer you're testing the in the KBOX.

Not many customers are willing to shell out for a CA trusted certificate for a trial. Even if they are willing to use a KBOX-generated self-signed certificate, it's work to get the certificate into the trusted store on all the workstations that you're going to be testing.
In the hundreds of trials that we've done since we've shipped the trial KBOX, we've had exactly two requests for SSL.

So, the answer is that we turn it off in Trial KBOX for simplicity's sake. This reduces our support costs during the trial, since it prevents unsophisticated users from accidentally turning it on.

Prospects who require SSL are accommodated through our evaluation process, which requires a bit more paperwork on the prospect's side, but a bit of paperwork should be a hindrance if you're not worried about the certificate distribution problem.

So, if you have need to evaluate SSL, talk to your sales rep.
Answered 02/19/2010 by: jkatkace
Purple Belt

Please log in to comment

Thanks for the explanation... and that makes sense as to why it was disabled.

This appears to be a design limitation more than anything, imo. The KBOX needs either an issued or self signed cert (SSL browser based administration). The clients should not rely soley on certs for encrypted communication to and from the KBOX... meaning that there are other ways to perform secure encrypted communications between the KBOX and it's clients that does not involve client certs.

The service is top notch with KACE. The sales rep is working on a solution that will meet our needs.

Answered 02/19/2010 by: v2Paul
Yellow Belt

Please log in to comment
Self-signed certificates are, in themselves, a security hole if they are not physically imported into the trusted cert store of the machine through a secure process. The KBOX agent will refuse to talk to a KBOX which does not have a certificate which is not signed by a trusted root CA. The only way around that is to put the self-signed certificate in the trusted store itself using a secure mechanism.

If we did what you requested without following standard PKI trust procedures, it would not be secure. You wouldn't like that, either. :-)

Thanks for the kind words.
Answered 02/22/2010 by: jkatkace
Purple Belt

Please log in to comment