GroundWork Monitor supports the use of HTTPS using TLS for encrypting web browser connections to Apache, although this feature is not enabled by default. The binaries and libraries necessary to enable HTTPS support are included in the GroundWork Monitor distribution. Also see sections for GDMA Notes.
WAS THIS PAGE HELPFUL?
To setup HTTPS in GroundWork you will need to run the setup-https.py script found in /usr/local/groundwork/tools/system_setup/.
|You will need to be root or run via sudo given the nature of some of the tasks performed.|
The script will set the system up with a certificate corresponding to the current FQDN of the system. Because daemons are restarted during this process it can take some minutes to complete. If you are planning on doing self signed certificates on a standalone GroundWork system then you can run this script without any flags:
- To not setup a port redirect from 80 to 443 you can use the --nodirect flag:
- To use your own provided certificate:
A backup of the configuration files modified by the setup-https.py script created at /usr/local/groundwork/backup/DATESTAMP-pre-https-config-backup.tgz. For example:
A log of the operation run by the script can be found in the same directory at /usr/local/groundwork/tools/system_setup/logs/setup-https.log. Refer to this log file if something didn't work as expected. If you need to open a support ticket, attach this file to the ticket.
In the event you need to roll back the changes done by this script you can run the grafbridge-control script, restore the backup file, and then restart GroundWork again:
- Run the grafbridge-control script to disable https in the respective config locations:
Because some APIs are communicated within this step, it is required GroundWork be up and available at the URL configured the previous time it was run (e.g., by the setup-https.py script). You MUST have restarted GroundWork prior to running this step again or it will fail. If a restart of GroundWork has occurred but this step produces errors you will need to run the following command to correct it:
- Restore the backup file found at /usr/local/groundwork/backup/DATESTAMP-pre-https-config-backup.tgz.
- Restart GroundWork daemons:
Because of recent changes to browsers, such as FireFox and Chrome, certificates are now required to have subject alternative name (SAN) fields. Self signed certificates created with instructions from previous versions of GroundWork will work with 7.2 but will not validate in these browsers because they lack these fields. The OpenSSL cli tool does not prompt for this field to be added so we have wrapped it in a shell tool.
- If you need to regenerate certs or create certs for child servers it is advised to use this tool on the parent so that a single self signed CA is all that needs to be distributed.
- make_cert.sh when run without arguments will generate a new CA certificate and a new certificate for the current short hostname signed by that CA. (If they exist it will not overwrite them without the -f flag to force.) Because certificates are used to convey the identity of the host, it is good practice to reduce ambiguity and use the FQDN of the host that will be used in the browser.
- To create a certificate for the child server you can do this with the -h flag:
The certificates will be created in /usr/local/groundwork/common/openssl/certs:
and key will be created in /usr/local/groundwork/common/openssl/private:
- This is the same tool used by setup-https.py to create certificates.
- The grafbridge-control script requires restarts of GroundWork between changes to the API endpoints. This includes changes to/from HTTPS.
- make_cert.sh is used to generate self signed certs. Should be reused on the parent for child server certs.
- Certificates need to have SANs in order to validate in modern browsers.
- Look in the log file if things go bad.
- GDMA Plugins
When using HTTPS and downloading GDMA plugins, if you provided your own certificates the hostname used to access the system must exactly match what is in the server's SSL certificate. For more information regarding downloading new GDMA plugins see the Bookshelf document GDMA Advanced. Also see Using GDMA with HTTPS.
- GDMA Version
If you use an old version of GDMA and need to transition to the current version you the --noredirect flag will setup an incompatible configuration as they leverage the port 80 to 443 redirect in their discovery. You can change this by rerunning the setup-https.py script again but passing the --redirect flag to override the stored settings from the previous run. Once you have migrated to current versions of the agent you can rerun again with the --noredirect flag should you wish to only listen on 443.