[zaroth]

If you are creating a new account key with a new authz, but the old account key still gives you access to renewal certs, that IMO is absolutely a bug.

The authz should be tied to the { domain, account_key } tuple, not just the { domain }.

Can anyone confirm?

[TheDong]

That's not a bug.

I have multiple servers that serve { domain } in dns round-robin. Each of them has a unique account key, but they also each issue certs for the same domain.

This is a totally normal and valid use-case, and allowing only a single account key for a domain at a time would ruin it.

[zaroth]

This is contrary to their documentation at [1].

  I'm sure this is what was meant, but just to confirm and spell it out, the authorization
  has to belong to the subscriber account that's making the request right?

  @tialaramex Apologies that it wasn't clear - you are absolutely correct. Authorizations
  are only reused within a subscriber account.

  tialaramex: If account A asks to create an authz for example.com, succeeds in validating
  it, and then account B comes along and wants an authz for example.com too, that should
  result in a fresh authz regardless of this setting.

  Correct. Account B's request would result in a fresh authz in pending state.

It's fine for multiple different servers with different account_keys to be able to each independently validate a domain and get their own unique authz tokens, but one server with account_key A must not be able to piggyback off of another server's authz done under account_key B.

Since, remember, it is trivial for anyone to get a new account_key, there is absolutely no validation that occurs to setup a new account key for a given domain. This is why I don't understand the purpose behind the account_key in the first place.

[1] - https://community.letsencrypt.org/t/upcoming-change-valid-au...