I'll say the same thing here that I said in a response to the survey: I'd be interested in taking part in a CA co-op that seeks membership/sponsorship to cover its infrastructure costs (including the huge initial cost of becoming an accepted CA), but that does not charge to issue certificates, including wildcard certificates.
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.
StartSSL/Startcom already does not charge for individual (wildcard) certificates, you can request unlimited numbers.
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.
> So you get unlimited free non-wildcard certificates
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!
But how do they detect that enforcement is even necessary?
(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")
Apparently StartSSL does charge you quite a bit to revoke a free certificate. That bit a lot of people when Heartbleed happened. See https://www.startssl.com/?app=37.
That's partly because of how the revocation infrastructure operates. It definitely adds cost, including generating CRL, trimming the CRL as certificates expire (could be 10 years into the future), and running the revocation server itself.
Let's not pretend it's anything more than profit. Adding a fingerprint to the end of a CRL file is a completely automated process which does not place significant strain on infrastructure.
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..
In another thread it was explained that they charge for revocation because their current software doesn't automate it. It sounded like a limitation in their stack and the fee is a workaround.
Pretty much what I was thinking. Here's what I almost sent as a response to the survey:
This is a brilliant idea. I would pay up to $50 a year for the pleasure of being able to get domain validated SSL certs that are trusted by the major browsers. I would assume that the validation would be via emailing webmaster@domain and making them either respond or click a link or something. That could all be automated couldn't it.
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.
Well, one way to automatedly ensure someone controls all the subdomains a wildcard certificate gives would be to ask them to create dns records indicating that. Basically, the CA could say "you want *.example.com, then create a dns txt record at mzzafr2pr.example.com with the following text: F5cbUl7pL2JM7z and click here. We'll get back to you once we see the dns change propagate". If I can create a random subdomain they suggest within a wildcard range, that makes it almost certain I can create every subdomain.
You both have to prove that you own the ability to create dns (with blogspot sorta) and the actual content. The CA provider both lists the record name and value.
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.
StartCom charges $60 for a wildcard certificate that will be accepted by just about every important browser out there. You might even be able to get them cheaper elsewhere.
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.
>There are not any significant costs to obtaining SSL certificates, so a new CA is hardly likely to change the SSL landscape at all.
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.
But this initiative (however good) will also not provide a no-barrier approach. You need to be a member of the coop (with associated fees) to request certificates.
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...
With all the cheap SSL providers[0] today, I don't really have an issue buying the certificates anymore. When they used to cost a small fortune, I was really restrained to buy a certificate for every small web project, but now the situation has improved.
That sounds very much like the service that is already offered by StartSSL.com. You pay for identity validation, but you can then create as many regular and wildcard certificates as you wish. It's a superb service.
it's a superb service, until you want a revocation, then they try to extort $25/revocation out of you (even if you've been a long term paying customer)
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.
Running a revocation service is an annoyingly fiddly job, but all of that needs to be setup and running before you become a CA. Pretty much all of the faffing around is in the need to regularly regenerate (including signing with the CA key) CRLs and OCSP responder certificates. Like the rest of a CA's operation, revoking an individual certificate should be a miniscule incremental cost, modulo the larger CRL size due to the added fingerprint. I was rather surprised that so many people are sucking down CRLs, but clearly they do (http://blog.cloudflare.com/the-hard-costs-of-heartbleed).
I use and like StartCom certificates, but they wouldn't solve this problem. Wildcard certificates should not require identity validation; you should be able to get a domain-validated wildcard certificate for free.
Also, their free certificates expire every year; domain-validated certificates should only require revalidation if the domain changes hands.
There are rules being introduced against issuing certificates for more than about three years (you can still get five years certs at the moment, but not for much longer); this is more to limit the risk of private key compromise than it is to require people to revalidate. I don't find it too onerous to have to install a new cert every year or so (he says, with several certs currently expired).
Still, I'd suggest issuing certificates for the maximum allowed length, unless requested shorter. Scalable revocation is possible; follow best practices for encryption keys by keeping a separate offline copy of a signed revocation request.
Revocation for X509 certs is a very different matter to that of revoking PGP keys. For X509, the CA can revoke the cert unilaterally, or at the request of the subscriber without the need for the subject private key. In fact, I'm not aware of the existence of a subject-side revocation process that doesn't involve the cooperation of the CA.
Do take note that they will reject and/or also refuse renewal if they think the domain whois doesn't exactly identify you, even if you confirm the domain webmaster validation. Lots of hassle if your domains have other entities or business names listed as the whois admin contact.
There's an assumption in this that domain validated certificates can be wholly automated. But, in the same way that spammers seek out open SMTP relays, phishers seek out weak SSL validation systems for use in setting up phishing sites.
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.
Interesting. Perhaps an alternative to the keyword warning system you describe (for SSL certs only) could be to scan the candidate CN for existing SSL certs. If any are found, flag it for manual review, or possibly come up with a proof system whereby the applicant proves he is the holder of the former certificate.
The problem is that phishers register sound alike domains like info-secure-apple.com or atlanta-usbank.com, that were completely clean prior to issuance.
Anything that includes a trademark (like info-secure-apple.com) or "risky" term (like atlanta-usbank.com) typically ends up getting manually verified, even for domain-validated certs. Not saying that plenty of dodgy stuff doesn't slip through the cracks, but it isn't quite a wild-west free-for-all...
Quite old now, but this was actually my point. That there is NOT really a level of validation that is/can be wholly automated and to try and develop a co-op or service with that assumption is bound for trouble.
I'm not developing the co-op based on the assumption that domain validation can be wholly automated -- but it can be automated for the 99+% of domains that don't try to phish people. I'd say the degree of phishing certificate requests made via the co-op will be lower than the "general population", simply because only members can request certificates. That isn't to say that the CA's policies will be any less stringent because of that, but I don't expect to be spending all of my day clicking "reject" on shady CSRs.
Actually, yeah, they should. Info Secure Apple. Make a comment forum about fruit-borne illness. Why should that be denied because there are companies using one of those words?
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 will gladly run a member organization to lower the barrier of entry to end-users and non-businesses. No one should have to sacrifice security because they don't want to fork over that kind of cash.
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.
Unfortunately they are so messed up, it isn't even funny.
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.
It's sad that debian removed them. I think cacert needs more dedicated governance. If all the money we spent on ssl certificates could be pooled together to create non-profit organisation dedicated to public certificates, it would be awesome! And we could probably get opensource PKI infrastructure.
"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...
iirc the WebTrust Audit required for such a system is in the ~$100,000 range. Why abandon existing initiatives to start another undermanned community based authority.
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.
What would make sense to me more than an SSL co-op would actually be a registrar that gives you a free wildcard certificate for every domain you register. You almost always need a certificate for every domain you use, so why not bundle the two? I wonder if doing a crowdsourced bootstrap of such a registrar would work.
I'm not averse to that idea, in principle. Heck, that sounds like a nice complementary business idea -- you run a DNS registrar that offers a free domain-validated wildcard certificate with every domain sold, and get your certs from the co-op. The costs would be minimal -- there's bugger-all required to start a domain name reselling business, and SSL co-op membership is shaping up to be more on the "consumer" end, rather than "retailer" cost structure, so there wouldn't be significant costs there, either. I don't think it would need crowdsourced funding to get started, honestly.
The game-changing of the SSL co-op has already started! New business models are taking shape! (grin)
I'm mainly favor in this because I could trust the cooperative more than I trust the existing CAs. As long as it doesn't cost me more than the existing cheapest options [e.g. StartSSL, NameCheap's cheap ssl certs] and had 99.7%+ coverage, I'm 100% sure I'd pay for it.. :)
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)
Possibly a stupid question, but why not make whichever vhost is correctly configured for SSL your default? Any traffic will go there unless another match is found. This is what I do to force SSL and redirect anything not matching another vhost.
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;
}
Or, rewrite HTTPS to HTTP for that vhost only
server {
listen 443;
server_name EXAMPLE.TLD;
return 301 http://EXAMPLE.TLD$request_uri;
}
Mozilla's server-side TLS wiki at https://wiki.mozilla.org/Security/Server_Side_TLS is the best documentation I've found yet, and includes great examples of complete configs for various servers. Hope that helps.
That's not helpful, he doesn't have a cert for www.sslscoop.org, so the link is http; but if you try https://www.sslscoop.org/ you get a cert error, because the IP(s) are running https, but for a different name.
By the time the server can return the redirect you propose, the user agent must have already accepted the non-matching certificate.
Hmm, good to know then. Is there a working Nginx config you can point me to for this use case, because I'd like to solve this issue too. My setup happens to be one HTTPS only server and one HTTP only, but it would be good to know in case I want to mix things up.
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.
Womble, I like your idea and I wish you success. But, it is now constructive feedback time. :)
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...
I'm a little surprised that so many people deliberately mangle URLs to see if there's anything listening on :443, myself. I might just pull SSL off the other domain on IPv4, and put it on a separate IPv6 address...
I think the question you should ask yourself is: how is the NSA involved in the currently established CA system? The answer (to your question) is , the very same way. Besides, who does think that having an alternative CA provider is going to change anything? The crypto empowering security nowadays is un-trusted, implementations proven containing backdoors, and on the top of that all the implementations are written in languages that can't be formally verified and there are serious security bugs every other week. Back to the topic, what is this new CA group addressing? Which part of this chain that going to be fixed by any mean with this initiative? I guess the answer is none. :)
The NSA almost certainly has a way to sign their own certificates that they use for MITM attacks.
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.
Well, the joke was about how useless is to start a new CA. The first member is going to be the government through a cover agency. Remember, making you believe that SSL makes your service secure is cheaper and better from the NSA point of view than having a huge cluster to crack the encrypted traffic.
The CA's are legally compelled to issue 'global certificates' that always return as valid so they can do MITM attacks at will.
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.
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)
Except if the NSA did sign Gmail in any non-trivial capacity, it'd certainly be noticed and the offending CA would be removed or put out of business or something like that. Plus it'd draw lots of attention to the NSA directly.
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.
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.