I've converted several projects over to Caddy[1] and been very happy with it. Caddy is a web server with Let's Encrypt integration built in. Your config can be as simple as:
example.com {
root path/to/root
}
And Let's Encrypt will automatically be used. It's amazingly simple.
I wonder if in the future we'll see things like mod_acme that automate Let's Encrypt into other servers.
Let's keep things orthogonal. I don't want to be "forced" into using one particular webserver just because it supports one feature better than another.
Sure, Caddy is pluginable, so it is orthogonal, LE just happens to be baked in and easy to use. I wasn't forced to use it, it has several compelling features (like git integration with GitHub webhooks [1]) and LE was one of them.
Presumably we'll start seeing tighter integration with other web servers, why can't there be a mod_le that automatically downloads certs from LE? And why wouldn't you want that?
I'm a bit confused about the "non-root support" -- the (somewhat lengthy) setup manual absolutely seems to require root to set up users and directories in the root filesystem.
In contrast, the official client can absolutely work without having root access. You can install it locally (pip install --user letsencrypt) and change all working directories to paths your user can write to using a configuration file.
Some people don't want to run a client as root because they don't want to increase their attack surface or don't trust the software to that extent. The purpose of the non-root manual is to allow people to take understandable steps as root to enable the client to operate not as root.
It should be possible to use the client without having root access, by passing --state (and perhaps --hooks) to use a state directory you control.
My motivation for not requiring root is shared hosting: I have a regular user witch access to an Apache webroot directory. They didn't fully automate Let's Encrypt, but they provide a script which installs certificates for the central webserver. So I have to download and run any ACME client myself to get my certificates.
There's been a lot of discussion about this on the IETF ACME mailing list. Essentially, the issue is that certificates don't nominate a specific port, so if you can get a certificate for a hostname you can impersonate any service on it. Thus, any validation method needs to represent not only a single port, but the machine as a whole.
443 is not really ideal for this purpose, but requiring control of it is probably the least worst option, security-wise.
How about requiring control over DNS, like I suggested before?
Put a public key in the DNS, sign the CSR with the corresponding private key, the CA will fetch DNS, verify the signature, and then sign your certificate.
LE lets you get a cert by putting stuff in DNS, but it's generally hard for a program running on your Web server to modify DNS in an automated fashion and this tool focuses on what can be automated on your Web server.
If I could just put a public key in DNS, sign stuff with the corresponding private key, and send the signed request via POST to LE, then they can easily check that I control the DNS, and I can automate it (and never have to change the webserver’s content or DNS).
I've suggested this on the ACME list, actually; allowing people to put their ACME account public keys in DNS, rather than the random-per-transaction challenge specified right now, which is quasi-unusable.
The problem, apparently, is that CA forum rules require that a random challenge be used. Of course this doesn't make much sense in the context of ACME, where you have a private key identifying the user account. But this obstructs the specification of a deterministic challenge for DNS, alas.
Control over a nonstandard port on a server doesn't necessarily mean that you control the web server on :80 and :443 of that host. For example, a nonprivileged user can listen on :8443 and get a cert.
Well, there are ports that require root to bind to that aren't 80 or 443. That being said, I guess it's relevant here that Let's Encrypt only supports certs for HTTP use cases.
Which leaves the question which one to occupy instead. There was the suggestion on the mailing list of officially getting an acme-port reserved, but I don't remember if there was any follow-up.
The problem is not all systems are *nix. Windows doesn't enforce the <1024 port restriction. The advantage of using port 443 I suppose is that it's so commonly used it'll probably (maybe) be tied up with one service or another when it comes to any important host. I guess. But really it's all guesswork and hope when it comes to deciding how to validate host control.
I'm not familiar with Azure. But assuming you're running ASP.NET on Windows, no. Windows support is explicitly not an objective of this client; I designed it to fit well in a UNIX system. There are probably issues with filesystem transactionality, with regard to the state directory format, and suchlike, which would be hard to port.
I wonder if in the future we'll see things like mod_acme that automate Let's Encrypt into other servers.
[1] https://caddyserver.com/