x/crypto/acme/autocert: failed cert creation is never retried #17740
Comments
|
@niemeyer good point. It's a known behaviour, well at least for me. I was planning on improving it. Define "short" and for how long would it need to keep retrying (in case of consecutive failures)? |
|
Maybe a simpler way is to just remove the "bogus" state from in-memory map and retry on the next TLS hello. So, it would just seem like a new domain to the Manager. How does it sound? |
|
If you're under heavy load and push a misconfiguration, you don't want to be slamming LetsEncrypt with requests. I'd make sure you not speak out any ACME for, say, a minute after any ACME rejection. Or be smart about which errors incur which time penalties. Some might mean infinite. Some might be transient network failures and you could retry in seconds. But I think just waiting for the next TLS hello to kick off the retry seems fine. |
|
This is related to the Upspin bug: |
bradfitz
added
the
NeedsFix
|
Thinking about this more, I'm leaning towards @bradfitz's suggestion - wait a minute and then remove the failed state, allowing next TLS hello to kick off a cert request again. |
|
Something like this: https://golang.org/cl/41694 |
|
CL https://golang.org/cl/41694 mentions this issue. |
This change makes the Manager try creating a certificate again, after a previously unsuccessful attempt. The implementation is based on a timer, to prevent hitting an ACME CA with too high QPS when under a heavy load. The timer is hardcoded to 1 minute. Fixes golang/go#17740. Change-Id: I46a49201cf423be3360633a89209d7b2bccc1d76 Reviewed-on: https://go-review.googlesource.com/41694 Run-TryBot: Alex Vaghin <ddos@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
This change makes the Manager try creating a certificate again, after a previously unsuccessful attempt. The implementation is based on a timer, to prevent hitting an ACME CA with too high QPS when under a heavy load. The timer is hardcoded to 1 minute. Fixes golang/go#17740. Change-Id: I46a49201cf423be3360633a89209d7b2bccc1d76 Reviewed-on: https://go-review.googlesource.com/41694 Run-TryBot: Alex Vaghin <ddos@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
This change makes the Manager try creating a certificate again, after a previously unsuccessful attempt. The implementation is based on a timer, to prevent hitting an ACME CA with too high QPS when under a heavy load. The timer is hardcoded to 1 minute. Fixes golang/go#17740. Change-Id: I46a49201cf423be3360633a89209d7b2bccc1d76 Reviewed-on: https://go-review.googlesource.com/41694 Run-TryBot: Alex Vaghin <ddos@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
This change makes the Manager try creating a certificate again, after a previously unsuccessful attempt. The implementation is based on a timer, to prevent hitting an ACME CA with too high QPS when under a heavy load. The timer is hardcoded to 1 minute. Fixes golang/go#17740. Change-Id: I46a49201cf423be3360633a89209d7b2bccc1d76 Reviewed-on: https://go-review.googlesource.com/41694 Run-TryBot: Alex Vaghin <ddos@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
When the creation of a certificate fails, the
certStateis being stored inm.statewith an emptycertfield, and there's no logic to retry the creation. On follow up requests the bogus state is returned and requests fail forever after.Instead, it should retry after a short delay.
The text was updated successfully, but these errors were encountered: