If not, than this is exactly what we need to establish HTTPS as the new standard.
If not, than this is exactly what we need to establish HTTPS as the new standard.
The cheap certs only offer domain verification; in other words, they verify that the person holding the certificate owns the domain in question. Typically via an automated email to one of the contact addresses associated with the domain. The catch here is that you're only allowed to fill out the CN= (domain) field in your cert; the others are blanked out. For what most people use SSL for, that's sufficient.
The more expensive certs will go a step further and verify the identity of the entity or person holding the certificate. This entails things like checking your articles of incorporation if your'e a business; things that tend to require a human operator at the CA reviewing your submission. In return, you get to fill out more fields in your certificate. However, nobody ever looks at the details for certs, so this is pretty much wasted money, IMHO.
The only point at which the more expensive certs get you something of value is:
1. You pay to get a wildcard cert, which lets you use your cert on as many subdomains as you want. If you actually need it for technical reasons (e.g. you let users create their own subdomains), this might be worthwhile. Most folks won't need this.
2. You pay to get an "Extended Validation" or "EV" cert, which gets you a little green box in the address bar with your company name. There's strict requirements on identity validation to get these, and it's supposed to engender more trust on the part of users. They're also very expensive. Personally, I suspect nobody really cares about these and it's just a racket for the CAs. But opinions vary.
It also drives me nuts that browsers still class self-signed certs below normal (non-ev) certs when they basically offer the same level of guarantees (in terms of "this person is who they claim to be")
That said, there are many ways in which browsers could improve the handling of self-signed certificates. For example, having a Convergence-like system to fall back to seems useful. Another possibility would be to use opportunistic encryption, where all access is encrypted even without a certificate. (This would defend only against passive attackers, but it's better than no encryption.)
They should be alright for most stuff, especially for personal use.
And they're free because it costs them nothing to issue them.
The first sentence and a half of this paragraph[1] from https://startssl.com/policy.pdf expressly forbid it. Its final "when" clause might be trying to limit what is forbidden, but, grammatically, it has no power to restrict the first sentence, and doesn't properly restrict the second sentence either.
[1] "Class 1 certificates are limited to client and server certificates, whereas the later is restricted in its usage for non-commercial purpose only. Subscribers MUST upgrade to Class 2 or higher level for any domain and site of commercial nature, when using high-profile brands and names or if involved in obtaining or relaying sensitive information such as health records, financial details, personal information etc."
(Naturally, I hope I've misunderstood their policy.)
We tried to switch our site to https only recently, and had to backtrack because of this (and because we are too cheap/stubborn to buy an SSL cert from someone who is in the XP trusted root certs).
Those aren't horrible trade offs tho, but yes, those are limitations.