
Show HN: ACME Let's Encrypt client – binary releases, works like 'make' - davewongillies
https://github.com/hlandau/acme
======
MatthewPhillips
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.

[1] [https://caddyserver.com/](https://caddyserver.com/)

~~~
amelius
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.

~~~
MatthewPhillips
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?

[1] [https://caddyserver.com/docs/git](https://caddyserver.com/docs/git)

------
rch
Shouldn't something called Acme work more like mk than make?

Good work and good ideas though. I haven't looked at the Python client, but it
seems like there may be some valid points here.

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

~~~
hlandau
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.

~~~
luchs
Ah, cool - I will try it then.

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.

------
dujiulun2006
I wouldn't use pre-compiled binaries when it comes to certificates...

I would read the source code and compile ($ go build) it.

~~~
alexchamberlain
Agreed; trusting a binary distribution for what is a security measure seems a
bit weird...

~~~
stephenr
It depends a lot on the source of the binaries.

------
Sir_Cmpwn
I'm curious - why is the LISTEN option only useful in development?

~~~
matt4077
It takes over port 80/443.

~~~
Sir_Cmpwn
Oh, now I understand. I wonder why Let's Encrypt/ACME servers aren't able to
make the verification requests on some other port.

~~~
jdiez17
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.

~~~
Sir_Cmpwn
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.

~~~
detaro
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.

~~~
hlandau
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.

------
MatthewWilkes
The official let's encrypt client will happily not modify your configuration,
too. I don't understand why being distributed as a binary is important.

------
anon1mous
I don't understand. What is the purpose of this tool?

------
doczoidberg
'Supports any web server

does this work with azure ASP.NET?

~~~
hlandau
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.

