Setting up secure connection on your Apache web server is very much straightforward on Linux — all the tools are at your disposal, and in just a few commands, you can be fully set up.
The following instructions are for Ubuntu and CentOS, and covers generating a self-signed certificate.
For an overview of free and cheap SSL certificates, see http://webdesign.about.com/od/ssl/tp/cheapest-ssl-certificates.htm. These certificates from Certificate Authorities only certify that the certificate was issued to the same person controlling the domain. They are fine for internal sites and personal home pages, but not for eCommerce sites..
For an overview of Enhanced Validation certificates (more expensive but more globally trusted), see http://webdesign.about.com/od/ssl/tp/cheapest-ev-ssl-certificates.htm. These certificates are issued against a real-world check of your identity, carrying thus a higher cost and higher trust. They are suitable for high-traffic sites that want to be properly identified and commercial sites; they are overkill for small project sites and testing.
Install and Configuration
Install Apache and OpenSSL
apt-get update && apt-get install apache2 openssl
yum install httpd openssl
Generate the SSL key, CSR and certificate
The following script generates the required keys:
F_KEY=$1.key F_CSR=$1.csr F_CRT=$1.crt [[ -f "$F_KEY" ]] || openssl genrsa -out "$F_KEY" 2048 [[ -f "$F_CSR" ]] || openssl req -new -key "$F_KEY" -out "$F_CSR" openssl x509 -req -days 365 -in "$F_CSR" -signkey "$F_KEY" -out "$F_CRT"
Call the script with the name of the certificate file as argument.
For example, save the script as ./gen_ssl_keys
Then run it with bash gen_ssl_keys mysite
You will be asked a few questions about the certificate you will be producing: most notably, when asked for the FQDN (fully qualified domain name), you must supply the full name of the server – which is especially relevant on internal networks: “server1.company.subnet.lan” instead of just “server1”
Now you configure Apache.
On Ubuntu edit the file /etc/apache2/sites-available/default-ssl.conf
On CentOS edit /etc/httpd/conf.d/ssl.conf
Look for the lines referencing
SSLCertificateFile /path/to/$F_CRT SSLCertificateKeyFile /path/to/$F_KEY
And set the paths as appropriate, to where your keys are, preferably somewhere in /etc/pki, which only root and apache2 or httpd can access, and permissions are set to 640 (-rw-r—-) with file ownership set to root:www-data
Ensure that the <Directory> directives are set to the same as the default site (which is the non-SSL site used by default)
Save the configuration and exit.
Enable mod_ssl and the site
On Ubuntu run
a2enmod ssl a2ensite default-ssl service apache2 restart
Or on CentOS
a2ensite default-ssl service httpd restart
Your site should now be accessible using HTTPS
If you have problems connecting, make sure mod_ssl is installed, the paths specified in the config for the SSLCertificateFile are correct, and that the firewall allows incoming connections on port 443
You will likely have issues when first connecting if using a self-signed certificate, since the key you used to sign that certificate is not trusted.
Once you are happy the site is working as desired, you can turn off the plaintext version of the site. Use perhaps mod_rewrite or some other mechanism to redirect insecure connections to secure ones.
Added notes – how certificates and key signing work
The script in the “Generate keys …” section above is useful to keep around:
The first step creates a Key file, which must absolutely be kept private.
The second key creates a Certificate Signing Request – the base information for the certificate which has yet to be signed by a trusted key. This is the step where you are asked about all the information for the certificate-to-be.
For extra trust, this CSR would normally be signed by a Certificate Authority’s key on another server, whose own certificate we already trust, generating a CA-signed certificate.
In this instance we are signing the certificate with its own key, thus creating a self-signed certificate.
The final step takes the Key, and the CSR, and generates a signed Certificate based on the information in the CSR. It has an expiration date, after which the certificate is no longer valid.
If you run the script again, with the same name parameters, the same Key and CSR will be used, and a new self-signed certificate will be produced, with an updated date.
The point of re-using the CSR for the same key is that you can re-issue new certificates from it without constantly re-entering the details.
You could then use your main key and the self-signed Certificate to issue other keys, with your own Key as the signing key.
openssl x509 -req -days 365 -in “subkey.csr” -CAkey “main.key” -out “subkey.crt” -CA “signed-main-key.crt”
For this you will also need a “signed-main-key.srl” (same name as your CA-cert but with a different extension), which is a serial number (arbitrary, of your choosing) for any key signed. You can issue batches of keys with the same serial number. You could later, if necessary, revoke whole swathes of keys using the serial number.
You can create thus a main self-signed Certificate using this self-signing mechanism, and distribute the Certificate to your company to be trusted as the main company certificate.
Afterwards, you use the key of the main certificate to sign the certificates of lesser keys.
Your main certificate becomes known as a “trusted authority” in your company, which guarantees the trustworthiness of sub-keys.
There are global trusted authorities like GlobalTrust and Verisign whose certificates ship be default with major browsers. If you have your CSR signed by a widely-trusted CA, and if the CA-signed certificate that the CA gives you permits it, you could issue signed keys with the CA’s trust chain (substitute the signed key in the -CAkey option).
Most basic certificates do not permit this usage – delegating key-signing trust from a CA to a sub-CA commands high prices, for fairly obvious reasons: the CA is in effect trusting you to act responsibly with the key signed certificate they give you. Cheap or free keys are not worth it for the CA.
I maintain a version of the script as part of my handy-scripts project – check it out on GitHub: