It started innocently enough.
In the mid-1990s some kind of encryption was needed in order to protect information – such as financial information – as it traveled across the Internet between a user’s Web browser and a firm’s Web server.
The solution was close at hand; public-key encryption. Here’s the basic concept. If you have something you want to send me, I give you a “public key.” You “lock” the information using the public key, then send it to me. Now, here’s where the system gets really clever; the public key you used to lock the information can’t be used to unlock the information. Instead, I have to use a mathematically related “private” key to unlock the information. How does this all work? It doesn’t matter. It’s magic, something to do with mathematics, long numbers and stuff. All you need to know is that the key that is used to lock – to encrypt – the information won’t unlock it.
So, here’s what happens when you access a secure page with your browser. The Web server sends your browser a special certificate. This certificate contains the public key. When you enter, say, your credit-card information and click the Submit button, your browser encrypts the information and then transmits it across the Internet to the Web server. If the information were to be intercepted somewhere between here and there, the person intercepting the information gets a bunch of useless, scrambled data. Now, when the information arrives at the Web server, the server uses its matching private key to unlock the data … to decrypt, or unscramble, your credit-card information.
This is a great thing, and for years now public-key encryption technology – more commonly known as SSL (secure sockets layer) or https (secure hypertext transmission protocol) _ has been built into both browsers and Web servers. In fact there’s no need to buy anything, the technology required to encrypt data is free.
But someone had another idea.
Someone, somewhere, said something like this: “Hey, if we’re going to add this encryption stuff, we could also have a central body issue special certificates that would verify the owner of the certificate.” So what happened was that browsers were given a little more technology. Not only could a browser accept and use a certificate _ the public key _ but it could check to see where the certificate came from, and inform the user if the certificate was issued by an organization that the browser doesn’t recognize. The user will see what appears to be an error message. It’s really just an information message, but having this message appear will dramatically reduce the number of people willing to buy from your site because it spooks them. They don’t know what it means, but it can’t be good.
And thus the scam began.
Why do server administrators buy SSL certificates? Is it so they can encrypt data being transmitted between browsers and their Web servers? No, they can create their own certificates and set up encryption for free. Essentially, they are paying – somewhere between $330 and $1,500 a year if they foolishly buy from VeriSign, the brand leader – so the informational message doesn’t appear.
The companies selling these certificates will tell you that they verify the company buying the certificates, that they check to see that the business buying the certificate is for real, as it were, and that this provides your site’s visitors – your clients – with confidence about doing business with you. This simply isn’t true.
Users don’t know anything about SSL certificates, so how can a certificate provide confidence? Certificates are often shared. Hundreds of companies using a single certificate issued to a hosting company, for instance (I’ve shared certificates owned by Yahoo, for instance). It’s also possible to buy certificates “without” any kind of verification. All in all, the “confidence” argument is nonsense. No, at the end of the day you have to buy the certificate so your clients don’t get scared off your site by an error message. In effect this little scam is a protection racket: “Give us your money, or we’ll stand outside your store, and scare clients away!”
So, what can you do? Well, if you’re doing business online, you really have to get one of these certificates. The only thing you can do is reduce what you spend. Don’t buy from VeriSign … buy from a company selling cheaper certificates, such as GoDaddy.com or InstantSSL.com; the latter sells certificates for as little as $55 a year and even provides free 90-day certificates. Secondly, always get the cheapest certificate on offer. You don’t need the premium or deluxe version, or whatever they call them … get the basic, cheapest certificate and reduce your protection payments to a minimum.
Peter Kent is an e-commerce consultant in Denver. He’s currently working with e-book software company DNAML, www.DNAML.com, to introduce its products to U.S. Publishers.