The author doesn't explain at all why he thinks that not using StartSSL solves any problem. This indicates a major and common misunderstanding of how certificates and PKI work.
Essentially it doesn't matter which Certificate Authority you use for security reasons - because any CA can attack you, whether you're their customer or not. This can only be mitigated by using key pinning (hpkp), but then - at least if you pin leaf certificates - it still doesn't matter which CA you choose.
Every text that indicates "I don't trust CA X for reason Y, therefore I don't use them" is based on a misunderstanding of how certificates work.
(And yes - I know that there is the issue that you can let StartSSL create the private key for you. Just don't do this ever, no matter which CA you use.)
> Firefox (and Chrome) disable Pin Validation for Pinned Hosts whose validated certificate chain terminates at a user-defined trust anchor (rather than a built-in trust anchor).
I understand this as "when using HPKP, you have to pin a CA certificate, not your site's leaf certificate". If this understanding is correct, I think your comment about HPKP is wrong and it is in fact a good idea to use a CA you find trustworthy and pin its certificate. Agree?
It's my understanding that you can pin to any certificate in your chain, but if a server presents a certificate that leads to a user-defined trust anchor (i.e. your typical corporate MitM proxy cert), no HPKP check is performed.
> "I don't trust CA X for reason Y, therefore I don't use them" is based on a misunderstanding of how certificates work.
I don't think so. If you don't trust a particular CA then you shouldn't in good conscience make trusting them a requirement to access your services. And by using an untrustworthy CA you are making it harder for browsers and distribution maintainers to distrust them if they start abusing that trust.
I have not implemented key-pinning myself, but I always assumed you were pinning the key of the actual site you were communicating with ... sort of like SSH ...
You can pin to any of the public keys in your certificate chain, so that's the root cert, intermediate certs, or your own cert.
Most deployments currently pin to a main and backup CA. This is because HPKP makes it fairly easy to essentially brick your domain (Think: Heartbleed and a lost backup key. Say goodbye to your domain!). It's possible, but you better know what you're doing.
"any of the public keys in your certificate chain" includes your own certificate, so yes, that's possible.
However, if your main and backup key is lost or compromised, you have essentially bricked your domain. That's why most real-life deployments pin to two CAs instead (since CAs are generally better at managing keys).
If you use StartSSL, and then down the line they go well and truly rogue, browser vendors will have to consider ceasing to trust StartSSL in future releases. If your site is popular, it will be one more reason for them not to do that, which would leave their users less safe. If they do decide to untrust StartSSL, this will break your site.
Well, you could pin your CA's certificate so at the very least your repeat users won't be at risk but fundamentally you're right and it is a common misconception.
Every CA in your trust store can issue certificates for every domain. "Attack", in this context, means issuing a trusted certificate that can be used to MitM users of your site. HPKP helps mitigate this risk on a Trust on First Use (TOFU) basis.
As long as the certificate is ultimately signed by a root CA in your computer's trust store, the certificate will be regarded as valid by your computer. So basically, any CA in your trust store or signed by a CA in your trust store can issue the certificates for anyone, anything and any domain. It doesn't matter if the owner of domain consents or not.
It's proven in the past that they're not a security company for anything that deals with protecting yourself against snooping by the Chinese state and will negatively affect your security.
Seeing this in relation to free SSL intended to be deployed all over the internet. Yeah, that is worrying.
Looks like we can't win, since most companies are being snooped by someone. There's hardly a service I use that's not within the NSA's reach, for example, and China is probably less dangerous to me than the US.
For Chinese people working in IT industry, Qihoo is an awful company for the reasons mentioned above, but also for allegedly assisting government Internet censorship.
This is pretty anecdotal and I doubt there will be a list of names written down somewhere. However have a look at the number of acknowledgements in Microsoft's security bulletins from last year:
Palo Alto Networks - 34
Qihoo/360 - 27
FireEye - 14
Tencent - 14
Trend Micro - 12
Fortinet - 7
McAfee - 2
VMware - 2
Kaspersky - 1
They are a pretty unsavory company but they really know what they are doing.
The problem is that, more often than not when something related to Qihoo gets posted on HN the replies were invariably about how evil Qihoo is as a company. The discussion quickly becomes derailed and meaningless as the choir busily preach its own members.
I've worked with a company that at least 30% of our user base uses Qihoo brower. They blocked few of our domains and now, someone from Qihoo asked us to pay so that they will unblock our domains.
Example, try search proprietary software, say 'Autocad', first few results are always pirate sites, while google will show the Autodesk site and the wikipedia post.
Recently Baidu also under the spotlight for monetizing illness-related forums[1]. The issue is some patients accused the Internet giant selling their private info to _unqualified_ private hospitals. These hospitals charge a lot but usually their hardware and staff are underqualified.
I imagine google is showing a global popularity vs popularity in China. A good search engine shows first the results that most people are really looking for...
What happens if that was your software? Will you think it is good? Hope whatever you have for a living is NOT up there for free due to 'popular demand'.
Unless this[0] is the Autocad office in China (which I highly doubt), there's absolutely no link to the Autodesk website on the first result page.
In fact, their instant answer when you search for Autocad is downloadable version of Autocad for Win/Mac/iOS. I don't have a Win/Mac computer with me at the moment, so I can't verify are those legit trial versions or pirated ones, but the iOS one points to the legit version on Apple's store.
Qihoo offers CDN and managed DNS services[1]. The choice is odd on StartSSL's part but may not be necessarily insidious.
What more, not using their services does not enhance or harm your security in many meaningful way as long as they remain a trusted CA who can sign any domain they want to. If nation-state espionage is really a concern for you, take a few minutes of your time and purge the list of trust anchors installed on your OS[2].
There's really not much reason to use StartSSL now that Let's Encrypt, AWS Certificate Manager and others offer free certs with vastly better support, tooling and interfaces.
StartSSL has some of the worst support I've ever encountered. Normally bad support means clueless or non-responsive. However StartSSL support is often actively hostile, treating customers as idiots or worse. I should point out that this isn't always the case, and I have used them in the past without trouble, but the times when it is bad are bad enough to write them off. Their site also looks like it was made in 1998, and while using client certificates is secure and everything, it's also seriously user-hostile. I have to remember which computer and browser I used a year ago to sign up? Yeah, I know I should back up client certificates, but seriously who does that?
> while using client certificates is secure and everything, it's also seriously user-hostile. I have to remember which computer and browser I used a year ago to sign up? Yeah, I know I should back up client certificates, but seriously who does that?
So you want a secure website, and you agree that SSL is needed for things to be secure.
But you're not willing to put in one inch of effort yourself to secure your own SSL keys. You can't even bother to back up the master key to your own certs, because it's too much work?
Cognitive dissonance much?
If you care about security, then do it properly. If you're going to do it half-assed, just don't bother at all. All you're doing then is contributing to security-theater, which is all the work and no real benefits.
Client certificate themselves aren't so bad, I use them for my personal sites. But they way startssl used them without accounting for bad browser support is a problem.
If you accidentally visit their page with the wrong browser (Safari or Chrome, I forget) when you need to renew an expiring client certificate - the browser doesn't download it properly, you can't ever request another one. Anyway, letsencrypt sorts that out.
I should add that of course I back up private keys, but in 20 years of using the web, I've not encountered a single other site that uses client certificates for authentication. I know it's more common in enterprise situations. I'm supposed to have a workflow to backup my browser client certificates just for one site? It's not their fault that browsers mostly have poor UI for handling client certs, but it is their fault for requiring them. Let's not even get started on what happens when you get chain problems, or if the client cert expires, or any of the myriad other ways it can go wrong. Just use 2FA like every other secure site, and I'll store a secure password in LastPass.
> I should add that of course I back up private keys, but in 20 years of using the web, I've not encountered a single other site that uses client certificates for authentication.
I don't know what you have been doing the last 20 years on the web (and I'll assume it's more than just surfing facebook), but it's not entirely uncommon, and I've encountered it several places.
Symantec's CA uses it. My online bank used to do so too. I've seen VPNs using it. Iirc some IPv6 tunnel-providers also require you to authenticate using certificates before letting you set up new IPv6 subnets.
It may not be mainstream, but it's part of the standard. And it's much more secure than a regular username/password, for the same reason SSH keys are more secure than allowing username/password logins.
The fact I'm on Hacker News should probably give you an idea. I know it's relatively common on corporate intranets, but I don't use those. I can assure you that I've used lots of CAs, banking sites, VPN providers, registrars, hosting providers (and plenty of others) and made no specific effort to avoid them, and StartSSL is (almost) the only one I've found. I've remembered that the UK Government Gateway used to use them about 10 years ago, but they were optional. My point was that you referred to all other security as "half-assed" (and implied I was too), which would make almost all other sites half-assed. Now there are a lot of sites with half-assed security, but I'm not sure you could call all of these half-assed: https://twofactorauth.org/http://www.dongleauth.info/
> My point was that you referred to all other security as "half-assed" (and implied I was too), which would make almost all other sites half-assed.
To be clear about that: My point about half-assed was your seeming unwillingness to back up client-certificates which gives full access to your real certificates and (in some cases) private certificate keys.
Unless on Windows (where StartSSL has its private keys marked non-exportable in the certificate store, sic), doing such a backup takes almost no effort. There's no excuse for going all the way through to get a cert and then not bothering backing up these client-certs too.
Even if it's easy (and it may be now - I haven't done it for a while), it's still a whole extra backup workflow, which I have to work out how to do for all different browsers, and if I'm on another machine work out how to import, and work out if it's possible on mobile, and oh look, my personal certificate has expired so I can't login to renew it so I need to create a new account to get a new certificate and email them to get the accounts merged...all for one site. Or
Good for you, I guess. I've yet to have letsencrypt work a single one of my websites and I'll stick to StartSSL until it there's something better around.
If a CA is not at least allowing client certs (so that you can e.g. use a smartcard with a key for auth rather than a password) then yes they're doing it half-assed.
(Browser makers are quarter-assing their UX for using client certs, but that's a separate issue).
I had a terrible experience with their support too. I'll never use them again.
The guy kept throwing out extremely passive-aggressive lines while using smilies while I was nothing but polite.
Things like:
- "I understand your problem, maybe you should be more careful next time. ;)"
- "Next time read the fine print! :)"
This was all because I needed to get a certificate revoked. Due to their terrible and unclear interface I had managed to lose a private key that they generated for me and as you know, revoking certificates with StartSSL costs money.
The hilarious thing is the revoke fee is way more expensive than just buying a certificate with a different provider.
Thankfully I'll never have to deal with them again in my life because superior services exist to obtain/revoke free basic certificates.
I've had good experiences lately, when they relaunched their website the option to create your own certificate for S/MIME had disappeared (on Mac - apparently it was still there when using Windows). I opened a ticket and the next day it was fixed. Now you can even upload your own CSR for S/MIME certificates which allows for 4096bit S/MIME keys. Previously they only had the in-browser key creation. Nice.
I agree that their style in responding to questions is really bad (one liners etc). Yet I'm having the experience that they responded quickly and with helpful information if you had a question.
I'm now just curious what happens to my data if they're sold to China.
I mean, the amount of personal data they are asking for when acquiring a certificate is not really small.
When I can use Let's Encrypt to get a certificate in production without running anything on my production web server, I'll consider it. Right now, StartSSL validates my domain via email and I only have to touch it once a year, not once every 3 months like Let's Encrypt.
I'm afraid you'll have to go through renewal every 3 months, but I'll still make a shameless plug of my client [1]. It uses DNS validation exclusively so you can generate certificates wherever you want.
In addition, domain authorizations last for 10 months, so you don't have to go through the DNS verification each time: just renewing is sufficient. Run the issue command, drop new certs into configuration management, done. Couple minutes tops. Just set your calendar!
>Automating this simply means that if someone hacks your machine, they also have full access to generate any certs they like.
Well, they can generate certs for your domain. But what exactly is the big difference between generating a new certificate for your domain and having your private key. I fail to see why it would be a huge risk, they can access all your users data in any case.
Hasn't this always been true for domain validated certificates? If you control the domain's content, you can get a cert. I don't see how LE makes that any worse.
Well, they can generate new certificates for as long as they have access to your machine. Take that access away, and they can't generate certificates anymore.
All in, the Lets Encrypt way brings you more security. Since the certificate validity is shorter, even generating an extra certificate will give the attacker a smaller average time with a valid cert than stealing your StartSSL cert.
It's like not-perfect-but-still-good forward secrecy: Your old certificate may be leaked or decrypted, but it will only endanger past communications; the communications after this one will still be secure.
Another side-effect is that you don't need to manage revocation stuff as diligently, because certificates automatically expire shortly. The window during which a certificate is valid is extremely short and recent, which means there is less chance that a problem happens. when that probability increases (as a result of being older), certificates become automatically invalid.
I use Let's Encrypt DNS validation. This does not require you to run anything on your server. You just need to have a way to distribute cert to your servers.
can you explain this ? I'm trying to bake letsencrypt certificates in my docker images and I am trying to figure out a way around the race condition (nginx needs a certificate to run <-> certificate needs nginx to run).
How about storing the letsencrypt certificates in a data-container/locally on the host and mapping those files to the nginx container when you start it?
For the very first time, you can use let's encrypt's manual verification process, but then have the let's encrypt client set up to renew certs automatically (possibly even from a separate container) using same data file mappings.
cannot run a docker inside a docker. the problem is not running a webserver, the problem is the race condition which needs to be solved when docker starts up.
As a totally-naive-to-your-problem-particulars and totally-hacky suggestion, why not start nginx with a starter cert, then mv the new cert into position and reload nginx?
Have an instance with plain-text http running only the Lets Encrypt challenge. Make an explicit rule for it on your load balancer, and deploy it first.
Just today, I'm setting up my first https by myself.
Started with Let's Encrypt. Running Mac OS X. Failed. Guessed cause has something to do with macports vs homebrew and having the proper Python version active. Disabled macports. Now the app runs.
But I got "Failed to connect to host for DVSNI challenge".
Start googling, reading, messing around with this for a while. No joy.
Bailed on Let's Encrypt, started over with StartSSL, because its the first source of free for not-for-profit certs I found.
My recommendation is to look beyond the free alternatives and consider how inexpensive paid certificates have become. These can be issued for lengths up to three full years and cost well under $10USD/year. Multi-year discounts bring three year certificates price to under $20USD.
Think about how much time it is going to take you to learn how to deploy and maintain your 'free' certificates and remember time is money. What do you make an hour? Is that more than the cost of a paid certificate?
Don't waste hours chasing down free certificates when paid ones are so cheap now. Use Let's Encrypt only if you need lots of certificates and the paid options become prohibitively high.
I use acme-tiny and confirm it is good. But there is still significant work to do to get a working certificate and the documentation is lacking significant details. I have my own recipe documentation that I should publish. Apart from this, this is the only script out there that did cut it for me.
Note that the update process needs to be automated because let's encrypt certificates last only 3 months as I have read.
Lack of support for wildcard certificates is still an issue for Let's Encrypt. Rate limiting and SNI are two issues that means a wildcard certificate is still highly desirable.
That's wrong. You can get more than 5 certs/domain: either you have to wait a week (it's 5 certs/domain/week), or you include multiple hostnames in a single certificate (up to 100 IIRC). The latter would allow 500 subdomains/week.
You'd probably have to bring your own SSL stack, which is not something you'd want to do for several reasons (staying on top of code patches, maintaining a CA root store, integrating any custom CA roots the user has added, handling any custom HTTP proxy settings, etc).
Well, if you are some kind of openssl master, acme-tiny is flawless.
In practice, for most people, reserve a few hours for your first deployment. After you got a script that calls openssl right, it's fast to adapt for other domains, but the first time is hard.
I use https://github.com/lukas2511/letsencrypt.sh and it handles all the openssl stuff for you, I've found it to be really nice and light-weight. You just give it a directory to put the ACME challenge files in and a list of your domains
Except for third-party services you need to provide your own SSL certificates for. AFAIK there's no way to automate renewing the certificate you use for GitHost (with a custom domain), for example.
The author doesn't say why this is worrisome. He just says he's worried "that the PKI front-end (auth.startssl.com) is now hosted within a Chinese Antivirus Company, who uses a Chinese ISP for 2 months and that there hasn't been any news around".
The article could certainly use a bit more connecting-the-dots to show how he gets from "they're hosted in China" to "I won't use them anymore".
I think the implication is that the Chinese government exerts a lot of control over the internet there, and are openly monitoring/intercepting internet traffic. As such, they shouldn't be considered a trusted authority for security related purposes.
Your concern is well placed but the linked post really missed the point. Signing authorities in X509 don't have access to private keys and they don't really need domain owner's input to sign a MITM cert.
Most software that uses TLS nowadays ships with a number of CA root certs sponsored by various nation states including China. On desktop they can be disabled but iOS drvices are out of luck (or perpetually compromised in a sense)
It used to be a pretty sweet deal, for $60 you could get unlimited multi-domain multi-wildcard certs. Most other CAs charged more than that for a single wildcard cert, and noone else seems to even offer multiple wildcard domains in a single cert.
Which was quite sensible, actually. Charge for the actual costly process of manually verifying ID, and then allow for unlimited free domain-validations to be issued to the corresponding ID (which is the machine-automatable part).
After searching the web and comparing the different price rates, I just found a lowest wildcard SSL at $42/yr. at https://www.ssl2buy.com. I hope that you would not find cheaper than this wildcard SSL. As they did not charge any extra beyond the price and helped me to secure my number of sub domains. Even the backend technical support was good enough.
I'm not convinced that is any more worrisome than the US situation as long as you don't trust them with your private keys. The US also monitors/intercepts internet traffic, except they do so (pre-Snowden anyway) secretly. They actually do a lot of things China gets accused of -- just think of the CISCO router "upgrade" facility.
Fine, stop using them. You still trust them. Your visitors browsers still trust them. Being paranoid wrt a Chinese CA really makes no sense. They have as much incentive as a western CA to behave wrt keeping their signing keys secure, and their revocation list sensible, which is all that really matters.
There are many things to take into account when choosing a CA to use for your site. But security, jurisdiction and any history of mis-issuance are not relevant to you; only reliers. And no relier has any choice in the matter anyway, or any economic relationship they can terminate.
(Things change if you start to use HPKP and pin to a particular root; nobody does that though because it's an availability and economic nightmare.)
Western CA's and ISPs are just as "state encumbered" as Chinese ones. We just turn a blind eye, for some reason.
It would be so easy for NSA/GCHQ to recruit or place an "agent" inside of any Western CA or ISP they wanted. There is even evidence in recent years that this has been happening.
This was merely the most recent incident. Yes Symantec covered it up quite nicely and framed it as a test that went wrong (the Russian's used that excuse with Chernobyl) but there is no evidence those "rogue employees" were not acting for the state i.e. the USA.
Still think the West CA's and ISPs are better than Chinese ones?
The only question you need to ask yourself is: Which government would you rather have eyes on your data? One might surmise that if you have something to hide from Western eyes then use a Chinese provider. And if you have something to hide from Chinese eyes then use a Western provider. The balance of probabilities, I believe, backs this up.
On a related note, Cloudflare use Baidu servers in China operated by Baidu staff. My understanding is that this means private SSL keys given to Cloudflare live on Baidu owned and operated servers.
They offer "keyless" ssl which puts the private key back in the data center but this adds complexity and latency on the initial connect so I suspect most don't use it.
CloudFlare's network in China does not contain configuration, settings, SSL certificates etc. from non-China CloudFlare customers. We run separate infrastructure there and only if you go through the hoops to expose your web site on our network inside China do we send information about your web site there.
Not that wrong. You're just saying you have to enable China.
Do you make it clear in the UI that a private key is ending up on Baidu's servers operated by Baidu's people? I don't use CF so I don't know - I'm just curious what the user experience is like. I'm asking because your CEO addressed concerns in the CNBC article about Baidu having access to your intellectual property so they seem to have full access.
I think the issue of user education is a real problem. I'm Wordfence's CEO - we're the biggest security vendor in the WordPress space. (We occasionally work with your support staff to solve a customer issue) and I know that user education in infosec isn't what it should be. We're actively working to try and fix that with a vendor neutral learning center we created.
So for example I'm not sure users understand the impact of having a partially secure connection to the endpoint when you only have SSL to a Cloudflare edge server and are reverse proxying in the clear. Same issue here - I'd like to learn more about the UX and how the location of their private keys is explained to them.
I think as vendors we're often to blame because the marketing team gets a little too excited at the cost of user education and clarity.
I'm the person designing this UX and yes, we plan to make quite clear/explicit the option of putting your private key in China. By default, keys will remain outside the country.
Re your comments on user education: if you'd like to learn more about our current UI, I encourage you to sign up for a free account at https://www.cloudflare.com/a/sign-up.
And if you encounter any experiences you feel are not sufficiently clear, I hope that you'll submit specific suggestions to me here: pat@cloudflare.com.
[quote]For the moment the China network does not support HTTPS traffic (HTTP only). Support for SSL/TLS will be made available in the coming months.[/quote]
As long as you don't sign in to China servers, they won't put you there. Even if you want to, first you need valid ICP certificate issued by Chinese govt.
Baidu is like Google but in China. They must already have a certificate in any browser's trust store. And also, think about all the keys contained in AWS servers, and AWS is in America...
Using a local CA seems like a bad way for a government to compromise HTTPS. If they got caught, that CA would get demolished practically overnight when the browser makers remove it from the trust stores. Compromising a foreign CA seems like a much better strategy. (Although not nearly as simple)
"StartSSL already refused to revoke certificates affected by the HeartBleed vulnerability and accused the user from negligence."
That's wrong. They did charge a $25 fee for the revocation, however. I think it's reasonable since there is probably some manual process involved and the certificate was already free. They have to earn money somehow.
Exactly, they've automated the issuance of free certs and revoking takes extra work. $25 sounds high (sub-$10/year certs with unlimited free revocation & re-issuance are easy to find) so it is a money maker for them but so what?
People think nothing of using the freemium model which gives you a basic product for free, and charges you for extra features. It's exactly what StartSSL are doing here.
I don't particularly like or use StartSSL, but much of the criticism of them sounds totally invalid to me. Paid DV certs are dirt cheap people, shop around!
Except that it causes that a startSSL certificate had a higher chance of being unrevoked if compromised. Therefore, I remove them from the truststore on my computers.
Reading this I'm more worried about the personal data StartSSL has about me. I never felt good giving away so much personal data to CAs when acquiring certificates to identify myself. Do we know how StartSSL handles this? Do the Chinese now have a copy of my passport, electricity bill et cetera? (well, I've been to China already, so the state already got my passport, but not necessarily a "private" company).
If the Chinese don't have it, the Mossad does. The fear is real. Maybe StartSSL was only a Mossad front to collect valid/real identities from around the world to use on covert ops.
I personally have a serious problem dealing with the state of china's telecommunications. It's about as close to evil as you can get. I'm not saying other state actors are much better but, I'm just saying ...
I had a bad experience with StartSSL using their free SSL cert. Basically they just treat you like a thief or scumbag trying to take advantage of their freebie. Eventually I found a company selling $10/year cert which I am happily paying. Now this adds another excuse for me to avoid StartSSL even more.
It's true, but they aren't usually portrayed as being smart, just crazy/ugly/stupid. Whereas Chinese and Russians are portrayed as being extremely smart and cold hearted.
You are borrowing someone else's trust. You are hoping that the company you get a cert from won't pretend to be you. There is no technical mechanism to stop this, no matter where the parent company is based.
Also the other thing to note is that virtually all communications companies have some sort of government involvement regardless of where they are based.
Now I'm gonna give you a few reasons not to use let's encrypt: it forces you to keep a piece of software that can generate keys in your server. It forces you to reload your web server config every two months, unattended (they won't issue certs valid for more than 90 days). The alernative would be to do the process manually every two months(wtf?). Also, its certificates are not trusted in Windows XP.
Now, as part of these piss-poor authoritarian decisions and attitude, someone is trying to trick startssl users into using let's encrypt posting this crap with circumstantial evidence about China and Startssl. I hope you fail miserably.
No, I have no ties to Startssl whatsoever. And it's been ages since I last used their service.
It does not force you to use any particular software. You can even write your own client.
Shorter validity time makes your users safer. If you lose the private key, it will only be a problem for three monts or less. Reloading your webserver should be a complete non-issue.
Because everyone should love to waste their time writing their own client. And running let'sencrypt scripts as root. And risking their security. And/or renewing certificates every now and then instead of focusing on stuff that matters. And anyone who disagreees should be downvoted to oblivion. YEAH!
I'm quite happy with simp_le[1] which doesn't require root. Renewals can happen automatically. All you need to do is monitor your certificates as you would anyway.
You don't have to run anything as root if you don't want to. There are tons of clients out there without that requirement. Your argument is basically that Let's Encrypt should have put more focus on working like other CAs do, while they decided to focus on better security and automation. Luckily, there are plenty of other CAs out there, and it's quite likely that more of them will start offering free DV certs soon, so it's not like Let's Encrypt is forcing you to do anything you don't want to.
I don't think anyone will be offering free DV certs while let's encrypt is still so dysfunctional and unusable in a real life situation. There was the potential for that, sure, but they've screwed up.
Two CAs already do this (StartSSL, WoSign). FWIW, there's a blog post by CertSimple[1] kind of confirming this is coming (no sources or specifics, though).
tobltobs: If you say I'm lying you should point out the falsehoods, or you're just another manipulator at work. At least pfg isn't arguing whether I'm telling the truth, he just has a different opinion.
> it forces you to keep a piece of software that can generate keys in your server.
wrong, there are different ways to get a cert, even web interfaces, which you can install everywhere.
> It forces you to reload your web server config every two months, unattended
wrong, if you like that kind of work you can replace it by hand.
> Because everyone should love to waste their time writing their own client.
wrong, because again you are not forced to, you could use one of the many clients available.
> And running let'sencrypt scripts as root. And risking their security.
You don't have to run at root, you could use a client which supports non root.
> If you say I'm lying you should point out the falsehoods, or you're just another manipulator at work.
Wrong again, because your errors have been pointed out already by others. You should start reading the answers and stop your "rage against censorship" quest.
Not wrong. You're forced to do all that if you don't want to spend inordinate amounts of money/time on maintaining the server. There are so many cheap certificates available -which are much simpler to use- that it's not worth the hassle, not by a long shot.
Essentially it doesn't matter which Certificate Authority you use for security reasons - because any CA can attack you, whether you're their customer or not. This can only be mitigated by using key pinning (hpkp), but then - at least if you pin leaf certificates - it still doesn't matter which CA you choose.
Every text that indicates "I don't trust CA X for reason Y, therefore I don't use them" is based on a misunderstanding of how certificates work.
(And yes - I know that there is the issue that you can let StartSSL create the private key for you. Just don't do this ever, no matter which CA you use.)