2 ms·
Interesting. I was using acme.sh and switched to lego, largely because I manage my servers with Puppet and acme.sh’s config format didn’t lend itself well to co
by akerl_ 3y ago
Interesting. I was using acme.sh and switched to lego, largely because I manage my servers with Puppet and acme.sh’s config format didn’t lend itself well to config management.
I renew certs for several boring things like nginx instances, but also things like my printer’s web portal, a Synology NAS, and a Unifi console that require bespoke commands to reload the cert.
I’ve got monitors that fire if any of my certs drop below 27 days before expiry, and over the past ~2 years, 100% of the problems have been with the custom hooks. I’ll log into the server and find that it did reissue the cert, but the command to make the Synology ingest the new cert failed for some arcane reason. The servers where it’s just running systemctl restart nginx or similar don’t fail.
- Macha 3y agoHuh, the environment variable thing was specifically aimed at acme.sh which rather arbitrarily changed the config value from ACMEDNS_UPDATE_URL to ACMEDNS_BASE_URL, never acknowledged this in a changelog and then silently failed after an automatic upgrade as recommended by the default install: https://github.com/acmesh-official/acme.sh/commit/2ce145f359deaaaff9bea06312984c70a04ef87c https://github.com/acmesh-official/acme.sh/commit/2ce145f359... It's also cleared out my .account.conf files when run on the suggested cron. I've started using updown which also monitors my TLS certs simply because I no longer trust the process to work as documented.
- akerl_ 3y agoAh, I plausibly didn’t hit this because I was permanently on a fork of the acme.sh codebase, after I opened a PR to support Route53 subzones and it was ignored.