Show HN: ACME Let's Encrypt client – binary releases, works like 'make' | Hacker News Reader

Show HN: ACME Let's Encrypt client – binary releases, works like 'make'

github.com

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/

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?

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

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.

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.

I believe this is regarding the renewal cronjob.

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.

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.

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

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

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

It depends a lot on the source of the binaries.

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

It takes over port 80/443.

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

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.

Anything under 1024 requires root iirc. 81, 88, &c would show you have control of the server, correct?

The bigger issue is probably firewalls (in front of the server getting a cert) only allowing inbound on 80 and 443.

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.

Well, that can be automated easily, too.

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

You can prove you control the domain by DNS: https://letsencrypt.org/howitworks/technology/

Yes, but that is only a challenge-response DNS verification.

What I’m looking for is "I write a value into DNS once, and use that to prove at any future point at which it exists that I still control the DNS".

In this example, by putting an RSA public key in there. (the very same I use for the CSR)

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.

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.

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

'Supports any web server

does this work with azure ASP.NET?

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.

Reply on news.ycombinator.com