exclusive content published on June 5, 2006

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 defacto 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, sign, and return certificates. However, the cost of certificates vary widely. When I priced a 2 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.

update June 8, 2006: Eddy Nigg from Startcom.org wrote to say the Startcom root certificate has been approved to be included in all future versions of Firefox and Thunderbird. Startcom is working to get it into all popular browsers as quickly as possible.