>You can emulate SSH's "remember this servers ket fingerprint and only tell me if it has changed" in most browsers by adding a permanent exception, so it'll only moan again if the self-signed certificate changes. Firefox does this.

Doing this en-masse would be a much better system than we have right now. Example: Have a random internet user visit a site and note down the details of the certificate they get (automatically). Repeat a few thousand times. Compare notes. Wait a sec, why do I have a different certificate than 99% of the other visitors? Hmm. Throw alerts.

The chances of the average user being the target of a MITM is utterly minuscule, so this system ensures that you as the bad guy either have to own the service provider directly by installing a certificate you have keys for, or every single user that hits the site simultaneously to prevent the others from being alerted.

Pinning on steroids, basically. No CA's required.

>but having a self-signed cert proves nothing at all.

..other than the connection being encrypted, the CN on the cert matching the domain name, and it not being expired. This is the same data that the lowest level certificates from every CA provides.

I believe that the past decade or so has shown that CAs do not deserve the level of trust they're implicitly given. I certainly don't trust them. We know they can be coerced by the bad guys with guns to generate certs anyways. QED, they are not trustworthy.

>Renewals exist because certificates expire. Certificates expire because an infinitely valid certificate is potentially dangerous because the revokation process can not be relied upon in many cases.

Then re-generate the bloody certificate and don't charge me money for the privilege of giving me exactly what I had before with a different date on it!

>f your e-commerce site finds $7/year or the hassle of using StartSSL's interface for free (or $120/y or $70/y respectively for EV certs) a problem, then it isn't much of a profit making e-commerce site...

Ah yes, the old "It's not that expensive, so why are you complaining?" canard. A dime here, a nickel there. It's nothing.

Why just a little of a bad thing remains bad is left as an exercise to the reader.

>Automated processes that rely on infrastructure that someone needs to create, monitor, and maintain. If you so strongly believe that this is a complete and utter rip-off and that you could do it so much cheaper, why not do so? If you can do it as well while charging less (or nothing) then people will flock to your service. One man's margin is another's opportunity.

Why are there no serious community CAs? Why is every single one of them a large corporation? Larger infrastructure projects exist that are community, free/donationware efforts, after all. Is it really that hard, or is there some other reason?

I'll wager that one of the reasons is that entrenched players (the VeriSigns and Comodos and Thawtes of the world) get to set the standard for the market. For audits (e.g. Webtrust) that cost tens-to-hundreds of thousands of dollars to complete.

De-facto regulatory capture, except the regulations are more of a consensus than top-down legislating.

>The scary warnings are not misleading in the worse cases. If a DNS hijack passes your bank's traffic through a server that has a self-signed certificate would you want your browser to warn you or just carry on because self-signed certificates are fine usually?

I have no way to prove this, but I would be willing to bet large and ridiculous amounts of money that 99 out of 100 SSL warnings an average computer user sees is going to be the result of either misconfiguration (a badly set CN is common) or expiration. The connection is still encrypted and the certificate was still generated by a "trusted" CA so we know that the identity is valid (what are the chances that the owner of bar.com doesn't know of the existence of foo.bar.com?) - yet we still cry wolf like something is very definitely wrong.

And I say "cry wolf" for a reason. With the majority of SSL warnings being bogus (bogus as in they fail part of some validation test, instead of bogus as in the user was in some actual danger), we're training users to override the annoying warning every time.

And you can't override parts of the validation - it's all or nothing. If I know a certain website has an expired cert, and everything else is still valid, why can't I just override the expiration check? Being N+1 days out of date doesn't reduce the security of anyone concerned. - Instead I have to completely except the cert from all checks and then I won't get warned if say, the issuer changes or the CN doesn't match or some other data point, which when taken together, might add up to a different whole.