One leg of the internet security stool is the SSL certificate. The cert is the basis for the transport encryption that protects your data from prying hackers — well, supposedly, although there have been suggestions that the NSA could probably break current SSL. But, anyway, NSA is probably not going to steal your identity.

SSL certificates cost money. Potentially, a lot of money. The reason is, each certificate is created for one specific web server or property. When you create a cert, you specifically assign it to “www.upyours.com,” or “secure.keepyourhandsoffmystack.com” — and that cert is technically no good anywhere else. By technically, I mean that you can use it somewhere else, like “iamtoocheaptobuyacert.org,” but anyone who hits that site is going to get a certificate error. The certificate error is going to tell you that the cert name does not match the site name, and you should not go there.

The idea behind this name matching scheme is to prevent attacks in which the attacker uses a dummy certificate to trick you into going to the wrong site. As a cautious user, you would never go to a site that has a name mismatch.

Of course, you aren’t a cautious user, you’re a determined one — determined to spend money at some company that’s too cheap to buy all the certs it actually needs. And so, you click past the certificate error and get on to that wallet action.

Another common certificate error that you will encounter is the “no trusted authority” error. The second leg of the security stool is that certificates must be issued by a recognized “certificate authority,” also known as the root certificate authority. Verisign is one example of a company authorized to act as such an authority. This authority is supposed to act as guarantor that your secure connection is going to a legitimate site, and not some hacky-sack phony.

When web sites are under development, many instances of the site will be in the hands of developers, and consequently, many certs may be needed. But, they’re not needed for public or internet usage — only for private usage. So, web development environments like Visual Studio provide simple tools that can be used to create a “self-signed” certificate. This certificate allows developers to create the necessary environment for their code.

The problem arises when the development is complete and the new site is published — along with the “self-signed” certificate. For various reasons, at top of which list is “save money,” companies decide not to swap in a legitimate certificate when the site goes live, and instead continue to use the “self-signed,” illegitimate, free one.

Now, you have two legs of the stool sawn through part way. To protect users against bogus certificates, a web site’s SSL certificate should be issued to the site name, and it should be issued by a trusted root authority. To save money, possibly also from laziness, legitimate companies use SSL data encryption, but deliberately ignore the rules of putting that security in place. By so doing, they imbue users with the sense that certificate errors don’t matter, and habituate them to clicking past them without serious thought. But, the third leg of our security stool is the willingness of users to attend to, and take seriously, certificate errors.

It’s not the 99% of the times that the landing site is legitimate, it’s the 1% when it’s not, that will do damage.

I really get irked by these certificate errors. Comcast is one such sinner — its subdomain activate.comcast.com uses a self-signed certificate. Another is my bank, Mutual Security Credit Union. It recently farmed out its online account management tools to a third party, but still continues to use its mscu.net certificate, even though the site is now at netteller.com. It’s BS, and I don’t see an end to it, unless somebody really gets burned by one of these illegitimate certs. Isn’t that the way of it?