| 19 Feb 2025 |
hexa | max cert duration | 16:46:04 |
hexa | * max remaining cert duration | 16:46:07 |
hexa | ARI is a way to skip the age check on the cert | 16:46:22 |
hexa | when ARI then renew, else normal proceedings | 16:46:39 |
emily | are you sure?
--ari-wait-to-renew-duration value The maximum duration you're willing to sleep for a renewal time returned by the renewalInfo endpoint.
| 16:46:23 |
emily | seems like not that | 16:46:24 |
emily | I do know how ARI works :) | 16:46:32 |
hexa | I'm telling you that from the code that I glanced at | 16:46:57 |
Sandro 🐧 | AFAIK it is the time lego is allowed to sleep for the time to be | 16:47:41 |
Sandro 🐧 | so if we set it to 23h, it could block execution for up to 23h | 16:48:24 |
hexa | wdym block | 16:48:35 |
hexa | you can always just restart and get a new renewalinfo 😄 | 16:48:45 |
hexa | https://github.com/go-acme/lego/blob/v4.22.2/certificate/renewal.go | 16:49:08 |
emily | ok, here's what I don't understand. why do we need it to sleep at all? it could check ARI and then just say "nope" if it isn't time yet. at most we drift across the recommended renewal by ~a day | 16:49:10 |
hexa | I think that would probably be fine | 16:49:37 |
emily | I don't think that's optimal – the timer-based setup is bad – but it seems to be what fits best with the existing module structure | 16:49:38 |
Sandro 🐧 | https://github.com/go-acme/lego/blob/v4.22.2/cmd/cmd_renew.go#L176 | 16:49:50 |
hexa | I think we don't know what probable renewal intervals sent via renewalinfo would be | 16:49:51 |
Sandro 🐧 | they literally call time.Sleep | 16:50:05 |
hexa | sandro, please check the backlog | 16:50:16 |
hexa | so really, beyond a day this is just an optimization | 16:50:45 |
emily | looking at cmd_renew.go it actually seems like it will force renewal if you set --ari-wait-to-renew-duration 1s and ARI says you should wait a month? | 16:50:59 |
emily | if ariRenewalTime == nil && !needRenewal(cert, domain, ctx.Int(flgDays)) &&
(!forceDomains || slices.Equal(certDomains, domains)) {
return nil
}
| 16:51:08 |
hexa | but there is no harm in letting the acme client sleep and wait between timer runs | 16:51:14 |
emily | the "do nothing if renewal isn't required" is conditionalized on not processing ARI | 16:51:17 |
emily | so actually --ari-wait-to-renew-duration is just a weird footgun…? | 16:51:28 |
emily | so unless I am misreading this Go, to have ARI work properly and not try to renew every single day we would actually need to give it an unlimited timeout. but that doesn't work with how non-ARI certificate renewal paths on a timer work. so lego has just bifurcated lego renew into two entirely different modalities of operation based on server capabilities and then enabled that by default. which seems terrible | 16:52:43 |
Sandro 🐧 | https://datatracker.ietf.org/doc/draft-ietf-acme-ari/#:~:text=Retry%2DAfter%3A%2021600%0A%0A%20%20%20%7B%0A%20%20%20%20%20%22-,suggestedWindow,-%22%3A%20%7B%0A%20%20%20%20%20%20%20%22start%22%3A%20%222021%2D01 | 16:52:52 |
Sandro 🐧 | it allows the acme provider to give you a window where you should renew your cert because they want to go down to shorter lived certs | 16:53:16 |
emily | I promise I do not need ARI explaining to me. I was following the ARI work years ago | 16:53:18 |