Getting Bad Vibes


I always thought that software made for one arch doesnt work at another which is one of the main reasons winRT cannot run any normal windows software…

but talking about pita, seems that multi-domain manual is a pita as well, just when I try to get a SAN let me do the same challenge for all domains, and/or leave confirmed ones intact if the same LE acc is used


If you look at the page its mission is pretty clear.

Let’s Encrypt is a free, automated, and open certificate authority (CA), run for the public’s benefit.

That the goal is clearly to automate certificate provisioning. I’m afraid some of you have the wrong expectations.


just provide the certs and let users handle the security part

The problem is that there is no such thing as “optional security” (ex. see Theo de Raadt’s rants on topic). Certificates are intended to provide transport security; if they are compromised, they are effectively useless. Let’s Encrypt builds the tools which allow really easy provisioning, which helps TLS adoption in practical cases. The tools are going to be used by a lot more people than just those with infosec understanding, and I believe there should be some restrictions which make the whole ecosystem more secure.

I believe we’ll have quite a lot of guides on Let’s Encrypt for general public soon, and I would rather not see smth like

Just get a cert for two years and let it stay in there. Nah, that’s fine. Who cares about rotation anyway?
Oh, something’s not working? Did you try chmod 777?

It’s quite easy to draw some similarities with SELinux from this point, I think.

Something breaks? Turn SELinux off. It’s scary and it breaks stuff.

Maximum (and minimum) certificate lifetimes?

In this case, Let’s encrypt is absolutely useless for professionals that will never trust an automated utility to manage their certificates. If the aim of this project is to just accomodate the needs of a few amateur admins with no experience in editing Apache / Nginx / lighttpd config files, then I certainly don’t want to use this service…


professionals that will never trust an automated utility to manage their certificates

Sorry, do you really think that companies with a vast infrastructure like Google, Twitter or Cloudflare rotate anything by hand? For ex. Google’s certificates are valid for three months, but are exchanged once a month. So, the idea is they have a contract with some Indian outsorcing firm to go through all their SSL-termination servers every month?

You see, there are people who just want to have their own simple service set up - with no need to go through the complexities of TLS and PKI. There are amateur admins, who have a lot to learn and a lot of mistakes to make. There are enterprise admins ruling over thousands of servers, with as much as possible automated. There are also SMB-retrogrades who deem themselves “professional” while thwarting the lowly “amateurs”, lost in their ignorance (oh, dramatic!).


if you’re an experienced admin for nginx or apache, you might want to look into letsencrypt client’s webroot authentication plugin see Letsencrypt Webroot Authentication Tested on Beta invited/whitelisted domain and Using the webroot domain verification method

With webroot authentication there’s a clearer separation in that letsencrypt client doesn’t actually touch your web configuration itself - instead it just validates the domain(s) when you pass the public web root path of your domain(s) to the letsencrypt client. So you can script and do the actual web server end configuration the way you want it setup and just point to the letsencrypt client obtained ssl certificate related files.

Letsencrypt client’s webroot authentication plugin is what I am integrating into my own Centmin Mod Nginx LEMP web stack for Nginx vhost auto generation with Letsencrypt SSL certificate and auto renewal scripted support - latest progress (still waiting on ability to update registered LE account’s email address Clarify the --email flag requirements? though and for multi-domain SAN ssl).


FWIW, I’m personally also not overjoyed with the current quality of the standard ACME client, but honestly, it’s not a security issue at all. And if you don’t like it, you’re entirely free to write your own; the protocol is open, and you can build your own web interface talking to it if you’d like.

LE, as a whole, is massively useful to the Internet. The automated procedure is unusual, but I believe that’s a good thing, not a bad one.


In this case, Let’s encrypt is absolutely useless for professionals that will never trust an automated utility to manage their certificates.

This is false, professional do automate everything. It would also be technically impossible. I’m managing a bit more than half a million certificates at work, I really don’t see how I could do it in any other way but automated. Manual intervention is error prone, impossible to scale, slow to recover and has no reproducibility.

While your lack of trust in LE client is unfounded IMO but as always trust but verify, and given that everything is open source, just go ahead and audit the client. If you are not satisfy, use one of the alternative client or implement one.


I think not that automation is bad but users should be able to get some control, because LE cannot work everywhere automated.


I can’t think of a case ACME does not solve (except wildcards).
If we have ACME, a backend, everything else is only a problem of a client (ex. an Installer plugin for letsencrypt). The only case which is problematic to cover then is embedded, I think.
Maybe you could provide some more cases where “LE cannot work automated”?
Also, optional security is bad security.


I dont say users should compromise the security, but making the cert time a year which is pretty standard shouldnt be that much of a problem, also heard of shared hosting where the best a user can do is manually upload files via ftp and putting in certs via some more or less stupid webinterface. you can only go manual there.


@NOYB: I hear your criticisms. However, ultimately I disagree with you. I hope you can see that that disagreement is not dismissal, but is based on experience and judgement. I’m sorry Let’s Encrypt will not meet your needs at launch. I would encourage you to wait six months and see whether Let’s Encrypt is succeeding in its goals.

I’ll note that this thread is effectively a duplicate of I encourage you to continue the conversation over there rather than creating new threads.


“Pretty standard” != secure. Ex. Heartbleed.

shared hosting

Yes, this is a case to consider. I believe the best option is having a hoster integrate LE into their infra, ex. Another option is asking the hoster for API, and yet another is trying to hack it out by emulating browser, which is problematic.
I think there will be hosters incorporating LE in their products (I think I’ve seen a discussion somewhere), which is certainly best for end-user.

Another thing to note is that LE’s goal (AFAIC) is not to just give everyone free certs; it is to build an encrypted web, with safe transport. To achieve high spread, making your service secure should be easy, as close to run and forget as possible. Which can only be done with some constraints such as regular rotation and only automated. Sure, initially not all cases may be covered, but for most this is just a matter of time (i.e. of written Installer's). And for a small part left - LE is just not targeted at these.

(I should have migrated to the other thread.)

Maximum (and minimum) certificate lifetimes?

There are already different implementations. (Java, Python, etc.)
But i also must admit that the default implementation is really large, and the protocol documentation could be improved,
But this is the stuff that will come when beta ends and more people going to use it.

On the other hand concerns about wildcard and lifetime:

  • Wildcard are always expensive on other CA’s so even if they would be nice it is not necessary
  • Lifetime is already long naught disused in another thread.

Nice would be if @NOYB not only say what he have bad vibes but make positive suggestions or even contribute some code.


That’s a common assertion people try to use against dissenters of something. But it is really kind of a silly assertion, but it does served to deflect from the issue rather than having to respond with a point.

Why would I/dissenters contribute code to enable doing something that I/we disagree with.
(please note that is a rhetorical question)


I disagree that this a duplicate of that thread. That thread is about one specific issue; certificate lifetime policy. This thread is much broader, about Let’s Encrypt policy, philosophy, influences, objectives, imposed requirements that perhaps may be driving policy, etc.

Something doesn’t seem to add up. And it concerns me. And I think it should, and probably does, concern others too. So I created this thread for that reason.

I see your duplicate assertion response as yet more dismissiveness of community concerns.


@NOYB yeah I can understand that it isnt just a duplicate but you never outlined any details, and that would be nice.

well, but not every hoster wants to integrate LE into their service (maybe because they sell certs themselves and want the users rather to try those, or they dont want anything that is unknown or potentially unsecure/unstable) and not everyone uses plesk.
also asking the hoster to make an api, how far can you even be in your world of dreams? the probability of them doing that much extra effort just so everyone can get automated free certs is most probably so close to zero that even a hair cannot fit in between.

also emulating a browser does not only bear problems but it’s plain stupid, it doesnt really solve the problem… For once the client needs your password essentially in cleartext and if there is any little change in the UI, well guess what happens.


I am not saying that every single hoster will integrate LE nor that we should go with either of other two technically possible but barely feasible solutions.

Rather, my point is that LE aims for easy (part of which is free) and secure. I’ve already stated why we can’t both have ‘secure’ and ‘something which lets anyone do a not-so-secure thing because they supposedly know what they’re doing’.
So, it may not be able to fit into all usecases. But should it? The target should be ‘security’, not just ‘plunge certificates everywhere and we’ll be fine’.

Maximum (and minimum) certificate lifetimes?

I’ve had a quick look at that, but stopped continuing as I stumbled upon an exec call of the OpenSSL binary. So that’s not a pure JavaScript solution - which works in Node.js, but not in a browser.

The sexy a browser solution is, in the end it’s a manual solution again. So I propose to not put any effort into a manual browser solution (at least not with 90-day-limits).
(Just an idea: for funding the IRSG, you could eventually give out 1-year-certs for a decent amount - though this implies things like billing, taxation, “non-profit”-discussions etc.).


As a small feedback: we have successfully implemented an “own” ACME client into our product (shared hosting control panel). A user can enable SSL by just entering the required domain - THAT’S ALL. No CSR, no intermediate certificates, no validity issues. IT JUST WORKS. :smile:
We’re right before public release with this and are still working on documentation; if anyone is interested in a more detailed post, please let me know.

All in all, I don’t see any problem with the 90-day-policy, as long as everything is fully automated. And that’s what at least shared hosting is all about! For any critical system with manual interaction required, I have no problem to spend some bucks for a 1-year-cert, but for the masses ACME is exactly the right thing!

Don’t confuse the Let’s Encrypt CLI (python tool) with Let’s Encrypt (the CA accessible with the ACME protocol). If the client does not fit your needs, just use another one. It’s no rocket science to implement ACME, and various libs are being developed right now.

I think it’s not the goal of Let’s Encrypt to suit all needs.


Well, I’d like to meet the rocket scientist who will implement a reliable ACME client for the Windows environment and update certificates on IIS. I surely wouldn’t trust any such utility on my production servers. I’ve myself started building a .NET library for the ACME protocol (minus the auto-installation part), but the 90-day limit makes then whole project pointless…