I thought at least part of the point was eliminating the cost factor with strong crypto controls on the backend on a widely accepted CA with a sane process for validating ownership (ACME).
There is a case to be made for ease of use, but I don't think they are broadening the horizons for TLS by making it as easy as "sudo letsencrypt -d www.example.org auth". Because 9 times out of 10 when you enter that command the first thing that will happen is 'port already in use'. Now what, shut down the production server? Or, trust this [1] to parse and edit my config files directly?
Now, tell me they created a Wordpress plugin which you install, activate, and magically you now are running TLS, and I am 100% with you. That's a package which makes 100% sense to me. But there's no 'git pull' or 'sudo' anywhere in there that an end-user would see or have any clue about.
If the person installing or renewing the cert is trying to decide, what should I type here...
user@www:~$
Then I think the answer is not what they are currently shipping. Give me a tool which lets me generate the ACME validation file, and then a second command to pull the cert once the file is in place. Two bash scripts which don't even need 'sudo' to run. Save the "full automation" for things like Wordpress plugins, not the shell.
Requiring the script to be run as root is a design decision, and I highly doubt it will be changed. They use the fact that the script is able to bind a privileged port (80) to prove it's being run as root so that chaos does not ensue in shared hosting environments.
I would agree the level of automation which the tool currently exerts (and the potential for resultant chaos) is definitely a good reason to require root privs by design.
I'm sure that they do not feel like the level of automation imposed by the tool is somehow a necessary component of the validation before they will generate a certificate. Certainly, there is no cryptographic value, because their tool doesn't do anything special, so there's no proof or requirement you actually run this particular tool. On their side they make the request for the validation file on the domain root on port 80, but the particular machine being controlled may be, in turn, replying to a request on a higher port.
The pair of bash scripts I would want to use each simply create a file in the CWD, so they cannot possibly cause chaos, and therefore I think most would agree can be shipped without imposing (artificially or not) a sudo requirement.
There is a case to be made for ease of use, but I don't think they are broadening the horizons for TLS by making it as easy as "sudo letsencrypt -d www.example.org auth". Because 9 times out of 10 when you enter that command the first thing that will happen is 'port already in use'. Now what, shut down the production server? Or, trust this [1] to parse and edit my config files directly?
Now, tell me they created a Wordpress plugin which you install, activate, and magically you now are running TLS, and I am 100% with you. That's a package which makes 100% sense to me. But there's no 'git pull' or 'sudo' anywhere in there that an end-user would see or have any clue about.
If the person installing or renewing the cert is trying to decide, what should I type here...
Then I think the answer is not what they are currently shipping. Give me a tool which lets me generate the ACME validation file, and then a second command to pull the cert once the file is in place. Two bash scripts which don't even need 'sudo' to run. Save the "full automation" for things like Wordpress plugins, not the shell.[1] - https://github.com/letsencrypt/letsencrypt/blob/master/letse...