Web interface SSL

Tom Elliott

Both of these already exist.
https://github.com/FOGProject/fogproject/issues/120

Look at ./installfog.sh --help to see all the arguments you can pass.

astrugatch

https://github.com/FOGProject/fogproject/issues/120

Is there a way to add a cert post install that will survive updates or will I need to run the installer again to add my cert?

Does the modifier take both the .key and the .crt?

astrugatch

-c    --ssl-file		Specify the ssl path
	               		defaults to /opt/fog/snapins/ssl

I see this in the --help does the cert need to have a particular name or will any *.crt be recognized?

Tom Elliott

@astrugatch It works only for the private key.

The full setup, however:

Usage: ./installfog.sh [-h?dEUuHSCKYXT] [-f <filename>]
                [-D </directory/to/document/root/>] [-c <sslPath>]
                [-W <webroot/to/fog/after/docroot/>] [-B </backup/path/>]
                [-s <192.168.1.10>] [-e <192.168.1.254>] [-b <undionly.kpxe>]
        -h -? --help                    Display this info
        -o    --oldcopy                 Copy back old data
        -d    --no-defaults             Don't guess defaults
        -U    --no-upgrade              Don't attempt to upgrade
        -H    --no-htmldoc              No htmldoc, means no PDFs
        -S    --force-https             Force HTTPS for all comunication
        -C    --recreate-CA             Recreate the CA Keys
        -K    --recreate-keys           Recreate the SSL Keys
        -Y -y --autoaccept              Auto accept defaults and install
        -f    --file                    Use different update file
        -c    --ssl-file                Specify the ssl path
                                                defaults to /opt/fog/snapins/ssl
        -D    --docroot                 Specify the Apache Docroot for fog
                                                defaults to OS DocumentRoot
        -W    --webroot                 Specify the web root url want fog to use
                                                (E.G. http://127.0.0.1/fog,
                                                      http://127.0.0.1/)
                                                Defaults to /fog/
        -B    --backuppath              Specify the backup path
              --uninstall               Uninstall FOG
        -s    --startrange              DHCP Start range
        -e    --endrange                DHCP End range
        -b    --bootfile                DHCP Boot file
        -E    --no-exportbuild          Skip building nfs file
        -X    --exitFail                Do not exit if item fails
        -T    --no-tftpbuild            Do not rebuild the tftpd config file
        -P    --no-pxedefault           Do not overwrite pxe default file
        -F    --no-vhost                Do not overwrite vhost file

What might work better is for you to create your own type of “fog.conf” file and install with the -F or --no-vhost switches. This way you don’t have to worry about updates breaking/potentially losing your cert information.

astrugatch

@tom-elliott

So if I put my domain cert.key file in /opt/fog/snapins/ssl and use the -S and -c modifiers would that take my cert?

If that doesn’t work I’m OK with making my own conf file, I’m just trying to make this as hand-offable as possible so someone doesn’t need to know a ton of unique specifics to work with my environment.

Tom Elliott

@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.

astrugatch

@tom-elliott

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?

Tom Elliott

@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.

gn_ro

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…

astrugatch

@gn_ro

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.

george1421

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.

astrugatch

@george1421

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.

gn_ro

@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).

astrugatch

@gn_ro

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?

gn_ro

@astrugatch We are booting and imaging over the internet.

Web interface SSL

139

11.7k

17.2k

154.7k