The SSL Co-operative: A Member-Controlled Certification Authority
sslcoop.org
sslcoop.org
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.
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.
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.
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...
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.
[0] - https://getssl.me/
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
CA's currently maintain internal keyword warning systems that flag domain validated requests for manual intervention. Anything that even hints that it is involved with a major company, church, charity, bank or financial institution gets flagged and approved manually.
What we "need" more of is EV-style validation, so I can see that the site I'm on is an actual company registered in whichever territory. Otherwise all it indicates is that an email address with the associated domain is linked to the private key for this site. Not really what most people are looking for.
I run a forum I want Wildcard SSL on but I don't want to buy one since I currently spend no more than $30/year to host it. The Wildcard SSL Cert alone would cost double that at some of the cheapest places.
If I can fix my problem and others, count me in.
It's a bit long to be the SSL co-op's tagline, but as a motto, you've pretty much hit the nail exactly on the head.
Honestly, my experiences with CAcert were awful. Pressuring people into signing legal contracts that are just laughably unfair was just one part of it.
They may have been a likable organisation at the begininng (maybe with a penchant for over-the-top policy), but when they realized they wouldn't get into major browsers by default, they tried to get "serious", changing too much too fast and wrecking the whole thing. Without the big result they were hoping for.
"If all the money we spent on ssl certificates..."
And thus was sslcoop.org born! I'm not sure what you mean by "opensource PKI infrastructure", exactly, but as a long time F/OSS hacker, I'm definitely planning on putting everything that's developed for the SSL co-op under an open licence.
But the software's the easy bit. The hard part is the work required to define processes and policies, get everything audited, and then getting through the inclusion process for all the browsers. That's what takes somewhat more organisation (and money) than writing some code and running openssl...
I think the focus should really be in jumpstarting CACert (overhauling its governance model) and building on its existing infrastructure and user/assurer base (As an assurer I'm probably biased here).
Of course this would be hard work and less self fulfilling than doing the F/OSS dance and re-inventing the wheel..
Organisations aren't code, so trying to make analogies to "forking" CAcert isn't something that stands up to scrutiny.
Yes, audits for WebTrust compliance are quite expensive -- $100k is within the range I've been quoted. However, CAcert has never (to my knowledge) even attempted to engage in one of those audits, and my understanding is that CAcert is attempting to create a system whereby they can operate without requiring a WebTrust audit -- so it's hardly reasonable to bring up the cost of an audit that's never been done, and will never be done.
It would be extremely hubristic of me to try and "take over" CAcert with the intention of trying to get it well-trusted by browsers. Either the organisation as it currently stands doesn't want to be in the trust stores (in which case, I'd essentially be destroying the organisation as it currently exists in order to make a new one from its ashes) or the organisation does want it, but the people currently working on the problem haven't worked out how, within the constraints the organisation has willingly placed on itself -- in which case, why do you think I'm that much smarter than the collective wisdom and experience of everyone, past and present, who has been involved with CAcert? Why would I have the silver bullet to work out how to satisfy the inclusion criteria of the browsers, within the boundaries the organisation has chosen to operate within?
My reasons for investigating the SSL co-op model have nothing to do with CAcert's governance -- from the outside, CAcert appears to be quite reasonably governed. They're to do with the feasibility of becoming a widely-trusted (by browsers, etc) root CA, given the current operational model. Given that I think the operational model needs to be completely different, the value of the existing infrastructure and user/assurer base to a root CA with a completely different operational model is, to be blunt, zero.
The SSL co-op will also explicitly not be an "undermanned community based authority". It will be operated on a solid commercial basis (please bear in mind that "commercial" does not equal "for profit"), and its budget will include funds to pay for staff to operate the CA and all the associated bumf. If the co-op cannot be run on a commercial basis, it will not be run, at least with my involvement.
And finally, I don't want CAcert to go away. I feel there is a strong need for more diversity in how CAs are operated, and the SSL co-op is merely the first step in that direction. I'd like to leverage the co-op's success to make it easier for alternatives like CAcert to be a part of the "in crowd" in the future.
- Where do you plan to place the infrastructure of the cooperative?
- What is your expected timeline to issue Browser accepted certificates?
- Are you planning to provide an API for signing CSRs?
I am currently working on a solution for self hosted messaging and file synchronization, and your project would complement our efforts to give people the possibility to self-host securely.
- Probably in Australia, at least at first, since that's where I'm based. I'd like the DR site to be in Europe, if possible, but that might not be a day 1 achievement.
- I'd like to be able to issue certs from day one of the co-op, via a reseller or other arrangement -- that might cost a few dollars per cert, though. It's a minimum of two years from "let's do this!" to being accepted in all the browsers, though (look at the Mozilla inclusion timeline for an idea of best case: https://wiki.mozilla.org/CA:How_to_apply#Timeline)
- An API is definitely intended from day one. My general architecture for these kinds of systems is API for everyone, and the website just talks to the same API that the general public does.
I'd love to talk to you more about how the co-op could help you with your system.
The game-changing of the SSL co-op has already started! New business models are taking shape! (grin)
CAcert's goal is to issue certificates for free, by implementing an alternate identity validation model. The SSL co-op's goal is to issue a subset of certificates for free, by having those who take advantage of that service share in the costs of running the infrastructure required to do so.
CAcert's determination to stick to its guns on doing everything "on the cheap" is admirable, and I'd quite honestly much prefer it if they succeeded (it'd be a lot less work for me, for one thing). However, looking at the browser inclusion landscape as it currently exists, I have doubts that CAcert has much hope of ever being widely accepted in the browsers. Worse, you can only change the rules about inclusion if you're already in the club... it's a nasty chicken-and-egg problem.
Yeah, well, I haven't worked out how to tell nginx to look at the SNI for a HTTPS request and bomb out completely if it doesn't match any SSL-enabled vhost. Unless you've got pervasive IPv6 -- then I can set everything up so manually mangling URLs to use HTTPS doesn't cause problems (there's no links to HTTPS resources on sslcoop.org)...
Turns out the real scarce resource is IPv4 addresses -- but we already knew that. ipv6coop.org, anyone? (grin)
Catch-all + HTTP --> HTTPS
server {
# Set server name & make it the default for this IP address
listen 80 default_server;
listen [::]:80 default_server ipv6only=on;
return 301 https://EXAMPLE.TLD$request_uri;
}
server {
listen 443;
server_name EXAMPLE.TLD;
return 301 http://EXAMPLE.TLD$request_uri;
}
By the time the server can return the redirect you propose, the user agent must have already accepted the non-matching certificate.
Testing a couple third-party sites, our local bus company simply times out when you manually input https://www.libertybus.je. Doing this on the main BBC site https://www.bbc.co.uk/ quickly returns you to the http version. Those are different setups but the cert errors do not happen, which is the goal here.
meowtaxi is sooo right! Seriously, I was going to post the same thing. Sure, I expected an SSL error when I manually switched to the https version of your url, but the specific SSL error I ended up getting reflects really, really poorly on an organization that aims to become a CA.
I did check your FAQ first for some mention of the site's current SSL woes...
A, creating rogue cert by md5 collisions (they have the capacity) B, making people believe that a CA guarantees the identity of the issuer, while having their CA in the approved list so they can sign certs (for example like gmail.com)
There is good documentation about it:
If they did want to sign something publicly, they'd just compromise some third-world CA and have them take the blame. There's plenty of them in there.
Or they could just sign up as a Comodo reseller.
It's fairly well documented if you google around.
And note, while it may seem like a terrible thing, it really isn't. The issue isn't that they're able to do it, the issue is how rigorous they are with their process of deciding to do it.
There is absolutely a valid reason for the government to want to do this.
But that doesn't mean they gain anything from infiltrating a large number of CAs; after all, those only sign certificates, not create the private keys.