4 ms·

I do wish the ACME ecosystem was as fire and forget as it's always aimed to be. It feels like an annual occurrence where I need to fix... Something misfiring wi

by Macha 3y ago

I do wish the ACME ecosystem was as fire and forget as it's always aimed to be. It feels like an annual occurrence where I need to fix... Something misfiring with acme cert issuance and I've tried certbot, acme.sh, Lego and they've all had issues. Like maybe when first issued the tool decided to use ZeroSSL but on reissue decides to use Let's Encrypt and fails because one requires an email and the other doesn't. Or the verification method gets deprecated and requires manual software updates. Or the tool decided to rename it's environment variables and auto updated so now it can't find it's DNS auth keys.

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 ago
  Huh, 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 ago
    Ah, 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.
Aissen 3y ago
I'm using certbot and acme/autocert, and it has been a few years since I last fiddled with this (even though I have CD happening !). I was a bit mad at certbot for having chosen snap as its recommended installation platform, but my solution to use pypi + CD seems to be quite stable (famous last words). The go services I run with autocert have had no manual intervention ever since the ACMEv2 move.
- placatedmayhem 3y ago
  EFF offers certbot in a Docker image, which is what I've been using for years: https://eff-certbot.readthedocs.io/en/latest/install.html#alternative-1-docker https://eff-certbot.readthedocs.io/en/latest/install.html#al...
crotchfire 3y ago
This is why I use .onion urls instead of WebPKI.

by Macha 3y ago

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 ago
Huh, 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 ago
  Ah, 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.

Aissen 3y ago

I'm using certbot and acme/autocert, and it has been a few years since I last fiddled with this (even though I have CD happening !). I was a bit mad at certbot for having chosen snap as its recommended installation platform, but my solution to use pypi + CD seems to be quite stable (famous last words). The go services I run with autocert have had no manual intervention ever since the ACMEv2 move.

placatedmayhem 3y ago
EFF offers certbot in a Docker image, which is what I've been using for years: https://eff-certbot.readthedocs.io/en/latest/install.html#alternative-1-docker https://eff-certbot.readthedocs.io/en/latest/install.html#al...

crotchfire 3y ago

This is why I use .onion urls instead of WebPKI.