If you like minimal dependencies another one to take a peek at may be acme.sh [1]. It depends on bash, openssl and curl. It seems to work fine in ash as well. It has code to handle most API's and most importantly to me is the great documentation.

In the same spirit of minimal and light weight there is also testssh.sh [2] for testing TLS on HTTPS/SMTPS servers that also depends on bash and openssl.

[1] - https://github.com/acmesh-official/acme.sh

[2] - https://github.com/drwetter/testssl.sh

I'd prefer to use a C, Go, or Rust app at this point. I love shell scripts because it was one of the first scripting languages I learned, but I'd trust a developer capable of writing C, Go or Rust to do a better job and make something more optimized than what is within the scope of Posix shell scripting.

There's step-cli that's just a single go executable: https://github.com/smallstep/cli

They also provide a CA to go with it, if you need internal certs.

Thanks. I actually have this installed. It does so many things and is pretty incredible!

To me it is a utility stuff. As long as it does the job (and acme.sh does it just fine) and does not require pulling down half of the Internet for dependencies I would not give rat's ass about what language has been used to write it.

I don't think optimization really matters to most people for a tool that does automated cert requests.

It is to an extent. I'm not saying acme.sh is bad just that if there is a tool in Go, Rust or C that does the same thing and is more efficient then I'm picking something that isn't wrapped in a bunch of shell code. Same with tiny webservers.

I use https://github.com/go-acme/lego, single Go binary.

Personally, I'm a fan of https://github.com/diafygi/acme-tiny. 200 lines of python without any additional python requirements and only the openssl binary as external dependency.

If we're plugging implementations, I tend to use the single-file implementation that ships with 9front. I wrote the first cut, but it's been improved heavily by others:

http://man.9front.org/8/acmed

http://git.9front.org/plan9front/plan9front/HEAD/sys/src/cmd...

It works quite well, and if you mount your unix machines via sshfs, it's pretty easy to dump the certs into the right place with them.

And unlike most ACME clients, it works seamlessly with DNS authentication, which allows you to easily grab wildcard certs.

This! Thanks for also mentioning it. So plain easy and just does what I need! Thanks to the author for publishing it.

I maintain my own patch, so tiny-acme supports an '--outfile' option (it originally only writes to stdout). This comes in handy when it is run by systemd service/timer.

The pull request is on hold, because the code then exceeds then 200 lines threshold :shrug:

You can directly redirect the service's output to a file: https://www.freedesktop.org/software/systemd/man/systemd.exe...

Thanks! That's tempting to drop the patch and just stay with the upstream.

I will plug my own Python program https://github.com/frutiger/concorde, which does depend on `requests` and `cryptography`.

You can use Caddy to automatically fetch certs and keep them renewed without much hassle[0].

Disclaimer: I'm affiliated with Caddy

[0]: https://caddy.community/t/using-caddy-to-keep-certificates-r...

Yeah IMHO this is the way to go. Individual web apps managing their own SSL certs is a longterm mess. Only your proxy or HTTP gateway/router should ever touch or know about SSL certs.

Caddy is great for web servers, but it's still not possible to have it run commands post certificate provisioning. So it's kind of a non-starter for anything but web-servers as there is no way to tell a different system to reload certs.

We're working on this! Hoping to have our new event dispatching system ready in the next few months. This'll let you hook into the post-issuance event and do whatever you want afterwards.

Yeah! I saw the PR. Looking forward!

Not affiliated with caddy, but caddy is awesome! I use it all the time.

Apache also provides a 1-at party ACME client in the form of a module, mod_md.

Static linking is a huge advantage. I don't understand the point you're trying to make.

Static linking is a huge disadvantage when it comes do security updates.

C is a huge disadvantage when it comes do security.

No, that depends entirely on how it's written.

I'm using lego - https://github.com/go-acme/lego for this, single binary works great.

This is the joy of static linking!

In the end does anyone really care if it’s a 10MB tarball versus a 330kb tarball?

Yes, many of us care.

Yes, very much so. Maintaining the security of OSes where many applications statically link thousands of dependencies is impossible.

You care when you need to deploy stuff to remote servers the time difference between 10MB and 330kb. There’s also data transfer costs to consider.

I never had a problem with how long it took to install dependencies until I had to do it multiple times over in quick succession.

Why wouldn't you upload the file to all the servers, and then deploy them all in succession, rather than upload and deploy in sequence?

Dehydrated is good for this, too https://dehydrated.io/

I used dehydrated pretty effectively (along with openssl) to renew and sync certs between several layers of proxies/loadbalancers. I ended up creating a nice k8s deployment with CronJob to implement this with ingress-nginx.