What do I need to consider when purchasing a SSL certificate?
The following 10 considerations must be taken into account before deciding which CA and which type of SSL certificate to purchase? Each point will be discussed in more detail on this page, or you can click each link now to jump straight to a particluar section.

1. What type of web site application. Low volume, professional or development?
   
   
2. How credible and stable is the CA issuing the SSL certificate?
   
   
3. What browser recognition is required?
   
   
4. Do I require a single root or intermediate SSL certificate?
   
   
5. What certificate strength is required?
   
   
6. Is technical support available from the CA for installation or CSR issues?
   
   
7. Do I need warranty?
   
   
8. What type of validation is required?
   
   
9. How fast do I want my certificate?
   
   
10. What budget do I have for my certificate?

Lets look at each point in turn.

1. What type of web site application. Low volume, professional or development?
Perhaps the most important differentiation between all the SSL certificates available on the market today, is the strength of the brand behind the SSL technology. SSL technology besides ensuring secure transmission of data, is an essential element in providing online customers with the confidence to buy or use a product or service.

For example, the greater the number of users visiting a website, the greater the probability that some customers may not complete a transaction, simply because they do not recognise or trust the brand behind the SSL technology.

Inevitably the well known brands from the credible long standing CAs are the most expensive SSL certificates on the market. If you have a low volume or development website and you decide that your customer's confidence is not affected at all by the brand behind the SSL certificate or the volume of customers that would have an issue are insignificant in number then the choice of CA and certificate is increased. Low volume websites can therefore enjoy significant savings on the SSL purchases by purchasing the lesser known brands of SSL certificates.

We suggest as a guide that if a website is performing more than 50 transactions per week then, it is advisable to use a known SSL brand.

Another important consideration is the typical or average transaction value that a website will process. If customers are expected to pay high amounts online the greater the probability that some customers may not complete a transaction because they do not trust the brand behind the SSL technology.

We suggest as a guide that if a website has an average transaction of greater than 50 USD, it is advisable to use a known SSL brand from a reputable CA.

2. How credible and stable is the CA issuing the SSL certificate?
Clearly for any SSL certificate to be taken seriously, it is important to ensure that the CA issuing the SSL certificate is well established and credible. The best way of determining the credibility of a CA is by simply establishing whether the CA in question owns its own trusted root i.e. does the CA own a root that is already present in all popular browsers?

You can examine trusted root ownership by double clicking the padlock seen in the browser during an SSL connection with a webserver. When the SSL Certificate appears, simply click the "Certification Path" tab to see which trusted root CA certificate issued the SSL certificate.

It is also possible to see the trusted roots referenced in a browser e.g. for IE6, go to "Tools", "Internet Options" and select "Content", "Certificates" and then the tab "Trusted Root Certification Authorities".

GeoTrust owns the Equifax root (Equifax Digital Certificate services became GeoTrust in 2001).

RapidSSL.com's RapidSSL product owns its own root. RapidSSL.com uses a different Equifax root (Equifax Secure eBusiness CA-1).

RapidSSL.com's RapidSSL Wildcard product uses an intermediate certificate issued by the Equifax Secure eBusiness CA-1 root, making it the only stable chained root certificate available on the market today.

Business stability is also an essential component when selecting any supplier. Whilst we do not examine financial stability of each CA in detail in this white paper, enterprise class accounts are advised to conduct their own due diligence into each CA, as well as examine the root CA certificate ownership.

When selecting a CA, always therefore consider the long term stability of the CA, especially if a longer term enterprise solution is required.

If the CA relies on an intermediate certificate - consider the long-term stability of the CA supplying the intermediate, and obviously the stability of the supplier relationship between the two CAs.

Clearly it is very advisable to ensure the integrity of the CA and to establish which CA is issuing the SSL certificate to be used.

3. What browser recognition is required?
Browser recognition or ubiquity is the term used in the industry to describe the estimated percentage of Internet users that will inherently trust an SSL certificate.

Certification Authorities who own their own roots, have what are known as Root CA Certificates. These root CA certificates are added into releases of all the major browsers such as Internet Explorer, Netscape, Opera, etc by the browser vendor (such as Microsoft). When a browser is used, it automatically relies on a "list" of root CA certificates that the browser vendor has deemed trustworthy. If a SSL certificate is issued by one of the trusted root CAs, then the browser will inherently trust the SSL certificate and the gold padlock will appear transparently during secure sessions.

The browser stores the CA roots that can be trusted, therefore if a browser encounters a website using a SSL certificate issued by a CA root it does not trust, the browser will display warning messages to the website visitor. The lower the browser ubiquity, the less people will trust a certificate - clearly, a commercial site will require as many people as possible to trust a SSL certificate.

The general rule is that any SSL certificate with over 95% browser ubiquity is acceptable for a commercial site.

As with any form of statistics, browser ubiquity is open to interpretation, hence in the Appendix, the table does not place a great deal of validity in presenting browser recognition "percentages", instead it simply concludes whether a SSL Certificate is acceptable for commercial sites.

Why is browser recognition important?
If a website visitor is using a browser that does not contain the root CA certificate used to issue the SSL certificate, they will be prompted with a security warning:

The signifies that the SSL Certificate has been issued by a CA that the browser does not trust. As more people upgrade their old browsers, this message becomes less frequent. It is also worth noting that people who do not upgrade their browsers are less technically and security savvy and hence are less likely to purchase from websites.

Another consideration often overlooked concerning the overall ubiquity of a SSL certificate is the issue over Webserver Compatibility. The SSL Certificate is required to be installed onto a webserver. Generally, all webservers accept all SSL certificates currently available but it is recommended to check with the CA to be sure. Webservers such as Apache (including the website control panel variants), IIS, Webstar, Website Pro, Java based, iPlanet, Zeus, Netscape server, Cobalt support the certificates of all SSL certificates featured in this whitepaper.

There are few webservers still in use that do not support the use of intermediate certificates. Such webservers are not SSL v3 compliant. If your webserver does not support SSL v3, then you will need to select a CA that issues certificates directly off its root such as GeoTrust and RapidSSL.com.

4. Do I require a single root or intermediate SSL certificate?
Some certificates are issued directly by a Trusted Root CA certificate e.g. GeoTrust. The Trusted Root CA certificate is already contained within all popular browsers, and hence is already trusted. Some Certification Authorities do not have a Trusted Root CA certificate present in browsers, therefore they need a "chained root" in order for their certificates to be trusted.

Both RapidSSL.com's RapidSSL Wildcard product and Comodo's InstantSSL product are chained root certificates. However RapidSSL.com own the trusted CA root used to issue RapidSSL Wildcard and are therefore the only stable chained root provider. Comodo do not own the BeTrusted root used to issue InstantSSL certificates and therefore cannot offer the stability of RapidSSL Wildcard.

Both RapidSSL and all of the Professional Level Certificates offered by RapidSSL.com are single root certificates.

Compared to single root installations, chained root certificates require additional webserver installation steps. If a CA is chosen that requires the installation of more than one certificate, then it is advisable to ensure that the necessary technical expertise or resources to be able to perform the installation are available. Loading and managing multiple certificates per installation, especially in an enterprise environment, can be costly and cumbersome.

Certification Authorities (CAs) that own their own roots are long-time security providers who have long term relationships with the browser vendors for the inclusion of their Trusted Root CA certificates. For this reason, such CAs are seen as being considerably more credible and stable than chained root certificate providers.

5. What certificate strength is required?
Generally there are two strengths of certificate in existence - 40 bit & 128 bit.

The bit size indicates the length of the key size used for the encryption during a secure SSL session. Hovering the mouse over the gold padlock will detail the current strength of encryption being used:

Why is encryption strength important?
The bigger the number, the longer it takes for computer(s) to crack or break the code.

• 40 bit: It is computationally feasible to crack a 40 bit key. For this reason 40 bit encryption is rarely used.
  
  
• 128 bit: It is computationally unfeasible to crack a 128 bit key. All banking infrastructures use 128 bit encryption.
  We strongly recommend the use of 128 bit SSL encryption for any application or website.

6. Is technical support available from the CA should I need it?
Installing a SSL certificate can sometimes be tricky - you will need to first generate a CSR and then install your issued certificate. For this reason it is essential that the CA provides sufficient and timely support.

All CAs provide some level of support, even if it is only email and web based. Most issues can easily be solved using the expansive online resources and knowledge bases provided by the CA. However, should an issue arise, it is highly recommended that there is access to technical support staff, therefore make sure the CA clearly publishes a technical support telephone number. Also, be aware that some CAs charge extra for telephone support.

7. Do I need warranty?
The warranty level is the financial protection awarded to end customers against the CA misissuing an SSL Certificate. If a customer relies on the information within a misissued SSL Certificate and suffers financial loss as a direct result of relying on the certificate, the CA will hold insurance to cover claims made by the customer against the CA. Effectively, the warranty is the insurance taken out by the CA to protect itself in the event it makes a mistake.

Verisign offers a more advanced insurance policy in that it will also provide insurance against a compromise of a private key or loss of certificate - but such insurance comes at a price.

How likely is a missisuance?
It is highly unlikely that a WebTrust compliant CA will mississue a certificate. All WebTrust compliant CAs have passed certification to ensure that procedures and policies are in place that make misissuance improbable. For this reason, many WebTrust compliant CAs do not offer a warranty at all.

Some CAs will offer the warranty as a means of adding perceived value to their SSL certificates.

8. What type of validation is required?
A trust hierarchy demands that entities "vouch" for each other. Companies that issue SSL certificates are in the business of establishing that entities on the web are, in fact, who they claim to be. The potential for criminal activity on the web (in relevance to SSL anyway), is in online 'hijacking' of sites or connections to siphon encrypted data. Persons so inclined can easily "copy" web site interfaces and pose as well known vendors, simply to collect these data.

SSL certificates work to prevent this through ensuring that www.abc.com is, in fact, ABC Co. In the "real world" we use identification procedures like photo ids, telephone calls and papers of incorporation to know with whom we are dealing. If products or services are defective, buyers can seek recourse. In the "online world", companies wishing to use SSL certificates must prove to the certificate authority that they have the right to present themselves online as ABC Co.

This is done through a variety of means in different SSL products. For the sake of simplicity, consider the method started and championed by Verisign, as the 'traditional' model. The process involves certificate petitioners faxing in their articles of incorporation, and then waiting several days to be granted a certificate to do business online under that name. There is a fair amount of overhead related to this task, as these credentials are examined and reviewed, and full-service products in this arena can cost hundreds of dollars.

There are newer, lower-cost alternatives in which certificates are issued more quickly. These certificates verify that the certificate holder is the owner of that domain, ensuring customers that domain name "owners" are who they claim to be.

There are also other validation options, like two-way, real-time telephony. Certificate applicants are required to provide telephone numbers, and certificate authorities call to verify basic information, yet another way to seek recourse in the event of problems.

So there are essentially two types of validation available, manual and automated.

Manual Validation.
Involves the validation of domain name ownership and business legitimacy using humans. This process is traditionally slow and takes up to two working days, often longer. A manually validated certificate usually contains the following information within the certificate:

Auto-Validation.
Computers, databases and automated routines validate domain name ownership and business legitimacy. The process takes minutes rather than days. The GeoTrust QuickSSL product and RapidSSL.com FreeSSL and ChainedSSL products use automated validation to issue SSL certificates within 10 minutes. Their automated validation processes are WebTrust compliant and use Domain Control validation and Unique Business Registration to validate the applicant before issuing the certificate.

An automatically validated certificate, such as the GeoTrust or RapidSSL.com certificates, contain the following information within the certificate:

9. How fast do I want my certificate?
The principal delay associated with the issuance process of SSL is the validation process adopted.

For fast issuance of certificates, it is advisable to use automated methods of validation.

Be very careful when confirming the issuance time with a CA. Some may suggest immediate delivery once they have obtained all your company documentation in the format required and have initiated the validation. This process may still take up to 2 days from start to finish.

10. What budget do I have for my certificate?
Certificates range dramatically in price from one CA to another. The highest prices are 40 times the lowest prices!

This white paper has examined numerous points of consideration in determining which SSL certificate to purchase.

The correct choice of SSL certificate is principally dependent on the application type and on whether there is a need for a well known brand of SSL that has been issued from a highly trusted and credible CA.

There are however significant savings available for websites conducting low volume / low value transactions. Some SSL certificate types are perfect for development environments, whilst other certificate types suit professional requirements. Buyers are therefore urged to carefully consider their choice of CA before purchasing.

Page 2		Page 4

Page Shortcuts
1 | 2 | 3 | 4 | 5

© 2005 RapidSSL.com.