agreed - you can argue statistics in many ways - even if the real number was only half of that value - it’s still impressive though, and since there are a significant number of people implementing automation - and it’s difficult to argue that having a short timescale doesn’t help force automation ( because doing it manually on a frequent basis is a pain in the ***** ).
Is automation perfected yet, certainly not, it’s still beta though. In my view, if you allowed certificates for a year or two, then there would be no driver / pressure for automation.
Again, this is a long-term project. Browsers vendors are moving in a direction where sites served via HTTP don’t have access to new browser APIs. Future versions of Firefox will show warnings on pages containing password fields if they’re served via HTTP. Eventually, any site served via HTTP will probably get a big warning. That’s when vendors will be forced to think about SSL, and then they’ll have the option of paying a lot of money to integrate with commercial CAs and their proprietary APIs, or go for the free option that already has clients in basically any popular programming language. They’ll be forced to solve this problem for their products, or become irrelevant.
I’m sorry, but that’s literally what’s been posted in the first post of this thread (which, itself, is just a follow-up thread to another long discussion on the matter). It contains a list of pro- and cons, which basically includes everything you mentioned. There’s even been a blog post on the topic. I’m not sure what more you could be expecting, other than a policy change.
It doesn’t even list all the cons that were posted in the previous thread (and this one) - including some of the more pertinent ones like HPKP and DANE
Offers no way to address actually address them to minimize the impact of the short certificate lifetime.
It also doesn’t seem to effectively weigh the very small cost of allowing longer certificate lifetimes as compared to the huge cost of creating automation for every device on earth (some of which may still not be possible). The cost to LE of allowing longer certificate lifetimes is so infinitesimally small compared to the enormous effort of forcing everyone to automate everything from day one. If the automation is useful, it will be adopted on its own merits over time, not by forcing it down everyone’s throats. Automation should be a means unto an end, not the end itself.
Shared hosting is a prime example of where you may never be able to automate (save for scraping webpages - which would make the automation itself more fragile than manual renewals), and has one of the biggest benefits to using TLS, yet seems to be ignored for “well just move to another host”. I think some people don’t understand the profit motivation of many web hosters, where things like selling SSL certs is how they actually make money, as margins are so thin in the hosting business they make almost no money from selling hosting itself. You think the (budget) hosting companies are going to make it easy to give up their high margin add-ons to allow LE to automate provisioning? And this is exactly the segment that is attracted to LE (for free certs) - cheap hosting = not willing to pay for certs. But these are people we probably most want to have TLS certificates. So why not try and make it as easy as possible for them, instead of putting up artificial roadblocks…
There’s a large list of shared hosting providers that seem to disagree with you. Even one of the biggest hosters out there, OVH, is a sponsor of Let’s Encrypt (and they have plans to automate issuance for their clients).
You also chose to ignore my point about HTTPS becoming de-facto mandatory in the long-term, which will force vendors to offer SSL as part of all plans. I’m quite aware that reselling certificates is one way for certain providers to make most of their money, but that doesn’t mean the market won’t make them completely irrelevant if they don’t stay competitive on this matter.
This is about prioritizing things, and Let’s Encrypt chose to prioritize security and automation over convenience in certain use-cases. This might not align with your needs, but it doesn’t mean there aren’t valid reasons for doing so.
Thanks for the honest feedback. You’re right that I haven’t been responding in this thread as often as I should, given how important this issue is to so many people. I have been reading and considering every post. I haven’t yet taken the issue to the TAB. I’ve been preoccupied mostly with other post-launch issues like improving our rate limits and renewal emails, and getting XP support working. I’ll bring it to them in the next few weeks.
Personally: After 4 months of experience, I feel that the 90-day lifetime has been very helpful so far. Most clients appear to be implementing automated renewals, which is great. I think that would be less likely if the clients could request longer lifetimes, and the author could postpone implementation of autorenewal until late 2016. Relatedly, we’ve found some issues that people have had at renewal time, and we’ve been improving the service to work around those issues. In a world of 365-day lifetimes, we may not have discovered those issues so quickly.
Relatedly, the fix for the Windows XP problem is going to involve deploying a new intermediate certificate. With 90-day certs, we can be confident that within 90 days, all currently-valid Let’s Encrypt certificates will be using the new, improved intermediate, and all those sites will be compatible with Windows XP. This type of transition would take much longer if some of our certificates were for a year or longer.
As @cool110 said, I think the HPKP / DANE use case is adequately addressed by requesting the same key at renewal time.
Believe me, I feel this pain. I recently advised a friend to pay(!) for a certificate from her shared hosting company, because they don’t yet support Let’s Encrypt, and the process of manually issuing certificates from Let’s Encrypt and uploading them to the web interface would have been too time consuming and tedious. Of course, I didn’t like making that recommendation when I work on Let’s Encrypt.
However, if she only had to generate and upload a certificate once a year, that would not be an improvement. It would still mean learning an arcane skill that takes away time from much more important work that she would otherwise be doing. In a year, if people are still copying and pasting keys and certs into hosting control panels, that doesn’t look like success to me. Success, in the shared hosting side, will be when a large number of providers implement automatic Let’s Encrypt issuance for all sites, with no configuration needed. Longer lifetimes don’t help us get there, and may even make it harder to get there.
I’d rather have used startssl in that case especially now since they got better with giving up to 5 domains and removing certain restrictions (like that you couldnt issue for .tk) and it’s still fairly easy.
personally I think that there should be a way to let “manual verification” work in a more or less easy manner (e.g. offer email verification) and let only the ppl with manual validation get longer times.
I do not agree with you on that point. Managing DANE by hand is really really pain in the ass, so I came up with automation for that years before letsencrypt even exists.
Now, I have certificates issued automatically and DANE put up to date immediately after that.
well I dont see where it is so hard doing dane by hand, unless you try calculating checksums by hand either. making dane isnt all that hard. there are generators for records out there in the web but you could probably do the checksum with openssl which gives you proper cert hashes without relying on a web service.
and when you have the checksum, the rest is actually pretty easy.
okay. I didnt talk about something that big. but if cloudflare will offer TLSA records you can also script that because they have an API that can do a lot and maybe even manage that when it comes.
It’s a simple case of the main site needing to be up before the root cert being created and the community before the intermediary got its cross signature.
Good points! We got the cert for letsencrypt.org before we were able to issue certs ourselves, and indeed before we had talked much internally about certificate lifetimes. We’ve talked a number of times about re-issuing from Let’s Encrypt for the reason you said - we want to be eating our own dogfood. However, for letsencrypt.org in particular we want to make sure the site is accessible to people whose browsers may not trust our root, so they can find out more about it.
The community site is a similar case: we set it up before we were publicly trusted, so Discourse (our host) had to get a certificate elsewhere. I think they may plan on integrating Let’s Encrypt, but haven’t done it yet.
I don’t think there are too many CAs that issue certificates with lifetimes that short. Seems like a lot of effort for questionable gain.
The premise is wrong too: Automation is what enables short-lived certificates. Before Let’s Encrypt, that wasn’t really a possibility unless you were already running your own trusted CA.
Yes, that’s a good point too. But as I said - As of Feb 2015, when we set up the site, we hadn’t actually had a discussion about certificate lifetimes.
Yes, I know it is over year old but situation changed since then and I thing it is good to show you are using your own product now
BTW, I agree on short lifetime. It has good side effects - better motivation for HA solution (life reloads of websites) and scripting certificate renewal.
