| SSL ("Secured Socket Layer") is a protocol used to | | | | Usually, mostly price. Some expensive certificates |
| encrypt the communication between the user's | | | | have specific functions, like securing a number of |
| browser and the web server. When SSL is active, a | | | | different subdomains simultaneously (a "wildcard" |
| "little padlock" appears on the user's browser, usually | | | | certificate), but the effective differences between |
| in the status line at the bottom (at the top for Mac | | | | basic single site certificates are very slight, despite |
| Safari users.) | | | | the wide range of prices: |
| | | | |
| This assures the user that sensitive data (such as | | | | The encryption mechanism used by all of them is |
| credit card numbers) can't be viewed by anyone | | | | the same, and most use the same key length (which |
| "sniffing" the network connection (which is an | | | | is an indicator of the strength of the encryption) |
| increasing risk as more people use wireless | | | | common to most browsers (128 bit). |
| networking). | | | | |
| | | | Some of them ("chained root" certificates) are |
| Common web site owner questions about SSL: | | | | slightly more of a pain for your web host to install |
| | | | than others ("single root" certificates), but this is |
| | | | pretty much invisible to the site owner. |
| How do I get the little padlock on my site? | | | | |
| | | | The amount of actual checking on the ownership of |
| To get the little padlock, your site must have an | | | | the domain varies wildly between vendors, with |
| SSL Certificate from a Certificate Authority. Once an | | | | some (usually the more expensive) wanting significant |
| SSL Certificate has been purchased and installed, it | | | | documentation (like a D&B number), and others |
| provides three things: | | | | handling it with an automated phone call ("press #123 |
| | | | if you've just ordered a certificate"). |
| | | | |
| The ability to show a page in "Secure Mode", which | | | | Some of them offer massive monetary guarantees |
| encrypts the traffic between the browser and the | | | | as to their security (we'll pay you oodles of dollars if |
| server, as indicated by the "little padlock" on the | | | | someone cracks this code), but since it's all the same |
| user's browser. A guarantee by the issuing Certificate | | | | encryption mechanism, if someone comes up with a |
| Authority that the domain name the certificate was | | | | crack, all e-commerce sites will be scrambling, and the |
| issued for is indeed owned by the specific company | | | | odds of that vendor actually having enough cash to |
| or individual named in the certificate (visible if the | | | | pay all of its customers their oodle is probably slim. |
| user clicks on the little padlock). An assurance that | | | | |
| the domain name the certificate was issued for is the | | | | The fact is that you are buying the certificate to |
| domain name the user's browser is now on. | | | | insure the safety of the user's data, and to make |
| | | | the user confident that his or her data is secure. For |
| | | | the vast majority of users, simply having the little |
| Once obtained, the certificate must be installed on | | | | padlock show up is all they are looking for. There are |
| the web server by your web host. Since your web | | | | exceptions (I have a client in the bank software |
| host also has to generate an initial cypher key to | | | | business, and they feel that their customers (bank |
| obtain the certificate, very often they will offer to | | | | officers) are looking for a specific premier name on |
| handle the process of obtaining the certificate for | | | | the SSL certificate, so are happy to continue using |
| you. | | | | the expensive one), but most e-commerce |
| | | | customers do not pick their sellers based on who |
| My web host has a "shared certificate" that I can | | | | issued their SSL Certificates. |
| use. Should I? | | | | |
| | | | My advice is to buy the cheaper one. |
| It's still fairly common for small sites to use a shared | | | | |
| certificate from the host. In this circumstance, when | | | | I have an SSL certificate -- why shouldn't I serve all |
| a page needs to be shown in secured mode, the | | | | my pages in "Secured" mode? |
| user is actually sent to a domain owned by the web | | | | |
| host, and then back to the originating domain | | | | Because SSL has an overhead -- more data is sent |
| afterwards. | | | | with a page that is encrypted than a page that isn't. |
| | | | This translates to your site appearing to run slower, |
| A few years ago, when SSL Certificates were quite | | | | particularly for users who are on dial-up or other slow |
| expensive (around $400 per year), this was real | | | | connections. Since this also increases the total |
| attractive for new sites just getting their feet wet in | | | | amount of data transfered by your site, if your web |
| e-commerce. Today, with a number of perfectly | | | | host charges by transfer volume (or has an overage |
| functional SSL certificates available for under $100 | | | | fee, as most do), this can increase the size of your |
| (exclusive of installation, etc.), it is a lot less | | | | monthly hosting bill. |
| attractive. Since your user can look a the address line | | | | |
| of his or her web browser and see that the site | | | | The server should go into secure mode when asking |
| asking for the credit card number is not the site he | | | | a user for financial or other sensitive data (which |
| or she thought they were on, the cost savings is | | | | may well be "name, address and phone number", with |
| probably not worth the risk of scaring off a sale. | | | | today's risk of identity theft), and operate in normal |
| | | | mode otherwise. |
| What's the difference between the expensive SSL | | | | Updates to this article, and many other great articles |
| Certificates and the inexpensive ones? | | | | and tutorials for small business web site owners can |
| | | | be found at Insanely Great Sites! |