| 19 Feb 2025 |
 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 |
