[dc352]

So do you imply that the account key is created from scratch for every new certificate?

Why we were surprised (and we don't say the implementation is necessarily wrong!) is that I can use the account key anywhere. If the genuine user keeps refreshing authz's, it will keep the stolen account key operational as well.

That's my understanding. I may be wrong, but if so, I don't quite yet understand the logic behind authz.

[pfg]

No, account keys are typically persisted and re-used, though specifics depend on the client implementation. I still think this is largely a non-issue. If you compromise the target system, you can just keep stealing private keys as they are being renewed. This would even decrease the chances of being detected, because using the stolen account key to issue new certificates would lead to those certificates popping up on various Certificate Transparency log servers, which might be noticed by the domain owner. You're already in a game-over scenario if you don't detect the compromise, the account key doesn't make things significantly worse.

Think of it like the credentials for a hosting provider where you bought your traditional SSL certificate being stolen. Not really a new threat.

[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...