Hacker News Reader

Comment by overshard | Hacker News Reader

The "How It Works" page, https://letsencrypt.org/howitworks/, has me a bit worried. Anytime I see a __magic__ solution that has you running a single command to solve all your problems I immediately become suspicious at how much thought went into the actual issue.

If I'm running a single web app on a single Ubuntu server using Apache then I'm set! If I'm running multiple web apps across multiple servers using a load balancer, nginx on FreeBSD then...

All the same I'm really looking forward to this coming out, it can be nothing but good that all of these companies are backing this new solution and I'm sure it'll expand and handle these issues as long as a good team is behind it.

View on HN

What you're seeing today is demos, not the software in its final form. You're also seeing it demo'd with a focus on the most simple usage. There are, and will be, advanced options.

We'll be doing quite a bit of work based on user feedback between now and when we go live. We're well aware that we need to cater to a variety of types of users.

I run Apache httpd, and there's no way I'd let a wizard anywhere near my configuration files or private keys, much less run it on a production server.

I think it's about time for a free CA that is recognized by all clients, but you still need to establish a trust chain to exchange a CSR for a signed certificate. This service needs to be server agnostic. The barrier to adoption isn't configuration, and HTTPS isn't the only thing that uses certificates.

There are lots of different barriers to adoption. With this project we are attacking several of them at the outset, including the cost of obtaining a certificate, and the inconvenience or difficulty of obtaining and installing it for users who don't do that every day.

Because of the open protocol we also aspire to support users with more complex configurations and requirements, who are absolutely welcome and encouraged to write their own implementations of the protocol and integrate with their own existing certificate management and configuration methods. If you think of other barriers to adoption that we can help with, please let us know and we'll try to address them; if you just want our certs for free, please get them and enjoy!

My concern is that your reach is too far. Asking domain administrators to trust your software to manipulate private keys (and server configurations) is as troubling as asking end users to click past security warnings. The whole purpose of the CSR is to obtain the signed certificate without putting the private key at risk. This decoupling isolates the challenge of identity verification in a reasonable place (nobody is saying it's easy). With your client, you're essentially telling people you accept checks or credit cards, but only if they show you their gold. It sets a bad precedent.

I do want your certs for free! But I also want/need to trust you and know that you're following best practices, not just with me but with everyone.

Oh, our software does NOT send the private key to the CA. Never never never never. The point of having it manage the keys is not to give us access to them, it's to be convenient for the end-user, on the end-user's own system, under the end-user's control.

You can tell because our software is open source, written in Python.

https://github.com/letsencrypt/lets-encrypt-preview

We expect the users to get this software from their operating system repos, like from the Debian package repository -- the very same place they get their Apache or Nginx packages. We are not asking people to get the software directly from us, or to use it without being able to read it and check that it's safe and does what they want.

Edit: And if you want to implement your own client, we encourage you to do that -- the more clients the merrier!

I'd still be more comfortable if the process never went anywhere near the private key (and I'm concerned that a proprietary competitor or look-alike would prey on naive users by leveraging your example). But I also applaud your effort and transparency. I admit I trust openssl to manage my own keys and certificates, and there is definitely room in this space for improvement and alternative approaches. But it does sadden me that we risk making administrators as trusting and ignorant of the underlying principles as end users already are today.

Yes, this will only hit the common small-site case. Hopefully if you're running "multiple web apps across multiple servers using a load balancer" you will have the skill to configure HTTPS properly for that situation, which will probably involve custom configuration on the load balancer. It's not a criticism of something trying to solve the common case, where the common solution up until today is pretty much "just forget about it", that it doesn't work at "cloud scale".

It doesn't seem as magical when you drill down. And if you roll your own nginx or whatever, it'll be less transparent still. But yeah, someone like Ubuntu or Red Hat could enable this on their product that simply.

Domain validation is done through a challenge (issued by a CA) to sign arbitrary data and put on a URL (covered by the domain) the CA can then query. This seems pretty solid. Better then email.

I don't get why they are releasing a command line, instead of just giving us a cert that we can install by ourselves.

That wouldn't be safe, because then they would have access to your private key and impersonate you. Having you (indirectly via their script) generate the key and submit the public key for signing means your private key never leaves the premises.

There is no reason for the CA to ever see the private key. All they need is a CSR. This approach is fundamentally broken.

The tool will gather the domains, use the CA API to validate ownership, obtain the certs (which cannot be unilaterally created since they are based on a public/private key pair) and manage their expiry.

That's a bit more then "giving us a cert"

It's primarily because of the interactive challenge to prove that you control the domains you're requesting the cert for.

If you want, the client can just give you the cert at the end instead of installing it. In the common case for a user who's not currently comfortable with the process, the client is automating several things -- generating a private key and CSR, proving control of the domain, and installing the key and cert in the server.

It would be really helpful if your how it works page explained in detail how it works, in particular that all browsers are covered, that a key and csr are generated, the certs recd, and that the private key never leaves the server (I'm assuming that at present).

My dream cli tool would just generate key, get certs, and dump them in the dir of my choice. The server config is nice to have but not really essential or the hard part.

Really looking forward to seeing this happen, is there any beta program at present?

Here's the current process:

Generate key, Generate CSR, Send CSR, Receive Certs from CA, Verify ownership, Install certs

Presumably their command line client creates the key, the CSR, sends the CSR, then gets back the certs (at least I'd hope so). I'd be happy to use a vetted command line utility which did that, or even just parts of that process, if I were sure the private key were not transmitted. It's just automating stuff which with current CAs needs to be done manually.

Reply on news.ycombinator.com