[pfg]

Revocation is also possible using the certificate's private key, but I agree that the risk of keeping the account key is not worth the hassle of deleting it straight away. As it stands, authorizations are valid as long as certificates, so the worst case is you're compromised on the 89th day of validity and get another certificate valid for the next 90 days. Soon, that'll be ~7 days, so even less of a concern.

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

[lightedman]

"Soon, that'll be ~7 days, so even less of a concern."

If you aren't authorizing and revoking immediately after delivering data, you're doing it wrong and opening yourself up to attack.

Source: Four penny auction websites using the same code were compromised by me (at their request - hired hacker.) I took their entire auction winnings after they gave me authorization to test their systems. It took me less than 20 minutes.

I walked away with $300,000 because in my contract I told them I keep whatever I compromise and steal. They agreed.

If you can't handle rapid token usage/generation, don't even bother using tokens. Token revocation is one of the harder things out there to get done properly. You're better off with a challenge/auth EVERY SINGLE REQUEST at the expense of page loading times.

[pfg]

Again, this isn't about tokens. We're talking about a private account key (like, an actual RSA or ECC key), which is associated with FQDNs for which the holder of an account key has the ability to issue certificates.

I'll try to phrase this as an example: Let's say you run an online store for music downloads. One implementation might be to send the user an email with a download link, identified by a token. In this case, it would make sense for this token to expire after the user successfully downloaded the file, and doing otherwise would probably be bad for your business. On the other hand, if your online store involves a login process you need to complete before you can actually download the file (the file being the domain authorization in this example), that's fine and you might not want to limit the user to one download.