The Internet is a budding marketplace of information and e-commerce. In the last few years, the growth of the Internet has been incredible, and today there’s a growing trend toward shopping online. A few years ago, people were wary of providing credit card information over the Internet. What has changed the way people view shopping online? Most likely, it’s an increased awareness that shopping online is safe and secure—the chance of someone stealing your credit card number is greater when you phone in a pizza order than when you order an item over the Internet.

SSL
Encryption and secure Web sites make shopping online feasible and reliable. Most Web sites use the Secure Sockets Layer (SSL), developed by Netscape Communications Corporation. SSL is a three-tiered encryption method that employs RSA and DES authentication and encryption, as well as additional MD5 integrity checking. This means that using SSL is pretty much guaranteed to be safe, and it allows people to easily shop with their credit cards online. SSL works by defining and exchanging a secret key at connection time between the client and the server. The secret key is then used to encrypt data. SSL also supports public key cryptography, so the server can authenticate users using schemes like RSA and DSS (the Digital Signature Standard). By using SSL, the server can verify the integrity of ongoing sessions using message digest algorithms like MD5 and SHA. When performing an integrity check, SSL ensures a secure session by making sure the data in transit isn’t being modified by a third party.

As a Linux Web administrator, you may be investigating e-commerce on your own. Perhaps you want to set up your own Web server that provides SSL encryption and authentication to provide your customers with the ability to shop online. Nowadays, this isn’t a ridiculous notion.

The tools you want, the tools you need
There are two methods of setting up a secure Web server with Apache, which is a popular Web-serving program for Linux (and many other operating systems). The first method is to patch Apache with the Apache-SSL patches. In order to do this, you need a copy of Apache, the Apache-SSL patches, and a copy of SSLeay, an SSL library that’s free for non-commercial use.

The second method, and the one I’ll explore in this Daily Drill Down, is to use Apache in conjunction with OpenSSL using the mod_ssl modules for Apache. Since the recent versions of Apache are modularized, it makes sense to use SSL as a module, as opposed to patching the Apache source code and re-compiling the program. You’ll need a recent version of Apache (which can be obtained from the official site), the mod_ssl modules (from the mod_ssl official site), and the OpenSSL program (from the OpenSSL official site).

Many distributions provide these programs as RPM or DEB packages, making installation extremely easy. If you’re running a distribution that doesn’t provide packages for all or some of these programs, download the source TAR/GZip archive(s) and unpack them using:
tar xvzf apache_1.3.12.tar.gz
tar xvzf mod_ssl-2.6.0-1.3.12.tar.gz
tar xvzf openssl-0.9.4.tar.gz

Next, you need to build the OpenSSL package first. Do so using:
cd openssl-0.9.4
./config
make
make install
cd ..

Then build Apache with mod_ssl support compiled in:
cd mod_ssl-2.6.0-1.3.12
./configure –with-apache=../apache-1.3.12 –with-ssl=../openssl-0.94 \
–prefix=/usr/local/apache
cd ../apache_1.3.12
make
make certificate
make install
Should the release version you are installing be more recent than the above, make sure you insert the correct numbers in the above commands.
Modules, modules, modules
As an alternative, you can build Apache with mod_ssl as a regular Apache module. If you already have Apache installed, it’s easy to build the mod_ssl module and use it as a “plug-in.”

To do this, use the following:
cd apache_1.3.12
SSL_BASE=/usr/local/ssl ./configure … –enable-module=ssl

You can also enable the Dynamic Shared Object (DSO) support for mod_ssl by using:
cd apache_1.3.12
SSL_BASE=/usr/local/ssl ./configure … –enable-shared=ssl

For either method, you still need to build Apache using:
Make
make certificate
make install

The advantage of building mod_ssl as a DSO as opposed to a static module is it allows you to achieve more run-time flexibility than you would otherwise have. You can decide whether you want to use SSL at run time instead of when you’re building the program. (This is true, of course, if you build Apache from the source code yourself.) Whatever method you choose, following the code examples above will configure Apache with mod_ssl support, compile it, make a test certificate, and install the program.

Keep in mind that the certificate you create is only a test certificate. This is one way of ensuring that everything is set up and configured correctly. Creating the test certificate will also help you become more familiar with how SSL works with Apache.

Once you have Apache, mod_ssl, and OpenSSL installed, you can create your site’s real certificate. To do this, you will need to use the OpenSSL command line tool called openssl. The first step is to generate your certificate. A good way to do this is to use RSA and encrypt the key with TripleDES by using:
openssl genrsa -des3 -out server.key 1024

This will create a 1,024-bit RSA key encrypted with TripleDES. OpenSSL will prompt you for the information to use while generating your key, similar to when you created your test certificate above.

You will be asked to enter the PEM passphrase to your encrypted RSA key. Should you ever need to make changes or administrate your certificate, you will need to know this passphrase. Make sure this is a strong password, because if anyone obtains your certificate, they can make changes to it and compromise your Web site’s security. You will be asked to reconfirm the passphrase.

Privacy Enhanced Mail (PEM) is a Base64-encoded Distinguished Encoding Rule (DER) with header and footer lines. DER is a binary way of encoding the certificate for any SSL-based Web site. Since some browsers are incapable of understanding and handling binary certificates, PEM is used to simplify the process of transporting the certificate using encoded ASCII text.

You will now have a server.key file in the directory. This is the private key used to encrypt and decrypt data being transferred from the client to the server and vice versa. You must generate the certificate request and use your new key to create it. At the command line, type:
openssl req -new -key server.key -out server.csr

You’ll be asked to answer several questions that determine how to create the certificate request. You’ll provide a country name, state or province name, city name, organization name, organization unit name, your common name, and your e-mail address.
The common name must be the fully qualified domain name of the site for which it will be used. For example, if your domain name is mydomain.com and the secure Web site will be available at https://www.mydomain.com/, you’d type www.mydomain.com in the common name field.
You’ll also be asked for any extra attributes you want to send with your certification request, such as a challenge password or optional company name. You’ll probably want to leave these fields blank.

Certificates
OpenSSL allows you to generate your own certificate to use on your Web site. However, most companies want to have their certificate generated by a Certificate Authority. If you are going to use this secure Web server for encrypting data sent via forms or during user logins on an interactive Web site, you can get away with generating your own certificate. However, if you plan to use your secure Web server for e-commerce, you’ll want to have the certificate generated by a recognized Certificate Authority.

Certificate Authorities are trusted third parties that issue certificates and verify their authenticity. By using a certificate generated by such a company, you can greatly enhance the credibility of your Web site and help the site meet any requirements you may need to fulfill to become an e-commerce firm.

Certificate Authorities establish the validity of your company by requiring you to provide legal proof that you’re authorized to use your company’s legal business name in transactions. You can provide this proof by using a valid business license, articles of incorporation, notarized partnership papers, registration records, and so forth.

Some recognized Certificate Authorities are:

These sites, and most other recognized Certificate Authorities, charge a fee for providing a one-year certificate. Most will do this only for valid businesses or governments, but some will provide certificates for individual users for personal use. Regardless of your needs, it’s best to look around for competitive rates and for which Certificate Authority best provides for your needs.

You can easily build your own certificate for your Web site with OpenSSL. Unfortunately, the generated certificate isn’t created by a reputable source. Otherwise, generating your own certificate works just as well as paying a Certificate Authority $200 per year to do it for you. On the command line, issue the following:
openssl genrsa -des3 -out ca.key 1024
openssl req -new -x509 -days 365 -key ca.key -out ca.crt

In order to create your own Certificate Authority, you must generate a new 1,024-bit RSA key—just like we did for your secure Web site’s RSA key. The second command creates a self-signed CA (self-signed Certificate Authority). It creates the CA using the X509 structure with the new CA RSA key. The certificate will be valid for 365 days from the date created, which is the typical amount of time certificates are valid. The output is PEM-formatted. If you wish to see the details of your certificate, issue:
openssl -x509 -noout -text -in ca.crt

The next step is to prepare a script for signing certificate requests. The reason for this is because the openssl ca command currently has some strange requirements and the default OpenSSL configuration doesn’t allow you to easily use the openssl ca command directly. Packaged with the mod_ssl distribution is a script called sign.sh located in the pkg.contrib/ subdirectory. Using this script is the simplest way to sign certificate requests and generate your site’s certificate.

To create your certificate, type ./sign.sh server.csr on the command line. This uses your new CA to sign your server’s certificate request and creates a real SSL certificate to use with Apache. The result is seen in the newly generated server.crt file in the current directory. The only thing left to do now is to configure Apache to use the new certificate.

In your Apache configuration file, httpd.conf, you must insert these directives:
SSLEngineon
SSLCertificateFile/etc/httpd/conf/server.crt
SSLCertificateKeyFile/etc/httpd/conf/server.key

These directives tell Apache where to find the files to encrypt and decrypt data on your secure Web site, and they tell Apache to turn on the SSL support.

You may encounter a problem when restarting Apache. Since you’ve encrypted your keyfile with TripleDES, Apache will ask you for your PEM passphrase prior to loading. If you want extra security, leave things as they are. However, if Apache doesn’t ask you for the passphrase and simply refuses to start (which happens if you start the server in the background), you must provide Apache with an un-encrypted keyfile. As long as you have your keyfile in a secure place with appropriate permissions (I suggest making the keyfile readable only by the user running Apache, typically httpd or no one, and making it writeable for no one), you can decrypt your RSA key and use it by issuing:
mv server.key server.key.des
openssl rsa -in server.key.des -out server.key

In the shop for a tune-up
There are more configuration options available to fine-tune how Apache works with SSL. I recommend creating a new configuration file called mod_ssl.conf in your Apache configuration directory and linking it to your existing configuration by adding to httpd.conf:
Includemod_ssl.conf

The contents of mod_ssl.conf should look similar to this:
LoadModule ssl_module/usr/lib/apache/libssl.so
# listen to the standard HTTPS port (443)
Listen 443
# Some MIME-types for downloading Certificates and CRLs
AddTypeapplication/x-x509-ca-cert .crt
AddTypeapplication/x-pkcs7-crl .crl
# configure the SSL session cache
SSLSessionCacheshm:logs/ssl_scache(512000)
SSLSessionCacheTimeout300
# Semaphore:
# Configure the path to the mutual exclusion semaphore the
# SSL engine uses internally for inter-process synchronization.
SSLMutexfile:logs/ssl_mutex
# Pseudo Random Number Generator (PRNG):
SSLRandomSeedstartup builtin
SSLRandomSeedconnect builtin
# The home of the dedicated SSL protocol logfile:
SSLLoglogs/ssl_engine_log
SSLLogLevelinfo

Restart your Apache Web server. In Red Hat and similar distributions, you can accomplish this by running:
/etc/rc.d/init.d/httpd restart

At this point, you should be able to connect to your Web site, and your browser should prompt you as to whether you want to accept the certificate. Congratulations! You now have a fully functional secure Web server.

Conclusion
There are a number of excellent sources of information that can teach you how to get more out of your secure Web site and fine-tune it further. The best site I have found is the mod_ssl homepage, which contains instructions for installing all of the necessary components (Apache, mod_ssl, and OpenSSL) and a detailed How-to and FAQ section for a number of different scenarios. It also provides a great deal of information on SSL itself and the types of encryption that can be used on an SSL-enabled Web server.

A secure Web site is ideal, and software has progressed to the point where it’s easy to install and configured everything to meet your needs. Gone are the days of patching source code or spending large amounts of money to invest in a commercial SSL library that provides the same functionality as the free OpenSSL implementation. Combine the obvious advantages of running a Web server under Linux with the tools to provide a truly secure Web site, and it’s no wonder Apache is one of the most widely used Web serving programs on the Internet.

Vincent Danen, a native Canadian in Edmonton, Alberta, has been computing since the age of 10, and he’s been using Linux for nearly two years. Prior to that, he used OS/2 exclusively for approximately four years. Vincent is a firm believer in the philosophy behind the Linux “revolution,” and he attempts to contribute to the Linux cause in as many ways as possible—from his FreezerBurn Web site to building and submitting custom RPMs for the Linux Mandrake project. Vincent also has obtained his Linux Administrator certification from Brainbench . He hopes to tackle the RHCE once it can be taken in Canada.

The authors and editors have taken care in preparation of the content contained herein, but make no expressed or implied warranty of any kind and assume no responsibility for errors or omissions. No liability is assumed for any damages. Always have a verified backup before making any changes.