This mostly affects autocert -- if you initially return false from prompt, then you have to kill the key even if you later return true.

This is approximately the lowest priority bug. Don't expect things to work when you don't agree to the TOS. Actually, LetsEncrypt only has the TOS agreement in the protocol because it's a CA/B forum requirement to have a contractual relationship with their "customers". While we have the hook as a formality to respect the LetsEncrypt necessary legal formalities, you should just always return true.

/cc @x1ddos

I think this is actually WAI. The acme package follows the spec very closely. So, acme.Register literally means perform the "registration" with the CA.

So, calling Register method regardless of the accept TOS return value will always result in a "conflict" error. Try calling it twice with accept TOS always returning true - you'll get a "conflict" error the second time.

@taralx so what are you proposing, add a logic to Register and invoke UpdateReg under certain conditions and don't otherwise? I'm afraid that may lead to unexpected behavior and will certainly break some existing clients which rely on that same fact that Register returns "conflict" error if called with an existing key.

This could be a feature request at best but not really sure it's worth it. Feels like very specific case and may cause more harm than good. Unless I'm missing something.

I'm fine with switching this to autocert if it's WAI for acme, but it seems weird that you only get a free UpdateReg the first time you call Register, after which you get a conflict error and no UpdateReg.

Opened #18433 for the autocert side.

follows the spec very closely. So, acme.Register literally means perform the "registration" with the CA.

If that's the case, why does it call UpdateReg at all? This is the problem IMO -- the behavior w.r.t. UpdateReg is inconsistent.

@taralx you're right. it should be consistent. I'll try to come up with a fix in the next days.