Getting Bad Vibes

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.

8 Likes

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.

8 Likes

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

1 Like

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.

1 Like

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.

2 Likes

@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 https://community.letsencrypt.org/t/maximum-and-minimum-certificate-lifetimes/. I encourage you to continue the conversation over there rather than creating new threads.

2 Likes

"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. GitHub - plesk/letsencrypt-plesk: Let’s Encrypt extension for Plesk gives all Plesk users the power to get a free Let’s Encrypt certificate with just a couple of clicks.. 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.)

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’.

2 Likes

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.).

Absolutely!

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.

5 Likes

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…

1 Like

Guys, the certificates work perfectly fine on Windows, just get the pem keys on a linux VM, copy them to your windows box and run command:

openssl pkcs12 -export -out cert.pfx -in cert.pem -inkey privkey.pem -certfile chain.pem

We are successfully using letsencrypt generated certificates on our Windows boxes in Azure.

Our C++ implementations has <1000 SLOC, the most complex part was JWK/JWS. For all crypto things we use OpenSSL, for all HTTP-related tasks we use a separate HTTP client library.
I personally see the biggest challenge in the IIS configuration (but I'm not familiar with IIS, .Net etc.).

Why? Once you've successfully automated the task and your software is "mature" and error resilient, the certs could even have a validity of one week. Who cares?

4 Likes

The issue is whether you trust such a utility on a production environment (and all it’s pitfalls described extensively above). I personally wouldn’t and from the comments above (and the discussions happening in other platforms such as Twitter or Reddit), a lot more people wouldn’t either. There’s no technical justification on not using certificates with longer expiry dates for people not wishing to follow the spoon-fed automated approach,

1 Like

To all participants of this thread.

I respectfully ask that discussion specifically regarding 90 day certificate lifetime make use of the all ready existing thread specifically on the subject of min and max certificate lifetimes.

As the originator of this thread. My desire was for it to be a broader discussion of things like policy drivers, philosophy, objectives, influences, and the like. Not the technical aspects of a specific issue or concern.

Thank you.

1 Like

@NOYB, it’s clear you have a bad feeling about this project. I can understand your statement that you would not wish to contribute to a project you have misgivings about. The suggestion that you have to “make positive suggestions or even contribute some code” doesn’t make a whole lot of sense - just because you’re pointing out a problem does not obligate you to help solve that problem.

However… you opened this discussion with a vague comment about “bad vibes”. You’re now stating that this thread was intended to be “a broader discussion of things like policy drivers, philosophy, objectives, influences, and the like”. So, presumably, something about these things are giving you a bad feeling.

If someone with more experience with certificates would like to air their misgivings about this project, I (as someone relatively new to this and eager to learn more) would love to hear them. But you haven’t done that. So let me ask the question which others in this thread have hinted at: what is it about the “policy drivers, philosophy, objectives, influences, and the like” that worries you?

5 Likes

well I want to know about the details too @NOYB

1 Like