Chapter 3. Securing Your Server

Table of Contents
How Server Security Works
Deciding on a Certificate Authority
Proving Your Organization's Identity to a CA
Creating Your Key and Certificate Request
Getting a Test Certificate
Installing and Testing Your Certificate
Buying a Certificate

To make your customers feel safe doing business with you over the Web, your Web server needs to be secure. A secure server instructs any browser accessing your site to encrypt all the data sent back and forth. Encrypted data can't be intercepted and read by a third party. Your customers will feel more comfortable when making purchases from your site if they know that their transactions are secure.

Secure servers aren't only for electronic commerce. A secure server may also be used to transmit sensitive data such as sales figures to sales people on the road or to business partners over the Internet.

This chapter will show you how to create a public and private key pair, which is needed to create a certificate request. Then we'll go through the process of getting a certificate signed by one of two different Certificate Authorities (CAs): VeriSign (http://www.verisign.com) and Thawte (http://www.thawte.com). Once you have a signed certificate, you'll learn how to install it on your Red Hat Linux Apache/SSL Server.

When you use a signed certificate, you guarantee the identity of the organization running the server. For example, if the certificate says the website is Red Hat's, and the user trusts the CA, then there is no reason to doubt that any files or programs downloaded from that site really are from Red Hat.

If you upgraded from a previous version of the Red Hat Secure Web Server, your old key (httpsd.key) and certificate (httpsd.crt) will be located in /etc/httpd/conf/. Rename httpsd.key to server.key and move it to the /etc/httpd/conf/ssl.key directory. Rename httpsd.crt to server.crt and move it to the /etc/httpd/conf/ssl.crt directory. Then start your Red Hat Linux Apache/SSL Server as described in the section called Starting and Stopping Your Server in Chapter 4. You should not need to get a new certificate.

Please Note: VeriSign is a very widely used CA. If you already have a VeriSign certificate for another purpose or that you used for a different web server software, you may have been considering using your existing VeriSign certificate with your new Red Hat Linux Apache/SSL Server. However, you are not allowed to, because VeriSign issues certificates for one particular server software and IP address/domain name combination.
If you change either of those parameters (for example, if you previously used another secure Web server product and now you want to use the Red Hat Linux Apache/SSL Server), the VeriSign certificate you obtained to use with the previous configuration will not work with the new configuration. You will have to obtain a new VeriSign certificate.

How Server Security Works

Your Red Hat Linux Apache/SSL Server provides security by incorporating an implementation of SSL, the Secure Sockets Layer protocol, into the Apache Web server and by the use of CA-approved digital certificates. SSL handles the encrypted communications and the mutual authentication between browsers and your Red Hat Linux Apache/SSL Server. The CA-approved digital certificate provides authentication for your Red Hat Linux Apache/SSL Server (the CA puts its reputation behind a certification of your organization's identity).

Encryption depends upon the use of keys (think of them as secret encoder/decoder rings in data format). In conventional or symmetric cryptography, both ends of the transaction have the same key, which they use to decode each other's transmissions. In public or asymmetric cryptography, two keys co-exist: a public key and a private key. A person or an organization keeps their private key a secret, and publishes their public key. Data encoded with the public key can only be decoded with the private key; data encoded with the private key can only be decoded with the public key.

You'll use public cryptography to create a public and private key pair. Then you'll create a certificate request, which contains your public key. You send your certificate request, proof of your company's identity and payment to a CA. The CA verifies the certificate request and your identity, and then sends back a certificate for your Red Hat Linux Apache/SSL Server.

Please Note: You can create test certificates using the OpenSSL software included with the Red Hat Linux Apache/SSL Server, or you can obtain free test certificates from a CA. Test certificates are not the same as signed certificates, however. The purpose of a test certificate is to make sure that your Red Hat Linux Apache/SSL Server is running correctly. You can't use a test certificate for secure transactions, because users' browsers won't recognize it or allow the secure connection to be made. More information on creating a test certificate is contained in the section called Getting a Test Certificate.
Signed certificates must be purchased from Thawte, VeriSign, or another CA. Signed certificates can be used to test your Red Hat Linux Apache/SSL Server and must be used to support secure transactions. Once you've installed a signed certificate, users' browsers will recognize the certificate and will allow your Red Hat Linux Apache/SSL Server to create a secure connection.
Signed certificates are not included with the Red Hat Linux Apache/SSL Server. Signed certificates must be purchased from a CA. For the purchase price, CAs certify the identity of a business or organization, in order to provide customers with a guarantee of safety.

Your Red Hat Linux Apache/SSL Server needs a certificate signed by a CA, so that people who visit your website know you are who you claim to be. When a Web browser connects to a secure website, the browser requests that the server provide some evidence of its identity (or more importantly, the identity of the organization behind the website). The certificate is signed by a CA, which basically means that you can be assured of its validity. Before signing the certificate, the CA verified that the organization (in this case, you) requesting the certificate was actually who they claimed to be.

Most Web browsers that support SSL have a list of CAs whose certificates they will automatically accept. If a browser encounters a certificate whose authorizing CA is not in the list, the browser will ask the user to choose whether to accept or decline the connection.

The process of getting a certificate is relatively easy and this chapter will cover how to get one in detail. A quick overview is as follows: you create an encryption key and then a certificate request based on that key. The certificate request contains information about your server and the company hosting it. You send this certificate request, along with documents proving your identity, to a CA. Once the CA is satisfied that you are indeed who you claim to be, they will send you a digital certificate. You then install this certificate on your Web server, and begin handling secure transactions.