Web interface SSL
-
@astrugatch setting your private key would not help much if you’re requiring specifics. The -S would force https I believe and -c would inform what private key to use, but it wouldn’t specify the server ca as the authority and would likely break the fog client. It’s for this reason I would recommend creating your own vhost file. Or you could sign your crt using the servers ca? But doing your own file I think would be the sinolest, just document it and why. In the near future we hope to be able to do away with the ca but for right now it’s kind of needed.
-
Using my key isn’t really a high priority as only I and the other admin will be using it so self signed is OK.
On the install process for self signed is it just -S and -c or is there something else I need to do for the installer to generate its own key?
-
@astrugatch all -S does is setup the vhost file so it will redirect to requests to https. The -c specifies which private key to use. If you need the installer to create keys for you, you can use the -K switch, and if you need a new CA you can use -C switch.
The installer already creates the keys for you by default, and the fog client looks for the servers CA key for validating the client is talking to the proper server.
If you want to use your own self signed cert, I might recommend using the servers CA so it works with that being the only difference you use.
As we do create the keys, if you’d like to use the fog generated key, the installer can just be ran with the -S argument. The only thing is recommend for that case is to import the ca cert so you dont have the self signed error. Machines with the fog client installed should see the green padlock as we do import the ca as I said earlier.
-
First sorry for posting in such an old topic, but:
Maybe is not that hard to integrate Let’s Encrypt free ssl certificate in the installer as an option to the self generated certificate?
Maybe just for the web interface and maybe at a later time for compiling ipxe… -
You would need to face your FOG Web UI to the internet to do that (Lets encrypt requires access to port 80). And doing that is not recommended by the FOG team.
-
While I really haven’t thought about this too long, but ssl certificate would imply using https, and https runs on port 443.
So if you enabled https when installing FOG then port 443 is occupied. But if you installed fog without https option then port 443 is available.
So we have two distinct functions here.
- Web interface for managing fog
- Web interface for internal fog communications
If the goal of using lets encrypt for all internal fog communications then the issue is with the fog client and the certificate used when compiling the fog client woudn’t match the external certificate. If you don’t use the fog client then it should be possible to use an external certificate with FOG. Because now we are only dealing with iPXE and the web server.
If your goal with is to use letsencrypt certificate for FOG management then we can create another virutal web server using a different port (like 1443) and attach the certificate to that interface. All of the fog clients and internal communications would not see or know about this interface so they would continue to function as intended by the fog designers.
-
I’ve long since moved away from the third party cert idea especially since I use the client heavily. I only responded because @gn_ro bumped this. The main issue with their request is that the main feature of lets encrypt is the automatic renewal which only happens in one of 2 ways. either a DNS update which you would use if you were generating a wildcard cert or through an http challenge. The http challenge is ONLY accessible over port 80 direct to the internet, which would mean exposing the fog web UI to the internet. As I’ve understood it this has been discouraged by the Dev team for security reasons.
-
@astrugatch We’re using a fog server reachable over the internet with all internet blocked and with permission to all services only from our sites. It’s not easy to update when a site changes it’s ip addresses but it’s working good so far. We have other services running this way using ssl from let’s encrypt (they have about 4 ip’s if I remember correctly).
-
What services are you making available over the internet? Just the web UI? Or are you imaging over the internet?
If its just the web interface are you putting it behind a proxy?
-
@astrugatch We are booting and imaging over the internet.
