You do pay a $60 fee for identity validation, which is valid for 2 years. You can also have automated validation, but they don't allow wildcard certificates (which I sort-of understand, they do need to make money some way right)
So you get unlimited free non-wildcard certificates or unlimited wildcard certificates for $30/year. Not a bad deal.
Do note the "no commercial use" clause on the free certificates. Not an issue for any of my uses but it may affect quite a few people. Though I'm not sure how they would enforce this.
Of course if you can't afford $60 for two years for the next grade up, then your commercial venture is probably not a roaring success!
Revoke the certificate.
(other than regular whois lookups assuming that data is correct (probably too much hassle), checking the sites secured by the certificates (even more hassle), or someone "dobbing you in")
I'd imagine the file gets large after a while, but we've had ways to ease distribution of large files for quite some time..
Nevermind the fact that CRLs are of dubious value, anyways. See: http://people.csail.mit.edu/rivest/pubs/Riv98b.pdf
Also, make wildcard certificates for domains available for the same low price, because it shouldn't take any more work should it. If I control example.org, then I think it's obvious that I control www.example.org and slighly-biased.example.org.
But then you have the issue of, if Org A controls com.au, that doesn't mean they control mywebsite.com.au. I don't know how you would automate that issue.
The non-automated stuff, make people pay for it. Seriously.
You do have a good point though. I'm sure there are some services right now that allow decent control of a chosen subdomain's dns, but don't mean for you to be able to create ssl certs valid for all other subdomains too. Perhaps there should be a blacklist of sites like "blogspot". Perhaps there should be a way for a domain to indicate that wildcard certs cannot be automatically created for it without passing other conditions.
The solution is called a public suffix list - more information about it is available at https://wiki.mozilla.org/Public_Suffix_List .
That's essentially the model I'm looking to implement. I prefer DNS modification for domain validation, but anything that can be automated will be.
There are not any significant costs to obtaining SSL certificates, so a new CA is hardly likely to change the SSL landscape at all.
StartCom's $60 wildcard is the cheapest I've ever seen. I'm impressed with StartCom's model overall, and it was a great inspiration to me with the SSL co-op. I feel like the more diversity in approaches there is, the better off the CA ecosystem will be. If nothing else, another voice for sanity in the relevant standards bodies (CA/Browser Forum, for instance) can only be of value.
It is $60 for as many as you need, for multi-name certificates too, as long as (presumably, I'd need to recheck the smallprint to remind myself) they are all for you and you aren't signing certificates for others. The fact that they are signed for two years instead of one is handy too.
I've recently signed up for that to get some wildcard+multiname certs mainly for convenience (not having to sign a new cert for every tld/sub-domain combination), and not have s wildcard cert for my vanity domain and one for all the names associated with a project that I'm trying to work on (.domain.net, .domain.com, .domain.co.uk, .domain.uk all in one certificate). Remember before considering this though: there is some extra security in having separate certificates for everything instead of a huge wildcard-for-all arrangement. If you PK for a combined wildcard certificate leaks from any one location any security problems that causes affects every location you have that one certificate in use, so I am trading off a convenience gain against taking a little extra risk.
Well, it'll slightly increase the attack surface against the CA model, so there's the (probably very small) chance that something will go wrong and it will introduce a massive (temporary) hole in TLS, since CA-based trust has a "weakest-link" failure model.
Which is logical. Running a CA and getting the root certificate into the right places is not cheap. Unless someone with money (e.g. Google, as they do with their CDN) decides to provide this service for free some money needs to be earned.
All of Google's free services (CDN, DNS, Chrome, etc) are centred around improving the experience of using the web, so more people use it for longer (and, hopefully, do more searches with Google and/or visit more webpages with AdSense ads on them). I'm not sure how more SSL-secured traffic feeds into that, exactly, but if anyone at Google wants to talk sponsorship, I'm all ears...
[0] - https://getssl.me/
this may be OK if you have only issued one cert, but if you've issued a few hundred (which is the main point of StartSSL: pay once and issue many), then you are SOL unless you can afford to plonk down thousands of dollars.
more here: https://www.techdirt.com/articles/20140409/11442426859/shame...
the CEO (Eddy Nigg) is similarly patronising over email too.
(Sarcasm? Moi?)
Also, their free certificates expire every year; domain-validated certificates should only require revalidation if the domain changes hands.
Certificates cost approximately nothing to issue, and most of the CA's infrastructure would not need significant scaling with the issuance of more certificates.
Manual validation of human/organization identities (the type that requires reading identity documents, such as for EV) costs money, and that could have associated fees, but it doesn't need to occur on a per-certificate basis. And automatable validation costs nothing.
In particular, wildcard certificates don't need to cost any more than standard certificates, and no-cost wildcard certificates would change the SSL landscape significantly. Today, any service that uses subdomains incurs significant fees to secure those subdomains.