Secure Server

 

Secure Server

 

Accessing The Server

To access your secure server, use a URL similar to the following:

https://
 server.example.com

Your non-secure server can be accessed using an URL similar to the following:

http://
 server.example.com

The standard port for secure Web communications is port 443. The standard port for non-secure Web communications is port 80. The secure server default configuration listens on both of the two standard ports. Therefore, do not need to specify the port number in a URL (the port number is assumed).

However, if you configure your server to listen on a non-standard port (for example, anything other than 80 or 443), specify the port number in every URL which is intended to connect to the server on the non-standard port.

For example, you may have configured your server so that you have a virtual host running non-secured on port 12331. Any URLs intended to connect to that virtual host must specify the port number in the URL. The following URL example attempts to connect to a non-secure server listening on port 12331:

http://
 server.example.com:12331

 

Types of Certificates

If you installed your secure server from the RPM package provided in Red Hat Linux , a random key and a test certificate are generated and put into the appropriate directories. Before you begin using your secure server, however, generate your own key and obtain a certificate which correctly identifies your server.

You need a key and a certificate to operate your secure server — which means that you can either generate a self-signed certificate or purchase a CA-signed certificate from a CA. What are the differences between the two?

A CA-signed certificate provides two important capabilities for your server:

If your secure server is being accessed by the public at large, your secure server needs a certificate signed by a CA so that people who visit your website know that the website is owned by the organization who claims to own it. Before signing a certificate, a CA verifies that the organization requesting the certificate was actually who they claimed to be.

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

You can generate a self-signed certificate for your secure server, but be aware that a self-signed certificate does not provide the same functionality as a CA-signed certificate. A self-signed certificate is not automatically recognized by most Web browsers, and a self-signed certificate does not provide any guarantee concerning the identity of the organization that is providing the website. A CA-signed certificate provides both of these important capabilities for a secure server. If your secure server will be used in a production environment, you probably need a CA-signed certificate.

The process of getting a certificate from a CA is fairly easy. A quick overview is as follows:

  1. Create an encryption private and public key pair.

  2. Create a certificate request based on the public key. The certificate request contains information about your server and the company hosting it.

  3. Send the certificate request, along with documents proving your identity, to a CA. We cannot tell you which certificate authority to choose. Your decision may be based on your past experiences, or on the experiences of your friends or colleagues, or purely on monetary factors.

    Once you have decided upon a CA, you will need to follow the instructions they provide on how to obtain a certificate from them.

  4. When the CA is satisfied that you are indeed who you claim to be, they will send you a digital certificate.

  5. Install this certificate on your secure server, and begin handling secure transactions.

Whether you are getting a certificate from a CA or generating your own self-signed certificate, the first step is to generate a key. See Section 20.6 Generating a Key for instructions on how to generate a key.

 

Generating a Certificate Request to Send to a CA

Once you have created a key, the next step is to generate a certificate request which you need to send to the CA of your choice. Make sure you are in the /usr/share/ssl/certs directory, and type in the following command:

 make certreq

Your system will display the following output and will ask you for your passphrase (unless you disabled the passphrase option):

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

Type in the passphrase that you chose when you were generating your key. Your system will display some instructions and then ask for a series of responses from you. Your inputs are incorporated into the certificate request. The display, with example responses, looks similar to the following:

 You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a
DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
-----
Country Name (2 letter code) [GB]:
 

US

State or Province Name (full name) [Berkshire]:

North Carolina

Locality Name (eg, city) [Newbury]:

Raleigh

Organization Name (eg, company) [My Company Ltd]:

Test Company

Organizational Unit Name (eg, section) []:

Testing

Common Name (your name or server's hostname) []:

test.example.com

Email Address []:

admin@example.com

Please enter the following 'extra' attributes to be sent with your certificate request A challenge password []: An optional company name []:

The default answers appear in brackets [] immediately after each request for input. For example, the first information required is the name of the country where the certificate will be used, shown like the following:

 Country Name (2 letter code) [GB]:

The default input, in brackets, is GB. To accept the default, press [Enter], or fill in your country's two letter code.

You will have to type in the rest of the values. All of these should be self-explanatory, but you need to follow these guidelines:

The file /etc/httpd/conf/ssl.csr/server.csr is created when you have finished entering your information. This file is your certificate request, ready to send to your CA.

After you have decided on a CA, follow the instructions they provide on their website. Their instructions will tell you how to send your certificate request, any other documentation that they require, and your payment to them.

After you have fulfilled the CA's requirements, they will send a certificate to you (usually by email). Save (or cut and paste) the certificate that they send you as /etc/httpd/conf/ssl.crt/server.crt. Be sure to keep a backup of this file.

 

Generating a Key

You must be root to generate a key.

First, cd to the /etc/httpd/conf directory. Remove the fake key and certificate that were generated during the installation with the following commands:

 rm ssl.key/server.key

 rm ssl.crt/server.crt

Next, you need to create your own random key. Change to the /usr/share/ssl/certs directory, and type in the following command:

 make genkey

Your system will display a message similar to the following:

 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:

You now need to type in a passphrase. For best security, it should contain at least eight characters, include numbers and/or punctuation, and not be a word in a dictionary. Also, remember that your passphrase is case sensitive.

You will need to remember and enter this passphrase every time you start your secure server, so do not forget it.

Re-type the passphrase to verify that it is correct. Once you have typed it in correctly, /etc/httpd/conf/ssl.key/server.key, containing your key, is created.

Note that if you do not want to type in a passphrase every time you start your secure server, you will need to use the following two commands instead of make genkey to create the key.

Use the following command to create your key:

 /usr/bin/openssl genrsa 1024 > /etc/httpd/conf/ssl.key/server.key

Then use the following command to make sure the permissions are set correctly for the file:

 chmod go-rwx /etc/httpd/conf/ssl.key/server.key

After you use the above commands to create your key, you will not need to use a passphrase to start your secure server.

Disabling the passphrase feature for your secure server is a security risk. It is NOT recommend that you disable the passphrase feature for secure server.

The problems associated with not using a passphrase are directly related to the security maintained on the host machine. For example, if an unscrupulous individual compromises the regular UNIX security on the host machine, that person could obtain your private key (the contents of your server.key file). The key could be used to serve Web pages that appear to be from your secure server.

If UNIX security practices are rigorously maintained on the host computer (all operating system patches and updates are installed as soon as they are available, no unnecessary or risky services are operating, and so on), secure server's passphrase may seem unnecessary. However, since your secure server should not need to be re-booted very often, the extra security provided by entering a passphrase is a worthwhile effort in most cases.

The server.key file should be owned by the root user on your system and should not be accessible to any other user. Make a backup copy of this file. and keep the backup copy in a safe, secure place. You need the backup copy because if you ever lose the server.key file after using it to create your certificate request, your certificate will no longer work and the CA will not be able to help you. Your only option would be to request (and pay for) a new certificate.

If you are going to purchase a certificate from a CA, continue to Section 20.7 Generating a Certificate Request to Send to a CA. If you are generating your own self-signed certificate, continue to Section 20.8 Creating a Self-Signed Certificate.

 

Testing The Certificate

To test the test certificate installed by default, a CA-signed certificate, and a self-signed certificate, point your Web browser to the following home page (replacing server.example.com with your domain name):

https://
 server.example.com

Note the s after http. The https: prefix is used for secure HTTP transactions.

If you are using a CA-signed certificate from a well-known CA, your browser will probably automatically accept the certificate (without prompting you for input) and create the secure connection. Your browser will not automatically recognize a test or a self-signed certificate, because the certificate is not signed by a CA. If you are not using a certificate from a CA, follow the instructions provided by your browser to accept the certificate.

Once your browser accepts the certificate, your secure server will show you a default home page.

 

Using Pre-Existing Keys and Certificates

If you already have an existing key and certificate (for example, if you are installing the secure server to replace another company's secure server product), you can probably be able to use your existing key and certificate with the secure server. In the following two situations, you are not able to use your existing key and certificate:

If you have an existing key and certificate that you can use, you do not have to generate a new key and obtain a new certificate. However, you may need to move and rename the files which contain your key and certificate.

Move your existing key file to:

 /etc/httpd/conf/ssl.key/server.key

Move your existing certificate file to:

 /etc/httpd/conf/ssl.crt/server.crt

After you have moved your key and certificate, skip to Section 20.9 Testing The Certificate.

If you are upgrading from the Red Hat Secure Web Server, your old key ( httpsd.key) and certificate ( httpsd.crt) are located in /etc/httpd/conf/. Move and rename your key and certificate so that the secure server can use them. Use the following two commands to move and rename your key and certificate files:

 mv /etc/httpd/conf/httpsd.key /etc/httpd/conf/ssl.key/server.key
mv /etc/httpd/conf/httpsd.crt /etc/httpd/conf/ssl.crt/server.crt

Then start your secure server with the command:

 /sbin/service httpd start

For a secure server, you are prompted to enter your passphrase. After you type it in and press [Enter], the server will start.

 

An Overview of Security-Related Packages

To enable the secure server, you need to have the following packages installed at a minimum:

httpd

The httpd package contains the httpd daemon and related utilities, configuration files, icons, Apache HTTP Server modules, man pages and other files used by the Apache HTTP Server.

mod_ssl

The mod_ssl package includes the mod_ssl module, which provides strong cryptography for the Apache HTTP Server via the Secure Sockets Layer (SSL) and Transport Layer Security (TLS) protocols.

openssl

The openssl package contains the OpenSSL toolkit. The OpenSSL toolkit implements the SSL and TLS protocols and also includes a general purpose cryptography library.

Additionally, other software packages included with Red Hat Linux can provide certain security functionalities (but are not required by the secure server to function):

httpd-devel

The httpd-devel package contains the Apache HTTP Server include files, header files and the APXS utility. You will need all of these if you intend to load any extra modules, other than the modules provided with this product.

If you do not intend to load other modules onto your Apache HTTP Server, you do not need to install this package.

httpd-manual

The httpd-manual package contains the Apache Project's Apache User's Guide in HTML format. This manual is also available on the Web at http://httpd.apache.org/docs-2.0/.

OpenSSH packages

The OpenSSH packages provide the OpenSSH set of network connectivity tools for logging into and executing commands on a remote machine. OpenSSH tools encrypt all traffic (including passwords), so you can avoid eavesdropping, connection hijacking, and other attacks on the communications between your machine and the remote machine.

The openssh package includes core files needed by both the OpenSSH client programs and the OpenSSH server. The openssh package also contains scp, a secure replacement for rcp (for copying files between machines).

The openssh-askpass package supports the display of a dialog window which prompts for a password during use of the OpenSSH agent.

The openssh-askpass-gnome package can be used in conjunction with the GNOME desktop environment to display a graphical dialog window when OpenSSH programs prompt for a password. If you are running GNOME and using OpenSSH utilities, you should install this package.

The openssh.server package contains the sshd secure shell daemon and related files. The secure sh


 

Home