NixOS's security.acme
is using simp_le
to obtain Let's Encrypt certificates
simp_le
is a very basic and almost unmaintained tool with at least the following problems:
dns-01
challenge, only http-01
, so it requires a machine with http-server and public IP addressI think simp_le
should be replaced with a more sophisticated and popular alternative, for example dehydrated
or certbot
or acme.sh
I also just added lego
support here (https://github.com/NixOS/nixpkgs/pull/34830), if that would work.
I can take care on this issue, just need to know which one of the tools the people prefer.
And it might affect other modules, at least nginx
with its useACMEHost
https://github.com/NixOS/nixpkgs/pull/33900
cc maintainers @abbradar @fpletz @globin
@volth
it tries to obtain all the certificates on each service (re)start, without checking that a certificate has been recently obtained and does not need to be obtained again. This quickly results in Let's Encrypt servers ban the IP address due to excessive usage.
Hmm, I though we are safe here:
simp_le:1517: Certificates already exist and renewal is not necessary, exiting with status code 1.
I've started porting our ACME module to acme.sh with a different style of hooking and DNS challenge support. Not sure if I'll be able to finish that for 18.03 or if acme.sh is really the way to go. It does some weird stuff with the global state so even though it would support multiple certs with one state dir, a separate one for each certificate is used.
Here's the code - maybe somebody wants to pick up the work: https://github.com/NixOS/nixpkgs/compare/master...mayflower:refactor/acme-sh
IIRC I tested both the HTTP and DNS challenges successfully but there is no support for keeping the old certs and state. The branch above is an untested rebase against master because I originally did the work on top of 17.09.
@fpletz have you seen Stateless-Mode in acme.sh? It looks like a nice way to simplify the nginx machinery and get rid of acmeFallbackHost
hack on multi-frontend systems. And it works smoothly with Varnish, which cannot serve files from a directory.
@fpletz I'm the author of acme.sh, please feel free to let me know if you need any help from me.
Thanks.
@volth Yeah, absolutely. We can do that eventually but I wanted to test the regular http-01 challenge first.
This seem to be more issue now. I've run acme and got:
simp_le: error: unrecognized arguments: --tos_sha256 cc88d.......
@spinus Should be fixed with https://github.com/NixOS/nixpkgs/pull/37733
I have cherry-picked #37733 yesterday and got this instead on a new server:
Apr 01 02:17:26 relay.abbradar.moe acme-relay.abbradar.moe-start[11427]: 2018-03-31 23:17:26,410:DEBUG:simp_le:336: Loading fullchain.pem
Apr 01 02:17:26 relay.abbradar.moe acme-relay.abbradar.moe-start[11427]: Not enough PEM encoded messages were found in fullchain.pem; at least 2 were expected, found 1.
Didn't have time to investigate this yet.
With so many different possibilities, I wonder if it makes sense to decouple cert and backend configs, e.g.,
security.acme = {
backend // one of "simp_le", "acme.sh", ... or "none"
certOpts // to specify certs regardless of backend
simp_le // config for simp_le backend
acme-sh // config for acme.sh backend
};
...
If I wanted to roll my own setup, I could set backend="none"
and still rely on security.acme.certOpts
to find which certificates I need to install.
I'm running in to the same issue as @abbradar. Has there been any development here? Thanks so much for any help.
There is #38372.
I have same issue as @abbradar as well. I had possibility to switch back to 17.09 so I did (and it works there, so looks like some kind of regression).
@dotlambda how this helps here? (actually, why we need CA there, I think current implementation already creates some certs, no?)
Having a different backend than simp_le available would also make getting certificates for non-web-servers (like IRC in my case) much easier. I'll take a stab at this in the following days.
@hyperfekt i already started some investigation with lego and it seems to be a pretty good fit... being a single binary, all parameters available as a command line option etc... acme.sh or dehydrated require configuration files to be written at specific places and have dependencies on some shell tools.
@hyperfekt @mbrgm I have some need for letsencrypt with dns-01 challenge so was just wondering if you've had any progress on this?
Most helpful comment
@fpletz I'm the author of acme.sh, please feel free to let me know if you need any help from me.
Thanks.