Enportal/5.5/admin/ssl configuration
Overview
For security reasons it's recommended to run AppBoard over SSL (Secure Socket Layer). This will ensure all communications between clients (browsers) and the AppBoard server are encrypted.
By default enPortal is configured with SSL disabled, but it does ship with a self-signed server certificate and can easily be enabled. In production environments this certificate should be replaced with one issued by a known Certificate Authority (CA) or one signed by a trusted root certificate within the organization.
Configuring enPortal for SSL
To enable HTTPS (HTTP over SSL) mode use the HTTP_SSL runtime option and set it to true. In addition you may want to also change:
- HTTP_PORT: HTTPS is typically served on port 443
- KEYSTORE_FILE: if using your own certificate
- KEYSTORE_PASS: if using your own certificate
- KEYSTORE_TYPE: if using your own certificate
See the Runtime Options page for more information on these settings and how to configure them. After making any changes then restart the enPortal service.
Process Overview
The basic process is:
- pick a Certificate Authority, this may be in-house if the organization has a Standard Operating Environment with their own root certificate installed on all systems. Otherwise this would be a commercial CA such as VeriSign, Thawte, or Go Daddy.
- create a Certificate Signing Request (CSR)
- have the CA sign the request
- download the signed certificate from the CA. Depending on the CA a variety of formats may be on offer. Choose an appropriate format for Tomcat - which the CA may explicitly list as an option, otherwise choose PKCS#7 format. Other formats may require additional conversion steps before Tomcat can make use of it.
- create a Java KeyStore (JKS) file for Tomcat and install on the enPortal server.
Another option is to generate a self-signed certificate to replace the self-signed certificate Edge ships with enPortal. However, end-users will still be presented with certificate errors and warnings.
Creating Certificate & Keystore
For SSL Tomcat requires a Java KeyStore (JKS). The keystore needs to contain the private key, the signed certificate, and any intermediate certificates from the CA. To create and work with a keystore it is necessary to have Java installed and be able to run the keytool command.
The recommended approach is to use keytool to create the private key and CSR and keystore all in one go, then have the CA sign, and then import the signed certificate directly into the keystore. Most CAs will have documented this process which can be followed such as these from VeriSign:
- creating a CSR and submitting for signing (using keytool and creating a keystore in the process).
- importing the signed certificate into a JKS keystore (in PKCS#7 / .p7b format)
- Then follow the instructions below on Installing the Keystore.
A limitation of keytool is that existing private keys cannot be imported. So for situations with an existing private key, and regardless of the certificate format then it will be necessary to use openssl to do conversion.
For existing private key with signed certificate and intermediate certificates in X.509 format follow these steps:
- Convert the private key (private.key), signed certificate (server_signed.crt), and intermediate certificates (ca.crt) into PKCS#12 format:
- openssl pkcs12 -export -in server_signed.crt -inkey private.key -CAfile ca.crt -caname root -chain -out combined.p12 -name your-alias
- You will be prompted to set a password, this must be set - do not leave blank. If you do not have any intermediate certificates then leave out the -CAfile, -caname, and -chain options.
- Create a JKS from the combined.p12 file generated above:
- keytool -importkeystore -srckeystore combined.p12 -srcstoretype PCKS12 -alias your-alias -destkeystore your-keystore.jks
- You will be prompted for the password set above and a new password, you must use the same password. your-alias must match the alias set in step (1).
- Take the resulting JKS file (your-keystore.jks) and follow the instructions below on Installing the Keystore.
For existing private key with signed certificate and intermediate certificates in PKCS#7 (.p7b) format follow these steps:
- Convert the PKCS7 file (certs.p7b) to PEM encoded certificates:
- openssl pkcs7 -in certs.p7b -inform DER -print_certs -out certs.crt
- Convert the private key (private.key) and certificates (certs.crt from above):
- openssl pkcs12 -export -in certs.crt -inkey private.key -out combined.p12 -name your-alias
- You will be prompted to set a password, this must be set - do not leave blank.
- Create a JKS from the combined.p12 file generated above:
- keytool -importkeystore -srckeystore combined.p12 -srcstoretype PCKS12 -alias your-alias -destkeystore your-keystore.jks
- You will be prompted for the password set above and a new password, you must use the same password. your-alias must match the alias set in step (1).
- Take the resulting JKS file (your-keystore.jks) and follow the instructions below on Installing the Keystore.
Installing the Keystore
Once a valid keystore has been created it can be installed on the enPortal server:
- copy to the [INSTALL_HOME]/server/conf/ssl.crt/ directory. By default files in this directory are automatically included in full archives.
- Edit setenv-custom.sh|.bat and update the KEYSTORE_FILE, KEYSTORE_PASS, and KEYSTORE_TYPE as required. If using the instructions above then the type should not need to be changed. Please note the keystore file path is relative to [INSTALL_HOME]/server/
- As noted previously also make sure the HTTP_SSL option is set to true.
- Restart the enPortal server.
Redirecting HTTP traffic
There are two recommended approaches for redirecting standard HTTP traffic to HTTPS:
- Use an external tool to redirect the traffic such as a load balancer or a full featured HTTP server like Apache. For many this will be the preferred option as since no configuration changes to enPortal are necessary.
- Modify server/conf/server.xml and server/webapps/enportal/WEB-INF/web.xml to define an extra non-SSL connector that will redirect to the HTTPS port. This approach is well documented by the Tomcat user community.