Web servers use HTTP by default, which is a clear text protocol. As the name suggests, a clear text protocol does not apply any form of encryption on the transit data. While the HTTP-based web server is very easy to set up, it has a major drawback in terms of security. Any “man-in-the-middle” is able to see the content of the transit packets with carefully placed packet sniffers. Taking the vulnerability one step further, a malicious user can even set up an impostor server in the transit path, which then pretends to be the actual destination web server. In this case, end users may actually communicate with the impostor server instead of the real destination server. This way, the malicious user can trick the end users into handing over sensitive information such as user name and passwords through carefully crafted fake forms.
To deal with these kinds of vulnerabilities, most providers often prefer HTTPS in their web servers. For read-only type sites where users only read the content and do not actually input any information, HTTP still is a viable option. However, for sites that maintain sensitive information and/or sites where users log in to get services, HTTPS is a must. HTTPS enables a website to provide the following services.
- Ensures that all transit packets to and from the servers are encrypted.
- Establishes the trust with an official digital certificate, such that impostor servers are unable to pretend to be the actual server.
The first thing needed for setting up HTTPS is a digital certificate. Digital certificates can be obtained in any of the following methods.
- Self-signed certificates are recommended for testing purposes and personal projects. Self-signed certificates are also applicable for service providers where the client users are specific and the circle of trust is limited. Self-signed certificates do not cost money.
- Certificates can be obtained from community-based certificate providers such as StartSSL and CACert. These certificates do not cost money either, but is recommended for personal projects.
- For commercial projects where websites are accessed globally, it is recommended to purchase a certificate from a well-known trusted certificate authority. These certificates cost money, but they increase the credibility of the web service provider.
In this demonstration, we will be using a self-signed certificate. It is assumed that Apache web server is already installed on CentOS. To generate a self-signed certificate, openssl is used. If openssl is not already installed, it can be installed using yum.
Generating a Self-Signed Certificate
The following commands can be used to generate a self-signed certificate.
First, generate a private key with 2048 bit encryption.
Then generate certificate signing request (CSR).
Finally, generate a self-signed certificate of X509 type, which remains valid for 365 keys.
After the certificate is created, the files are copied to necessary directories.
# cp ca.key /etc/pki/tls/private/
# cp ca.csr /etc/pki/tls/private/
Configuring Apache Web Server
Now that the certificate is ready, it is time to tune Apache web server.
First, edit the following configuration file.
### overwrite the following parameters ### SSLCertificateFile /etc/pki/tls/certs/ca.crt SSLCertificateKeyFile /etc/pki/tls/private/ca.key ### The following parameter does not need to be modified in case of a self-signed certificate. ### ### If you are using a real certificate, you may receive a certificate bundle. The bundle is added using the following parameters ### SSLCertificateChainFile /etc/pki/tls/certs/example.com.ca-bundle
Then the httpd service is restarted for the changes to take effect.
The web server is now ready to use HTTPS.
Tuning Virtual Hosts
Apache web server can be configured to host multiple web sites. These sites are declared as virtual hosts in httpd configuration file. For example, let us assume that our Apache web server is hosting a site virtual-web.example.com, and all the files of the site are stored in /var/www/html/virtual-web directory.
For the virtual host, the typical configuration for HTTP would look like this.
NameVirtualHost *:80 <VirtualHost *:80> ServerAdmin [email protected] DocumentRoot /var/www/html/virtual-web ServerName virtual-web.example.com </VirtualHost>
We need to create a similar definition for HTTPS as well.
NameVirtualHost *:443 <VirtualHost *:443> SSLEngine on SSLCertificateFile /etc/pki/tls/certs/ca.crt SSLCertificateKeyFile /etc/pki/tls/private/ca.key <Directory /var/www/html/virtual-web> AllowOverride All </Directory> ServerAdmin [email protected] DocumentRoot /var/www/html/virtual-web ServerName virtual-web.example.com </VirtualHost>
For each virtual host, similar tags have to be defined. After adding the virtual hosts, the web service is restarted.
Now the virtual hosts are ready to use HTTPS as well.
Optional: Forcing Apache Web Server to Always Use HTTPS
If, for some reason, you decide to always use HTTPS in the web server, you will need to redirect all incoming HTTP requests (Port 80) to HTTPS (port 443). Apache web server can be easily tuned to do this.
1. Forcing the Main Site Only
To force the main site to always use HTTPS, we modify the httpd configuration file.
ServerName www.example.com:80 Redirect permanent / https://www.example.com
2. Forcing Virtual Hosts
If you want to force HTTPS on some virtual host as well, the definition for HTTP can be rewritten as followed.
<VirtualHost *:80> ServerName virtual-web.example.com Redirect permanent / https://virtual-web.example.com/ </VirtualHost>
To sum up, HTTPS is always recommended for sites where users log in. This improves the security of both the server and the users who use it. Certificates can be obtained in various means such as self-signed, community driven or even commercial authorities. The admin should be prudent while selecting the type of certificate that will be used.
Hope this helps.