Secure Socket Layer

Introduction
The Secure Socket Layer (SSL) is a protocol independent transport layer for sending encrypted information over the Internet. SSL provides encryption preventing eves-droppers from being able to see the information. It also provides authentication to prevent people spoofing their identity. The SSL protocol is an open specification backed by all major vendors including Microsoft and Netscape.

Concepts
The SSL protocol uses public key cryptography. The server has a certificate that includes a public key. At the start of an SSL session, the server sends the browser this certificate. The browser then generates a random number that is used as the session-key. The browser then encrypts this with the server's public key, so only the server can decrypt it with the server's private-key. A session key has now been exchanged that is known only by the browser and the server. This session-key is then used as the key encode data for the rest of the session.

The certificate contains information about the server, and the organisation that runs it. Certificates need to be signed by Certificate Authorities to guarantee that the organisation running the server is who they say they are. In order to get a signed certificate, you must create a Certificate Request and send that to a Certificate Authority along with appropriate documentation to prove your identity.

For test purposes you can create a self-signed certificate. This allows for data to sent encrypted, but the browser will not be able to check that you're not pretending to be someone else.

Creating a Private Key
Before you create a private key, you must first appreciate its value. If anyone was to get hold of your private key, they could decrypt all your encrypted communication. They could also masquerade as you, and take credit-card orders pretending to be you. It is therefore of great importance, that once you generate your key, you keep it secret. For security reasons you should not transmit your private key over a network. For this reason the tools provided to create keys are command line only and the web interface does not display the private key. A program called cert is provided for this purpose. It lives in the $ZEUSHOME/admin/bin directory. 

Usage: cert -new -type private -out <private_key_file>
This file will be created with 0400 permissions, so that only the user who created the key can read it.

Creating a Certificate Request
For an SSL enabled browser to connect seamlessly to your site you must now have your new private key signed by a Certificate Authority (CA). The CA will require an X509 certificate request in order to return you a signed key. The cert program can be used to create an appropriate request. 

Usage : cert -new -type request -key <private_key_file>
	     -out <outfile>
The output file can now be send to a certificate request, who will, for a fee, return you back a signed certificate request. Zeus recommends Thawte Consulting as the best certificate authority to use with your Zeus Server.

Creating a Self-Signed Certificate
For test purposes, you might just want to create a certificate that you sign yourself. This avoids the delays and costs of getting a certificate authority to validate your identity. As users will have no means of validating the certificate these should not generally be used in public sites.

To created a self signed certificate use the following command 

Usage : cert -new -type public -key <private_key_file;> 
	     -out <output_file>
This will produce a self signed certificate containing your public key.

Making a Server Secure
In order to make a virtual server secure you need to follow these instructions.

Chained Certificates
Each public certificate your secure website presents to its web clients ought to be signed by a trusted CA certificate. Web clients trust certificates signed by several well known CA's (Verisign, Thawte etc).

Other CA's can obtain signing certificates signed by one of these trusted CA's. They can use these certificates to sign public website certificates. For example:

  1. Trusted root CA 'A' decides that organisation 'B' is a legitimate certificate agency and provides them with a public key.
  2. You create your private key and certificate request and ask 'B' to generate and sign a public certificate for you ('C').
  3. You install your certificate C on your secure website.
However, when a client comes to your website and looks at your certificate they will reject it if they do not explicitly trust organisation B. You need to provide B's certificate as well as your own.

Then, the client will accept your certificate because it can trace the certificate chain of trust back to the root CA 'A' which it does trust.

You can provide a certificate chain to Zeus by concatenating the certificates together into the file you provide containing your public key. If your certificate is in the file c.pub and your CA's public certificate is in the file b.pub, do the following:

$ cp c.pub chained.pub $ cat b.pub >> chained.pub
Present the file 'chained.pub' to Zeus as your public key file.