Allow agents to connect via reverse proxy using publicly trusted certificate
With the KONEA revision for the agents the KOENA SSL certificate is being used for agent communication back to the K1000. This is a self signed certificate issued by KONEA to KONEA.
If you install a publicly trusted certificate for your K1000 URL in your reverse proxy, the user/admin portal and the mobile app work fine. However, the agent continues to require the self signed certificate and will not connect to the K1000 using the trusted certificate.
Why not allow the agent to use standard SSL certificate stores for communication instead of the self signed certificate?
This will become obsolete in 11.0. We are going to route all agent communications via the Konea tunnel which uses the Konea self-signed cert. Therefore, SMA certificate will be irrelevant.
Garrett Michael Hayes commented
This "Decline" makes no sense. It is the self signed cert which is the PROBLEM. It cannot be deployed to a reverse proxy server.
If this is your "solution", then I believe you have fundamentally misunderstood the issue.
Justin L. commented
We're experiencing the same issue. Has anyone discovered any additional/relevant information/clarification regarding this, or is it even on their development roadmap for being addressed?
Danny Arroyo commented
Having the same problem in our environment. We are running v10.1 on our Virtual Kace SMA. I tried to put the SMA behind our F5 Load balancer (which has reverse proxy capabilities). In addition, I added a third party certificate from Entrust. In my experience, the Admin Portal still complained with a certificate warning (going direct to the SMA). My devices outside of our network (no VPN) were able to update their inventory, but the devices were not connected. In the Konea log for my test devices, I saw the messages concerning the self signed Konea certificate ("err":"x509: certificate is valid for kace.mycompany.com, not konea"}). Prior to starting this process I opened a Ticket with Quest support. I was told that it is not recommended to put the SMA in the DMZ (which I havent tried yet) but it should work. I then asked about placing the SMA behind a reverse proxy and I was told that it should work. I dont think Level 1 support knows about this issue. I escalated the call and hope to speak to level 2 or 3 for clarification.
Having no solutions for a reverse proxy so the KACE SMA can manage non-networked devices without compromising our security is leaving us with no other option other than looking for another MDM solution other than KACE.....
Garrett Michael Hayes commented
This is absolutely essential. The Quest implementation adviser even TOLD us that putting the SMA behind a reverse proxy would work.
Now after months of digging down to the WireShark packet capture level, to find out that the product design doesn't permit it is simply unacceptable.
Jason Webb commented
When attempting to connect via a Citrix ADC reverse proxy we have the same outcomes. Would love to see a solution, as placing the SMA directly on the perimeter is not desired.
Hi JTuran, did you ever find a solution to this issue? We are running into the same problem using haproxy as an HTTP reverse proxy. The webui works fine but the agents are not accepting the certificate as they are expecting the konea self-signed certificate. We are running the latest KACE version 10.1 and almost 3 years later this hasn't even been looked at...