Skip to content

x/crypto/acme/autocert: client should deactivate authzs that failed in a non-recoverable cases #23426

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom
Closed
costela opened this issue Jan 12, 2018 · 3 comments
Closed

x/crypto/acme/autocert: client should deactivate authzs that failed in a non-recoverable cases #23426

costela opened this issue Jan 12, 2018 · 3 comments
Labels
FrozenDueToAge NeedsFix The path to resolution is known, but the work has not been done.
Milestone
Unreleased

Comments

@costela
Copy link
Contributor

costela commented Jan 12, 2018 •
edited
Loading

During the TLS-SNI incident, autocert generated a lot of dangling authorization requests because of "no supported challenge type found" errors. In this case, these authorization requests would never be fulfilled, because reference to the challenge gets discarded after the error and before anything gets put in the cache. These dangling authzs, in turn, lead to rate-limiting on the side of Let's Encrypt ("too many currently pending authorizations").

Since ACMEv1 AFAICT doesn't support querying pending authorization requests, there is no way to clean up these authzs, short of waiting for the rate limit window to pass. This may become less important after #21081, if ACMEv2 supports querying.

It would be nice if the client would deactivate the authorization requests in these unrecoverable cases . Even though the certificate wouldn't be generated, at least we would steer clear of this specific rate-limit.
@gopherbot gopherbot added this to the Unreleased milestone Jan 12, 2018
@x1ddos
Copy link

x1ddos commented Jan 12, 2018

Yeah, we should definitely delete unused authorizations.
acme.Client supports it. Just need to call it from autocert.Manager in the right place.

@titanous titanous added the NeedsFix The path to resolution is known, but the work has not been done. label Jan 12, 2018
@junderw junderw mentioned this issue Jan 21, 2018
Open
@gopherbot
Copy link
Contributor

Change https://golang.org/cl/100078 mentions this issue: acme/autocert: revoke dandling pending authzs

@costela
Copy link
Contributor Author

costela commented Mar 12, 2018

hey @x1ddos, maybe you have a couple of minutes to go over the CL? :)

@golang golang locked and limited conversation to collaborators May 23, 2019
c-expert-zigbee pushed a commit to c-expert-zigbee/crypto_go that referenced this issue Mar 28, 2022
@costela @FiloSottile
acme/autocert: revoke dangling pending authzs
43516a9 
We now keep track of pending authorization requests during verify() and
defer the asynchronous revocation of the ones that failed.
This should help avoid letsencrypt's "too many currently pending
authorizations" error.

Fixes golang/go#23426

Change-Id: Ibffb10f59733962d45e43b67fc42a2ec7c5faf51
Reviewed-on: https://go-review.googlesource.com/100078
Run-TryBot: Filippo Valsorda <filippo@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Leo Antunes <costela@gmail.com>
Reviewed-by: Filippo Valsorda <filippo@golang.org>
c-expert-zigbee pushed a commit to c-expert-zigbee/crypto_go that referenced this issue Mar 29, 2022
@costela @c-expert-zigbee
acme/autocert: revoke dangling pending authzs
60fe22f 
We now keep track of pending authorization requests during verify() and
defer the asynchronous revocation of the ones that failed.
This should help avoid letsencrypt's "too many currently pending
authorizations" error.

Fixes golang/go#23426

Change-Id: Ibffb10f59733962d45e43b67fc42a2ec7c5faf51
Reviewed-on: https://go-review.googlesource.com/100078
Run-TryBot: Filippo Valsorda <filippo@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Leo Antunes <costela@gmail.com>
Reviewed-by: Filippo Valsorda <filippo@golang.org>
c-expert-zigbee pushed a commit to c-expert-zigbee/crypto_go that referenced this issue Mar 29, 2022
@costela @c-expert-zigbee
acme/autocert: revoke dangling pending authzs
dbb681e 
We now keep track of pending authorization requests during verify() and
defer the asynchronous revocation of the ones that failed.
This should help avoid letsencrypt's "too many currently pending
authorizations" error.

Fixes golang/go#23426

Change-Id: Ibffb10f59733962d45e43b67fc42a2ec7c5faf51
Reviewed-on: https://go-review.googlesource.com/100078
Run-TryBot: Filippo Valsorda <filippo@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Leo Antunes <costela@gmail.com>
Reviewed-by: Filippo Valsorda <filippo@golang.org>
LewiGoddard pushed a commit to LewiGoddard/crypto that referenced this issue Feb 16, 2023
@costela @FiloSottile
acme/autocert: revoke dangling pending authzs
f7c8c2e 
We now keep track of pending authorization requests during verify() and
defer the asynchronous revocation of the ones that failed.
This should help avoid letsencrypt's "too many currently pending
authorizations" error.

Fixes golang/go#23426

Change-Id: Ibffb10f59733962d45e43b67fc42a2ec7c5faf51
Reviewed-on: https://go-review.googlesource.com/100078
Run-TryBot: Filippo Valsorda <filippo@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Leo Antunes <costela@gmail.com>
Reviewed-by: Filippo Valsorda <filippo@golang.org>
BiiChris pushed a commit to BiiChris/crypto that referenced this issue Sep 15, 2023
@costela @FiloSottile
acme/autocert: revoke dangling pending authzs
afbe057 
We now keep track of pending authorization requests during verify() and
defer the asynchronous revocation of the ones that failed.
This should help avoid letsencrypt's "too many currently pending
authorizations" error.

Fixes golang/go#23426

Change-Id: Ibffb10f59733962d45e43b67fc42a2ec7c5faf51
Reviewed-on: https://go-review.googlesource.com/100078
Run-TryBot: Filippo Valsorda <filippo@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Leo Antunes <costela@gmail.com>
Reviewed-by: Filippo Valsorda <filippo@golang.org>
desdeel2d0m added a commit to desdeel2d0m/crypto that referenced this issue Jul 1, 2024
@desdeel2d0m @FiloSottile
acme/autocert: revoke dangling pending authzs
76bc7bb 
We now keep track of pending authorization requests during verify() and
defer the asynchronous revocation of the ones that failed.
This should help avoid letsencrypt's "too many currently pending
authorizations" error.

Fixes golang/go#23426

Change-Id: Ibffb10f59733962d45e43b67fc42a2ec7c5faf51
Reviewed-on: https://go-review.googlesource.com/100078
Run-TryBot: Filippo Valsorda <filippo@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Leo Antunes <costela@gmail.com>
Reviewed-by: Filippo Valsorda <filippo@golang.org>
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Assignees
No one assigned
Labels
FrozenDueToAge NeedsFix The path to resolution is known, but the work has not been done.
Projects
None yet
Milestone
Unreleased
Development

No branches or pull requests
4 participants
@titanous @x1ddos @costela @gopherbot