x/crypto/acme/autocert: Persistent cache results in stuck configuration if TOS is not always accepted #18433
Milestone
Comments
taralx
changed the title
|
/cc @bradfitz |
|
I'll be back from vacation on Monday but will try to come with a fix end of
this week.
…On 4 Jan 2017 6:19 pm, "Brad Fitzpatrick" ***@***.***> wrote:
I have the same comment here as #18379
<#18379> --- don't disagree with the
TOS sometimes and expect things to work.
That said, @x1ddos <https://github.com/x1ddos> can prioritize a fix as
his schedule allows.
Alternatively, feel free to send a fix yourself if it has tests.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#18433 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/AABjPZZo5XM5ts6TL78ViZEqlaMg0qwIks5rO9SogaJpZM4LV6Oe>
.
|
|
If the only supported configuration is "accept the TOS", then perhaps the function should be replaced with a boolean, and passing "false" should cause an error without attempting registration at all. |
|
No, you're right... if it's there it should work. But it's only there as a formality, not because we expected anybody to use it. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Please answer these questions before submitting your issue. Thanks!
What version of Go are you using (
go version)?1.6
What operating system and processor architecture are you using (
go env)?amd64
What did you do?
Create a Manager that will not accept the TOS, but that does have a persistent Cache. Then re-use the cache with a Manager that does accept the TOS.
What did you expect to see?
First Manager fails to register, second Manager succeeds.
What did you see instead?
Seconds Manager also fails because acme.UpdateReg is never called.
See #18379 for the acme side of this.
The text was updated successfully, but these errors were encountered: