You can enable HTTPS using a self-signed certificate for selected Nectar applications. Applications that support HTTPS will give you the option to Enable HTTPS as part of the Configure Application steps. These applications currently include CKAN, Drupal, LAMP, LimeSurvey, MediaWiki and WordPress.
If you want to enable HTTPS, just select the Enable HTTPS option.
Once your application is deployed and ready, there are some important precautions needed when using a self-signed certificate.
You will need to add a security exception in the Web browser you will use to access your Nectar application. To minimise the chance of a man-in-the-middle attack you should check that your browser and Nectar application both have the same fingerprint and common name for your Nectar application's server certificate.
To check the HTTPS SHA256 Fingerprint of your Nectar application, click the Applications tab, then the Environments sub-tab. You should see a list of your application environments. Click the environment name to continue, for example quick-env-1.
This will take you to the Application Components screen. Click the Latest Deployment Log tab to see the log entries with the HTTPS SHA256 Fingerprint of your Nectar application and your instance address. You can click the instance address link to open your Nectar application in your Web browser.
If you are using Mozilla Firefox, you will see an Insecure Connection alert. Click Advanced, then Add Exception... to add a security exception for your Nectar application.
Click the View... button to see your Nectar application's server certificate.
In the Certificate Viewer, confirm that the SHA-256 Fingerprint matches the HTTPS SHA256 Fingerprint of your Nectar application and the Common Name (CN) matches your instance address. Click the Close button to continue.
After confirming that the fingerprint and common name match, you can click the Confirm Security Exception button.
You will reach your Nectar application's start page. You should see the secure connection lock with a yellow warning beside the Web browser address. The warning remains because the browser does not recognise the signer of a self-signed certificate.
Installing your Certificate Authority Issued Certificate
You can avoid the self-signed certificate problems/precautions mentioned above if you use a certificate that has been issued (signed) by a recognised Certificate Authority (CA). Many institutions have agreements in place with their preferred CA/s, so it is usually best to submit a request with your IT support organisation to find out how to obtain a CA issued certificate.
Once you have your CA signed certificate, you can install it in your Nectar instance in place of the self-signed certification as follows.
Use SSH to login to your instance as the first step.
Once logged in, get the location of your current SSL certificate and key files from your Apache SSL config file.
On CentOS instances:
$ grep SSLCertificateFile /etc/httpd/conf.d/ssl.conf SSLCertificateFile /etc/pki/tls/certs/apache_https.crt $ grep SSLCertificateKeyFile /etc/httpd/conf.d/ssl.conf SSLCertificateKeyFile /etc/pki/tls/private/apache_https.key
Ignore any entries that are commented out, such as lines starting with '#'.
On Ubuntu instances:
$ grep SSLCertificateFile /etc/apache2/sites-available/000-default.conf SSLCertificateFile /etc/ssl/certs/apache_https.crt $ grep SSLCertificateKeyFile/etc/apache2/sites-available/000-default.conf SSLCertificateKeyFile /etc/ssl/private/apache_https.key
Now you need to make sure the Apache SSL config points to the new certificate and private key files. You can either edit the Apache SSL config file to use the new files, or switch the old and new files without editing the config file.
To switch the old and new files, on CentOS for example:
$ sudo mv /etc/pki/tls/certs/apache_https.crt /etc/pki/tls/certs/apache_https.crt.old $ sudo cp <your_new_CA_cert_file> /etc/pki/tls/certs/apache_https.crt $ sudo mv /etc/pki/tls/private/apache_https.key /etc/pki/tls/private/apache_https.key.old $ sudo cp <your_new_CA_key_file> /etc/pki/tls/private/apache_https.key
Check that new private key file has same owner and permissions as the old private key file, on CentOS for example:
$ ls -l /etc/pki/tls/private/apache_https.key.old -rw-------. 1 root root 3272 Aug 9 00:40 /etc/pki/tls/private/apache_https.key.old $ sudo chown root:root /etc/pki/tls/private/apache_https.key $ sudo chmod 600 /etc/pki/tls/private/apache_https.key
Also check that the new certificate file has same owner and permissions as the old certificate file.
Restart your Apache server so the new SSL certificate and key files are loaded.
On Ubuntu instances:
$ sudo systemctl restart apache2.service
On CentOS instances:
$ sudo systemctl restart httpd.service