@Gabor said in better web performance?:
Really fog clients and pxe boot is secure even on http?
As George already said, fog-client communication is encrypted and save but PXE boot over HTTP is not. So unless you use join multicast sessions or other PXE menu things that ask FOG credentials you don’t need to worry.
I will try it in a test environment with a new vm server , then I just have to figure out how to reinstall the FOG clients to connect them to the new server.
I don’t use the fog client in my environment, but if you were to look into the fog client directory on the target computer, I bet you would find the certificate it downloads from the FOG server. One might think you could swap that certificate with one from the new fog server and live happily.
Not that easy, sorry. The cert is being installed into the Windows certificate store. So you’d need to find a way to remove and install certs from that using some kind of automated way. Doing it manually for 100 clients is a nightmare. There have been a few people in the forums trying to automate this but I think we never got any detailed feedback on how they did it, see 1, 2, 3. I have too many other things on my list and never really looked into this myself.
What if I inject my own key,crt,ca files at this point of the installation and enable https as in the first install?
I haven’t looked at the installer scirpt, but I bet it calls openssl to create the certificates. If one would short circuit that code and slip his/her enterprise certificates in its place, would the fog installer know any difference?
While it might work for PXE boot this would surely break the fog-client communication. As described in the wiki the current fog-client code checks the common name of the certificate to be FOG Server CA
. I am fairly sure not too many CAs will allow you to generate a sub CA using that CN (common name). I know this is not good practice but it’s not me who came up with this initially and I have thought about different ways to get away from this. Sure we could remove that restriction and allow for any certificate to be used by the fog-client. I am open to discuss this with all of you. Though on the other hand I am questioning the secure encrypted communication over plain HTTP altogether with HTTPS becoming state of the art more and more. But moving FOG and the fog-client to be HTTPS only and remove the internal encryption is a major project which I don’t have the time to right now.