[0] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=744027
StartSSL charge you for revoking that exposed certificate, so your choices are you pay for the revocation, or wait until the certificate expires.
Now if there had been a problem with their signing certificates then I would have expected them to revoke anything affected for free and offer replacements similarly at no cost.
OK, they could have done that anyway (or perhaps offered a discount on the revoke charge) as an good will gesture, but they didn't, so what.
All they claim is to provide free certificates for non-commercial use, and that they do provide. If people read something else into that it isn't because they were deliberately led to.
Though many people picking up a cert without really knowing the infrastructure won't know about revocation infrastructure and such so might have mislead themselves by having not read the Ts&Csm.
Cheap certificates are available, however, they are still not for free. And hosting more than one domain with SSL is a problem too with most hosting providers if you do not want to book additional hostings.
StartSSL is free, and as long as you correctly bundle the intermediate cert (something you have to do with many, many other CA's anyway) your SSL will look no different than a $100+/year one from an A-list provider.
SSL does not come cheap. Certificates have become cheap but you need your own IP, i.e., shared hosting is a problem and hosting becomes more expensive. Certificate sellers, hosters etc. on the other hand are certainly happy about these new business opportunities – although we all know that SSL is inherently broken.
OK, probably still better than nothing! :)
Not anymore, unless you need to support antiquities like IE7 on Windows XP or some ancient Java-based software. SNI works just fine in other cases.
SSL is still more expensive, though. For most small content websites (< 500-1000 visitors a day), a shared hosting is sufficient with costs of maybe around 100 USD/year. For SSL, you usually need a more expensive hosting, you have to buy a certificate (OK, available for less than 10 USD if you don't care about it's quality but need mainly browser support without an ugly warning window) and most hosters allow SSL only for one domain in a hosting.
Example:
Shared hosting with 4 WordPress blogs, SSL is active but only to access the control panel since the hoster allows SSL only for one domain. Costs incl. a cheap SSL certificate: 110 USD/year.
All 4 WordPress blogs with SSL, i.e., 4 shared hostings plus 4 cheap SSL certificates: 440 USD/year.
(And caching with a Wordpress plugin is probably no longer possible …)
https://www.startssl.com/?app=1
You also don't need "expensive" hosting, it just needs to support SSL which is free from a technical perspective. You no longer need a dedicated IP either.
A cert with a larger key is better than one with a smaller key, but other than that, what's the "quality" of a SSL certificate?
Galopping gargoyles, where do you host that shared costs you $100? A small VPS costs half.
$29.88/year.
"Base certificate costs $165.00 for three domains"
"After the third domain, each additional domain costs just $45.00"
The multidomain cert supports up to 100 domains, but the cost is $29.88/year for the first 3 included, plus an additional $12.88/year for each additional domain.
Under this price structure, you could have 100 domains covered with one certificate, but it would cost you $1,279.24 per year for that single certificate.
Nobody said otherwise.
3 domains at $30/year is $10/year/domain which is no different than buying individual certs.
The problem was that shared hosting plans didn't support multiple certs, forcing people with a few sites to purchase a plan for each. The multidomain cert solves this problem.
SNI works fine, but when it doesn't it fails horribly. Apache defaults to the first vhost on an IP which can result in non-SNI clients being redirected to the wrong site.
As for XP/IE7 usage, I have a client in an aerospace related industry with most of their customers still on XP/IE7.
http://en.wikipedia.org/wiki/Server_Name_Indication#Browsers...
It is documented, and all you have to do is install additional packages to enable it, but still, that's not automatic.
Together, they are a quite neat combo and we wouldn't have to pay for certificates anymore.
Lot of critical information is still transmitted through emails.
But I got one very valid concern. Most websites running some kind of affiliate links and banners. Most of the affiliate links and banners is not on the https platform. This will cause mixed content error message by the browser. First, is using protocol relative urls solve this mixed content error issue? Second, can the non-https affiliate links and banners work correctly(tracking etc) on https website?
I am sure this is the one big hurdle need to be addressed or else more than 50% of the websites in existence will have difficulty to migrate.
Quick question. Is the type of certificate also a signal? i.e. self-signed vs plain vs EV?
Once again, self-signed SSL raises the cost of an attack from "basically free" passive monitoring to a much more expensive[1] MitM attack. It's a travesty that apache doesn't simply auto-create a self-signed certificate if it doesn't have one so plain HTTP can be retired forever.
Note: this is about transport security, and the UI presented should not suggest any kind of authentication has been achieved. In firefox, this means not showing the "locked padlock" and other changes usually associated with SSL.
So please, stop undermining the security of the web. We could have been all-HTTPS a long time ago if this nonsense wasn't brought up each time.
[1] and hard to use against everybody simultaneously
Some webmasters say they have "just a content site", like a blog, and that doesn't need to be secured. That misses out two immediate benefits you get as a site owner:
1. Data integrity: only by serving securely can you guarantee that someone is not altering how your content is received by your users. How many times have you accessed a site on an open network or from a hotel and got unexpected ads? This is a very visible manifestation of the issue, but it can be much more subtle.
2. Authentication: How can users trust that the site is really the one it says it is? Imagine you're a content site that gives financial or medical advice. If I operated such a site, I'd really want to tell my readers that the advice they're reading is genuinely mine and not someone else pretending to be me.
On top of these, your users get obvious (and not-so-obvious) benefits. Myself and fellow Googler and HNer Ilya Grigorik did a talk at Google I/O a few weeks ago that talks about these and a lot more in great detail:
https://www.youtube.com/watch?v=cBhZ6S0PFCY