In reply to @emilazy:matrix.org
(in terms of "ACME quality of implementation and best operational practices" I think Caddy has very few competitors and would solve a lot of our problems; we can start up a single long-running daemon and get rid of basically all our gross shell logic. but it's not all sunshine and roses; for one thing, using DNS providers would require us to have a story for Caddy modules (though we could probably just build a mega-ACME-Caddy with all the first-party providers out of the box), and also you can certainly do better in terms of hardening (Go is memory safe, but AFAIK there's no privilege separation going on: it's possible that exploits could leak private key material through confused deputy or Go runtime exploits))

Test "Can request certificate with Lego's built in web server" failed with error: "unit "acme-finished-http.example.test.target" is inactive and there are no pending jobs"

In reply to @hexa:lossy.network

Test "Can request certificate with Lego's built in web server" failed with error: "unit "acme-finished-http.example.test.target" is inactive and there are no pending jobs"

In reply to @m1cr0man:m1cr0man.com

okay yeah, so these are pretty lenient for most people. I think I was only concerned about the concurrent one that the ticket opener mentioned:

the “new-nonce”, “new-account”, “new-order”, and “revoke-cert” endpoints on the API have an Overall Requests limit of 20 per second.

Right now this one is very easy to do