[linsomniac]

We make extensive use of self-signed certificates internally on our infrastructure, and we used to manually manage year-long certs. A few months ago I built "LessEncrypt", which is a dead simple ACME-inspired system for handing out certs without requiring hijacking the HTTP port or doing DNS updates. Been running it on ~200 hosts for a few months now and it's been fantastic to have the certs manage themselves.

https://github.com/linsomniac/lessencrypt

I've toyed with the idea of adding the ability for the server component to request certs from LetsEncrypt via DNS validation. Acting as a clearing house so that individual internal hosts don't need a DNS secret to get certs. However, we also put IP addresses and localhost on our internal certs, so we'd ahve to stop doing that to be able to get them from LetsEncrypt.

[jraph]

Why or in which cases is opening a dedicated port better than publishing challenges under some /.well-known path using the standard HTTP port?

(You say hijacking the HTTP port, but I don't let the ACME client take over 80/443, I make my reverse proxy point the expected path to a folder the ACME client writes to, I'm not asking for a comparison with a setup where the acme client takes over the reverse proxy and edits its configuration by itself, which I don't like)

[linsomniac]

The case for it is where it's not easy to plop a file in a .well-known path on port 80/443. If you have a reverse proxy that is easy to set up to publish that, that makes it easier. I guess I could have used different wording, I do consider making the .well-known available a subset of hijacking the port, but can see why it would be confusing. ACME setup can still be trickier to set up, but is definitely a good solution if it fits in your environment.

[jraph]

ok, thanks!