September 17, 2018 posted by S.P.Zeidler

using DNS alias mode with sub-domains dedicated to ACME verification

delegating the sub-domains to the servers where the certificate will be needed

using bind on the servers where the certificate will be needed (where it was running as resolver already anyway)

using dns_nsupdate (i.e. dynamic DNS) to add the challenge to the ACME subzone.

options { .... allow-update { localhost; }; .... }; zone "acme-www.pkgsrc.org" { type master; file "acme/acme-www.pkgsrc.org"; update-policy { grant acme-ddns name _acme-challenge.acme-www.pkgsrc.org. TXT; }; };

Peter Wemm's writeup about using acme.sh for FreeBSD.org served as inspiration, but I chose to do a few things different:Appropriately restricted, that gives the following addition to named.conf on the target server (with an update key named acme-ddns):And last but not least, deployment of certificates via make, i.e. completely independent of acme.sh.

Due to all of the above, acme.sh does not need to tentacle about in the filesystem and can run as a plain user in a chroot. It's not a tiny chroot, though (20M), since acme.sh needs a bunch of common shell tools:

awk basename cat chmod cp curl cut date egrep/grep head mkdir mktemp mv nsupdate od openssl printf readlink rm sed sh sleep stat tail touch tr uname, and their shared libs, /libexec/ld.elf_so and /usr/libexec/ld.elf_so;

under the chroot /etc a resolv.conf, the CA cert for Let's Encrypt (mozilla-rootcert-60.pem) and to make openssl complain less an empty openssl.cnf

and in the chroot /dev: null, random and urandom.

I call both the acme.sh --cron job and the certificate deployment make from daily.local, which adds the output to the daily mail and makes it easy to keep an eye on things. [0 comments]