Home » Computing » Internet » Install a secure web server on Linux

Install a secure web server on Linux

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

Ubuntu:

apt-get update && apt-get install apache2 openssl

On CentOS:

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

Configure Apache

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:

https://github.com/taikedz/handy-scripts

Posted in Internet, Linux, Security, Tai's FWA

Leave a Reply

Your email address will not be published. Required fields are marked *