Creating a Secure Server with SSL

Creating a Secure Server with SSL

You have no doubt noticed the URLs that begin with https:// (instead of the usual http://)-those are HTTPS requests that use HTTP together with encryption performed using the SSL. HTTPS requests are commonly used to securely send sensitive information such as your date of birth or a credit card number to a website. The 's' in the protocol name https means that the Web server communicates with your Web browser using HTTP over an SSL connection.

The Apache Web server supports SSL through the mod_ssl module that, in turn, relies on the OpenSSL toolkit to perform the encryption function. Red Hat Linux comes with everything you need to turn Apache into a secure server. The configuration file /etc/httpd/conf.d/ssl.conf loads the mod_ssl module and configures various parameters that mod_ssl needs. You do not have to do anything to the ssl.conf configuration file to enable HTTPS support, but you do have to create some additional files required for encryption using SSL.

The same Apache server can handle both HTTP and HTTPS requests because these two protocols use two different ports by default. HTTP uses port 80, whereas HTTPS uses port 443.

The following sections provide an overview of how to create a secure Apache server using SSL. In addition to the simple setup I show in the following sections, there are many different ways to configure SSL. For more information on SSL configuration of Apache, consult the online documentation at http://httpd.apache.org/docs-2.0/ssl/.

Secret

Secure Sockets Layer (SSL) is a client/server protocol that enables the client and server to use public key cryptography to authenticate each other and exchange a 40-bit or 128-bit shared secret key. That secret key is then used to encrypt and decrypt data sent between the client and the server.

Public key cryptography relies on each party having a key pair-a private key and a public key-that are related in such a way that a message encrypted with one key can only be decrypted with the other. The public and private keys are usually 1,024 bits long. The public keys are available to anyone, while the private key is kept secret, known only to the owner of the key. Then anyone can send a message securely by encrypting the message with the recipient's public key because only the recipient can decrypt the message with the corresponding private key.

A digital certificate, or simply a certificate, associates information about a recipient and the corresponding public key. It's basically a well-defined format so that the public key information can be distributed easily.

The only catch is how do you know that a public key truly belongs to your intended recipient? That's where the certificate authority (CA) comes in. The CA is the trusted third party that verifies the identity of a certificate's owner and assures that the certificate contains the public key and identifying information of that owner.

How does the CA assure the integrity of a certificate? It does so by digitally signing the certificate. The CA creates the digital signature by first computing a message digest-a short fixed-length number from a message from arbitrary length-of the certificate and then encrypting the digest with the CA's private key. Then anyone can verify the authenticity of the certificate by decrypting the digital signature with the CA's public key and computing the message digest again and comparing with what the digest in the CA's signature.

For more information about SSL, visit Netscape's website at http://developer .netscape.com/docs/manuals/security/sslin/contents.htm.

There are two versions of SSL:

• SSL v2.0-This is the original version of SSL protocol, developed by Netscape Communications. This version of SSL uses only RSA keys.

• SSL v3.0-A version of the SSL protocol revised to prevent certain security attacks and to support non-RSA keys and certificate chains.

SSL 3.0 is the basis for the Transport Layer Security (TLS) protocol, which is currently being developed by the Internet Engineering Task Force (IETF).

Establishing an SSL session involves a handshake sequence between the client and the server, followed by encrypted data exchange using an agreed upon secret key. The overall sequence has the following key steps:

1. The client sends a client hello message to which the server must respond with a server hello message, or else a fatal error will occur and the connection will fail. The client hello and server hello establish the following attributes: SSL protocol version, a session ID, and the cipher suite-the method to exchange the key, the secret key, and the message digest algorithm to be used to create the message authentication code that ensures integrity.

2. Optionally, the server sends its certificate to the client for authentication. The server may also send a key exchange message, and it may request a certificate from the client. The details of the exchanges between the server and the client depend on the cipher suite selected and whether the client had a digital certificate or not.

3. The client sends a change cipher message and uses the secret key to send an encrypted message indicating it's done.

4. The client and server begin to exchange encrypted data using the secret key.

To support SSL, your Apache server needs a public-private key pair and a digital certificate to provide the public key to any Web browser that connects to the server with a HTTPS request. Ideally the certificate should be signed by a well-known certificate authority so that anyone coming to your website can trust the certificate. The next section explains how to set up the keys and the certificate.

Generating Digital Certificates

To support SSL, the Apache Web server needs a public-private key pair and a digital certificate with its public key. You can perform these tasks by using the make command and the Makefile in the /etc/httpd/conf directory.

Secret

Before you can use the Makefile, you have to remove the keys and certificate that were generated during Apache installation. To remove the key and certificate, type the following commands while logged in as root:

cd /etc/httpd/conf
rm ssl.key/server.key
rm ssl.crt/server.crt

Next, generate the keys by typing the following command:

make genkey

You should see some output similar to the following that ends with a prompt for a pass phrase:

umask 77 ; \
/usr/bin/openssl genrsa -des3 1024 > /etc/httpd/conf/ssl.key/server.key
Generating RSA private key, 1024 bit long modulus
........................++++++
.......++++++
e is 65537 (0x10001)
Enter PEM pass phrase:

Type a long pass phrase-it can be a sentence with spaces and punctuations-and press Enter. You will be prompted to reenter the pass phrase. The new key is now in the /etc/httpd/conf/ssl.key/server.key file.

Generating a Certificate Request

The next step is to generate a certificate request that you can send to a Certificate Authority requesting a signed digital certificate. Typically, you have to pay an annual fee for the CA's services. Verisign, Entrust, Thawte are some of the well-known CAs in the United States. You can find links to other CAs at the PKI Page (http://www.pki-page.org/). To generate the certificate request, type:

cd /etc/httpd/conf
make certreq

You will be prompted for the pass phrase-enter the same pass phrase you typed when creating key. You will also be prompted for the following information:

• Country name-Enter the two-letter country code (for example, US for the United States). For the official list of two-letter country codes, consult http://www.iso.org/iso/en/prods-services/iso3166ma/02iso-3166-code-lists/list-en1.html.

• State or province name-Enter the full name (for example, Maryland).

• Locality name-Enter the name of your city or town (for example, North Potomac).

• Organization name-Enter the name of your organization.

• Organization unit name-Enter the name of division or section where you work (or type anything you want).

• Common name-Enter the server's hostname.

• Email address-Enter the email address of the person responsible for the server.

When you finish entering this information, the certificate request is created and saved in the file /etc/httpd/conf/ssl.csr/server/csr.

Insider Insight

After you create the certificate request, select a CA and visit its website for further instructions on how to send the certificate request and how to pay for the certificate. After the CA is satisfied about your identity and receives payment for the certificate, it will send the signed certificate back to you by email. You should save the certificate in the file /etc/httpd/conf/ssl.crt/server.crt (overwrite the existing file).

Creating a Test Certificate

For the purposes of testing, you can create a self-signed certificate. To generate the test certificate, log in as root, and type the following commands:

cd /etc/httpd/conf
make testcert

You will see output similar to the following:

umask 77 ; \
/usr/bin/openssl req -new -key /etc/httpd/conf/ssl.key/server.key -x509 -days 365 -out /etc/httpd/conf/ssl.crt/server.crt
Using configuration from /usr/share/ssl/openssl.cnf
Enter PEM pass phrase:

You have to type the same pass phrase that you used when generating the key. After you enter the pass phrase and press Enter, you have to provide the same set of information that you enter when preparing the certificate request (see the 'Generating a Certificate Request' section). Provide the requested information and, at the end, a test certificate should be created and saved in the /etc/httpd/conf/ssl.crt/server.crt file.

service httpd restart

Starting httpd: Apache/2.0.40 mod_ssl/2.0.40 (Pass Phrase Dialog)
Some of your private key files are encrypted for security reasons.
In order to read them you have to provide us with the pass phrases.

Server new.host.name:443 (RSA)
Enter pass phrase:

https://192.168.0.8/