| 17 Feb 2025 |
 hexa | looks like we always call lego | 16:58:13 |
 emily | perhaps we just need to pass an ARI flag then. (not sure why that wouldn't be default) | 16:58:42 |
| hexa | still a draft | 16:59:00 |
| hexa | https://datatracker.ietf.org/doc/draft-ietf-acme-ari/ | 16:59:08 |
| emily | I think it's been deployed at Let's Encrypt for a while though | 17:07:42 |
| emily | (years?) | 17:07:48 |
| hexa | yeah, 2023-2024 | 17:10:23 |
| hexa | they updated the spec a few times | 17:10:30 |
| hexa | securit.acyme.defaultsextraLegoRenewFlags = [
# https://datatracker.ietf.org/doc/draft-ietf-acme-ari/
"--ari-enable"
];
| 17:10:44 |
| hexa | does nothing when the acme endpoint does not offer RenewInfo | 17:11:12 |
| hexa | https://letsencrypt.org/2024/04/25/guide-to-integrating-ari-into-existing-acme-clients/#step-5-selecting-a-specific-renewal-time | 17:12:17 |
| hexa | given that lego is not in control about when we run it again that algorithm seems moot | 17:12:30 |
| hexa | --ari-wait-to-renew-duration value The maximum duration you're willing to sleep for a renewal time returned by the renewalInfo endpoint. (default: 0s)
| 17:13:24 |
| hexa | so this needs to stay at 0, since we cannot deviate interactively from the timer schedule | 17:13:41 |
| emily | probably we would need to rearchitect the entire timer logic to implement LE's recommendations | 17:13:54 |
| emily | it's another thing where modern ACME practices are better suited to long-running manager daemons than cron jobs | 17:14:11 |
| emily | we do at least randomize enough to avoid a periodic thundering herd | 17:14:28 |
| hexa | I think for now it would be good to just enable ARI, so lego would do early renewal, even if the cert lifetime is fine | 17:14:31 |
| hexa | * I think for now it would be good to just enable ARI, so lego would do early renewal, even if the perceived cert lifetime is fine | 17:14:37 |
| emily | yes, would be a good incremental improvement, should be harmless to do by default | 17:14:44 |
| hexa | * I think for now it would be good to just enable ARI, so lego would do early renewal, even if the perceived cert lifetime as sufficient | 17:15:04 |
| emily | if this supports sleeping until lego thinks it'd be a good time to renew even if the endpoint doesn't support ARI, then maybe we could get rid of timers entirely and just run a lego renewal process per domain | 17:15:25 |
| emily | I suspect not though, in which case it would be a horrible pain to bifurcate the logic | 17:15:34 |
| hexa | + lego --accept-tos --path . -d juno.lossy.network --email hexa@darmstadt.ccc.de --key-type ec384 --dns rfc2136 --server https://acme-v02.api.letsencrypt.org/directory renew --no-random-sleep --ari-enable --days 30
2025/02/17 17:17:18 [INFO] [juno.lossy.network] acme: renewalInfo endpoint indicates that renewal is not needed
2025/02/17 17:17:18 [juno.lossy.network] The certificate expires in 89 days, the number of days defined to perform the renewal is 30: no renewal.
| 17:17:42 |
| hexa | https://github.com/go-acme/lego/blob/master/cmd/cmd_renew.go#L175 | 17:18:36 |
| hexa | so we could pass a willingness to sleep 23h59m for example | 17:19:06 |
| hexa | * so we could pass a willingness to sleep 23h for example | 17:19:13 |
| hexa | and lego wouid apparently wait sleeping | 17:19:38 |
| hexa | extraLegoRenewFlags = [
# https://datatracker.ietf.org/doc/draft-ietf-acme-ari/
"--ari-enable"
"--ari-wait-to-renew-duration=${toString (86400 - 3600)}s" # 23h
];
| 17:33:19 |
| emily | yeah, but what if your ACME provider doesn't support ARI? | 18:52:09 |
