Secure Sockets Layer (SSL) is the backbone of e-commerce on the web. It is the protocol used to encrypt communications between a web browser and web server, though it can also be used for other applications. To use SSL on your own web server, you often need to deal with an external company called a certificate authority (CA). Three major considerations come into play when choosing a CA: trust, audience and cost.

Quick SSL background

SSL was created by Netscape to enable secure e-commerce and rapidly became a de facto standard. SSL uses public key encryption methods to verify the authenticity of a server or client and encrypt communications between them. In a typical web-based application, it is the client that requires authentication from a server. To identify itself, an SSL certificate is installed on a web server and the client checks the credentials of the certificate to make sure it is valid and signed by a trusted third party. Trusted third parties that sign SSL certificates are called certificate authorities.

The life and death of an SSL certificate

This is the standard process used to get an SSL certificate from a CA. I won't repeat the installation details because excellent guides abound.

User creates an SSL key pair (public/private)
User creates a Certificate Signing Request (CSR)
User sends the CSR to a CA
CA returns a signed SSL certificate
User installs certificate on web server
Certificate expires (or is renewed)
 
In Linux, the CSR is created with openssl. Each CA has guidelines on their web site about how to fill out the fields in the CSR. Not all fields are used by all CAs.

Trust

The goal of using SSL is to prove your identity (either as a server or a client). To do that, you have to trust the certificate authority, the certificate authority has to trust you (by verifying you are who you claim to be), and the client has to trust the certificate authority. If you pick a CA that your clients don't trust, you lose business.

The procedures and policies used by different CAs to verify your identity are not uniform. Sometimes, a CA will require printed letterhead with the address of your organization on it and follow up with a phone call to the contacts. Some go further and look up Dun and Bradstreet information or use online resources. One CA I worked with recently required that the domain be listed in a particular WHOIS database. These details may add to or diminish your confidence in the judgment of a CA. One that does no verification at all won't instill a lot of trust in your clients.

Audience

Another major consideration is whether the user base will be mostly internal or external. If internal, you theoretically have more control over the client configuration and more options when it comes to CAs. If external, you have no control over the client, and you can't afford to inconvenience them just to use your web site.

Most web browsers come with a set of CA certificates already installed. These trusted CA certificates are used to validate the signature on certificates downloaded from other computers. The browser will warn you if it doesn't recognize the signer. Sometimes this warning will scare off uninformed visitors. While you can add additional third-party CA certificates to most web browsers, many people don't understand how to do it, and don't want to be bothered. This puts the pre-loaded certificate authorities in an advantageous position.

I compared the pre-loaded certificates in the following browsers to find the common ones. Here are the common CAs I found in IE 6, Firefox 1.5, Opera 8.5, and Safari (Tiger):

Common CAs across browsers
 
  Baltimore Cybertrust
  Entrust
  Equifax
  GTE
  TC Trustcenter
  Thawte
  UTN
  ValiCert
  Verisign
 
 Note: I found it interesting that the root CAs in Safari are stored in a keychain database and can't be viewed from within the browser. So much for ease of use. I had to use a command line tool called security to dump the CAs out of the database.

The most conservative approach is to use one of the common pre-loaded CAs. This ensures there will be no pop-up warnings when people visit your SSL-enabled site. This assurance comes at a price since the popular CAs charge more for their services.

An organization that has the resources may choose to set up the necessary infrastructure and act as its own CA, especially for internal projects. Self-signed certificates may be created and client certificates installed to identify both the client and any server with which it communicates.  


Cost

The services provided by a CA are largely the same. They process CSRs and sign and return certificates. However, the cost of certificates varies widely. When I priced a two -year certificate from two of the top CAs, one was double the price of the other. Prices reflect the expiration date, (usually one, two or three years from the date it is signed), encryption strength, whether the CA certificates come pre-loaded in most browsers and reputation. Special features, like a certificate that can be used with domain wildcards, also cost extra.

Some CAs may offer optional services that make it easier to track certificates or renew them faster. If you are managing hundreds of certificates, those services may be worth the expense. If you are managing only a handful, those extra services are overkill.

There are several low-cost CAs, and even one that will sign your certificate for free. The root certificates of most bargain CAs do not come pre-loaded in the browsers, so they are probably not the best choice for external applications.


Decide for yourself

Knowing your application, audience and budget, you can narrow your choice of CAs down to a short list. From that list, go with the least expensive one that you trust. If you aren't comfortable working with a particular CA, your customers probably aren't either.

Taken from: http://www.hostingtech.com/?m=show&id=1378
Submitted by Ahmad Permessur