Comment by overshard
11 years ago
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.
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.
2 replies →
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.
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.
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"
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.
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?