Securing Your Apache 2 Server with SSL

Securing an Apache 2 Web server can be an intimidating prospect for those new to secure sockets layer (SSL) certificates. However, this need not be the case. SSL secures Web server to Web browser connections. Read on to better understand SSL certificates, learn how to set them up on Apache and launch your SSL-enabled site.

In today’s Web hosting environments, many Webmasters host on servers with ready-made SSL setups and no installation requirements, or with setups on which a control panel handles the heavy configuration work. Whatever the case, it’s important to understand just what your SSL options are, and to know how to manage the process manually.

Caveat to Apache 1.x Users

While this tutorial specifically addresses Apache 2, not that much is different between this and the 1.x versions of Apache. Prior to version 2, SSL support was not built into Apache due to export and encryption regulatory demands. However, both apache-ssl and mod_ssl are available for 1.x versions of Apache. Much of the openssl and httpd.conf content in this tutorial covers both versions.

Certification Authorities and Trusted Roots

Before we dig into SSL certificate types and how to buy and install a certificate, let’s complete a brief review of how SSL certificates are created and managed.

Certain circumstances were necessary for SSL to attain widespread commercial adoption. ‘Trust’ had to be established before users would willingly transmit confidential information over the Internet. Thus, Certification Authorities (CAs) were born. To ensure the software companies building today’s popular Web browsers would include support for these CAs, several gained ownership of their trusted root certificates — the certificates that originate the SSL certificates sold to users for securing Websites. These companies are referred to as Trusted CAs; examples include GeoTrust, Thawte and VeriSign.

According to representatives from SSL Review the Trusted CAs that control their own trusted root certificates are permanent players in the SSL market and offer the highest level of business stability to enterprises and small to medium-sized businesses.

SSL Review is a Website that’s dedicated to demystifying SSL certificates and, while owned by GeoTrust, a major SSL provider, the site is fairly unbiased. It includes an excellent SSL comparison chart featured previously in Open Sourcery.

What Type of Certificate Should I Choose?

There are numerous vendors offering a variety of SSL certificates. Certificates can range considerably in price — from as much as US$1495 to free — depending upon the way you plan to use the certificate, and the services and support the vendor offers. Let’s take a look at a few of the options.

Certificates start at a minimum of 40-bit encryption. These certificates are useful for securing extranets, intranets and Websites through which ecommerce is not being transacted. They also include 128-bit encryption, the de facto standard for two-way encrypted transactions between users and a Web server.

Securing Data in a Non-commercial Environment

If you are seeking to secure data by providing an encrypted connection through which users can be authenticated, modify records, or view personal data, then a low-end certificate may work.

Certificates in this category should cost under US$50 annually and include availability from Trusted CAs ipsCA and FreeSSL.com. As these certificates do not carry a known brand, fraud control or human support, they are suitable for non- or light commerce environments, though they do provide bonus 128-bit encryption. According to FreeSSL.com, a light commerce environment is one with no more than 50 transactions weekly, and an average transaction value of US$50.

Wildcard Certificates – Securing Multiple Domains with one Certificate

There may be cases in which multiple sub-domains under one domain need to be secured. For example, securing www.domain.com, orders.domain.com and service.domain.com under one certificate is possible with a wildcard SSL certificate.

Since you can secure an unlimited number of host names, wildcard certificates are generally more expensive than normal certificates, but they become very cost effective for those who need to secure several domains. Certificates in this category can range from US$299 up to US$800 and are available from FreeSSL.com, ipsCA, GeoTrust and others.

Securing for eCommerce

If you’re securing a site for commerce-related activity, many issues arise, including browser compatibility, fraud prevention, and the deployment of the highest levels of security within your economic and technical capabilities.

Each Trusted CA has developed its own features, benefits and platforms to support its bid for your SSL business; however, some provide more comprehensive solutions than others.

When looking for an ecommerce SSL, consider the following questions:

Does the Trusted CA offer your users a method by which they can authenticate or validate your SSL certificate through their Web browser?
Is there warranty protection if your certificate is stolen, corrupted, impersonated, or you experience loss of use?
What kinds of perks are added in if extra dollars are invested in the certificate — such as extended renewal and payment services for processing transactions?

The price of an ecommerce certificate can range from US$199 to US$1495 annually. They’re available from all major Trusted CA providers, including GeoTrust, Thawte and VeriSign.

Testing SSL via Self-Signed Certificates/

Your Apache Web server is already prepared to provide a self-signed SSL certificate. These certificates are handy for testing and are, of course, free. In most cases, they will generate alert messages for your users as they are not generated from Trusted CA root certificates and do not offer any third-party proof to validate your site’s identity. Thus, these certificates are best for internal use or during development and testing.

Getting Started with SSL on Apache

There are a few key ingredients you will need to use with Apache to secure your Web server: OpenSSL, mod_ssl, and root access to the server.

OpenSSL is a command line toolkit for using secure sockets layer encryption on a server and can be acquired from openssl.org. This tool works with Apache module mod_ssl in carrying out SSL-related tasks. You will need root privileges to install OpenSSL to its traditional destination of /usr/local/ssl/install/openssl.

You must also ensure that mod_ssl is available on your server. There are other alternatives to mod_ssl; one is apache-ssl, from which the mod_ssl code was forked. However, mod_ssl’s adoption has been dramatic — nearly 20% of Apache servers were running it at the beginning of 2002.

To see which modules are active in Apache, issue the following command in a Terminal as root user on your server.

/usr/sbin/httpd -l

If you have a recent Linux distribution installed, it is likely Apache’s modules are compiled as dynamic loadable modules, in which case you’ll need to edit your httpd.conf file and check that the following line is uncommented.

LoadModule ssl_module modules/libmodssl.so

Restarting Apache will load the module into action. In my case, having used an RPM-based install of Red Hat and Apache, this is achieved with the apachectl command, typically found in /usr/sbin/apachectl. You can restart Apache by typing the following:

/usr/sbin/apachectl restart

There are several helpful features of apachectl, including stop, start, restart, status and check config. See the man pages via man apachectl.

Note that in recent Apache distributions, the httpd.conf file contains an <IfDefine HAVE_SSL> section that is intended to contain the <VirtualHost> definitions for all your SSL Websites. By placing these definitions within the <IfDefine> section, you can ensure that the sites will not be made available unless SSL support is successfully loaded on the server. This prevents any problems arising in which SSL could expose your secure sites.

Create a Local Key Pair

If you have not already done so, your first step should be to create a local private/public key from which you can generate certificate requests. These can then be used for self-signed certificates, or when purchasing a certificate from a CA.

OpenSSL allows us to use the command line to generate keys. You have the option of using strong encryption and a passphrase to secure your private key, as shown below.

openssl genrsa -des3 -out domainname.com.key 1024

Typing the above on the command line will create a private key using TripleDES encryption, 1024 being the number of bits generated in the key. There are options for lower encryption levels and making the passphrase not required, however, these are not recommended for those with servers that are accessible via the Internet.

Note that if OpenSSL is not in your path, you may need to enter the full path to the binary for this purpose; by default, it’s /usr/local/ssl/install/openssl/bin/openssl. The key will be created in the directory you’re in.

Finally, you should modify the permissions to restrict access to the new key by issuing chmod 400 domainname.com.key on the command line. This ensures that only the root user has access to this file, and still requires the passphrase you may have used to create the key in order to open.

Creating a Self-Signed Certificate

This is a very easy step, but again, remember that self-signed certificates should only be used for internal systems or in development and testing.

Generate your own certificate by going back to the command line and entering the following:

openssl req -new -key domainname.com.key -x509 -out sslname.crt

This command creates a self-signed SSL certificate, which can then be placed in the proper directory. Due modifications can then be made in httpd.conf (we’ll cover these in just a moment).

Generating a Certificate Signing Request

To purchase an SSL certificate from a CA, you need first to generate what is called a CSR, or Certificate Signing Request. This is submitted to the CA of your choice, and is used to create the official SSL certificate that will be returned to you, and with which you may secure your Web server.

The CSR request is straightforward; it’s effected on the command line with OpenSSL as follows:

/usr/local/ssl/install/bin/openssl req -new -key domainname.com.key -out domainname.com.csr

This command creates the .csr file that is sent or uploaded to a CA during the process of ordering an SSL certificate.

Receiving and Installing Your SSL Certificate

Generally, CAs provide detailed instructions for the installation of their SSL certificates; however, I’ll cover some broad points here.

The CA from which you order a certificate will email you either the certificate, or a link at which you can download it. Follow the instructions provided precisely — especially with regards to opening a certificate in a text editor. Do not use a word processor or rich text editor, as the certificate code can become corrupted. You should also take care to ensure that no leading or trailing spaces follow the beginning and end of the certificate code — see the example code below:

Using RPM-based install defaults, my private key and the valid SSL certificates returned from a CA go into /etc/httpd/conf/ssl.key/ and /etc/httpd/conf/ssl.crt/ respectively. Your self-signed certificates should also reside in the latter directory in place of, or in addition to, formal SSL certificates issued by a CA.

This will differ depending upon how your version of Apache was installed. VeriSign offers on its site a sweeping installation guide index that covers numerous Web servers, including Apache. The Apache mod_ssl tutorial is based largely on the information available on the modssl.org Website.

Configuring Apache to enable SSL for the domain(s) you’re securing occurs in the httpd.conf file. To begin, make a backup of the file. Then, open it in your favorite text editor.

You can add the virtual host domain you’re securing into the <IfDefine HAVE_SSL> section noted above. A minimal example entry straight from a default httpd.conf file is listed below for your reference. You should modify items such as paths and IP addresses to fit your own environment. The SSL port is 443 unless you’re specifically adjusting the port to another port number (the SSL config appears in bold below):

<IfDefine HAVE_SSL> 

 

<VirtualHost 10.0.0.5:443> 

DocumentRoot /home/sites/domainname.com/html 

ServerName www.domainname.com 

ServerAlias domainname.com 

ServerAdmin admin@domainname.com 

ErrorLog /home/sites/domainname.com/logs/error_log 

TransferLog / home/sites/domainname.com/logs/access_log 

SSLEngine on 

SSLCertificateFile /etc/httpd/conf/ssl.crt/domainname.com.crt 

SSLCertificateKeyFile /etc/httpd/conf/ssl.key/domainname.com.key 

SetEnvIf User-Agent ".*MSIE.*" nokeepalive ssl-unclean-shutdown 

</VirtualHost> 

 

</IfDefine>

Note that, if you perform a hard start of your server, your passphrase will be required for you to access the OpenSSL private key you created earlier. It is not prompted during reboots.

Now, you must restart Apache using the apachectl command, to ensure that all your modifications are enabled. You should then be able to access your site securely by going to https://domainname.com/.

Wrapping Up, Additional Features and Tools

As you can see, while some research, planning and effort is required to get SSL up and running, it is not an insurmountable task. In the coming weeks, I’ll be blogging in Open Sourcery on SSL-related topics such as configuring Web log files to log SSL activity on the secure portion of your site, and a few interesting tools with SSL applicability. Stay tuned!