If the client receives no response or a malformed response (e.g. an end timestamp which is equal to or precedes the start timestamp), it SHOULD make its own determination of when to renew the certificate, and MAY retry the renewalInfo request with appropriate exponential backoff behavior.
Currently when lego encounters an ARI renewal window that specifies "an end timestamp which is equal to or precedes the start timestamp", the following panic occurs:
This PR avoids panicking when the renewal window is "malformed", and instead makes "its own determination" that the start timestamp is "when to renew the certificate".
https://www.ietf.org/archive/id/draft-ietf-acme-ari-04.html#section-4.2 says:
Currently when lego encounters an ARI renewal window that specifies "an end timestamp which is equal to or precedes the start timestamp", the following panic occurs:
https://pkg.go.dev/math/rand#Rand.Int63n documents this behaviour: "It panics if n <= 0".
This PR avoids panicking when the renewal window is "malformed", and instead makes "its own determination" that the
start
timestamp is "when to renew the certificate".