List of authorized accounts


#1

Especially in the early days of Let’s Encrypt I was playing around with different ACME clients. I tried to re-use / import my account key whenever possible, but I’m not sure if this actually worked correctly. Now I’m wondering whether there might be multiple accounts authorized to issue certificates for my domain(s).

So, in essence I have these questions:

  • Is it possible to have multiple accounts authorized for the same domain(s)? Or is only the last activated account kept active?
  • Is there a way to list all accounts / contact details that are currently authorized to issue an certificate for a particular domain (given that I have at least one valid private key for such an account)?
  • Is there a way to list all accounts with a given mail address? This will probably not be possible due to privacy concerns.

#2

Hi @kbabioch

first: A Letsecnrypt - account has an account-url (something like https://acme-v02.api.letsencrypt.org/acme/acct/35657966 ) and an associated public-private key pair. The mail address is an additional property - but not really relevant. Different accounts can use the same mail address. But never the same account url or the same public / private key pair.

An account can create a new order with a domain name. If the challenge is done, then this account can get a certificate. But the certificate has no information about the account.

So:

Yes, it’s possible. But you can restrict that via CAA-Entry.

server-daten.de 0 issue letsencrypt.org; accounturi=https://acme-v02.api.letsencrypt.org/acme/acct/35657966

restricts certificates with this domain name to Letsencrypt and my account. That information is public visible (via CAA query).

If I know it correct, such a list doesn’t exist. “Fire and forget” - you can use Transparency Logs to find certificates, but there are no account informations.

No. An account owner can get the account informations (date created, mail address). But there is no reverse search.


#3

Hi @JuergenAuer,

thank you very much for your detailed response.

I know this already, I was more thinking about the authorization aspect. Obviously this is not something that will be put into the issued certificate, but still is something that the ACME server has to keep track of.

Okay, but as you’ve said this is publicly visible. Also it requires the issuing bot to honor those records. I don’t think this is much of a problem in reality, but still this feels kind of soft protection. I would prefer to be able to definitely revoke / inactivate an account.

For me this whole account aspect seems to be broken then. All clients encourage new account creation / registration and there is no real standard to export and re-use those private account keys. Hence, in reality most people will create multiple accounts for the same domain. Once you loose track of one particular key pair, you are no longer able to deactivate this account, although you are still in possession of (multiple) other accounts that are authorized to issue certificates for a particular domain.

To my understanding this is also a problem with domain transers. Unless the old domain holder de-activates his account (which I cannot really verify as an outsider), he might still be able to issue certificates for the domain he no longer has control over.

Shouldn’t it be possible to lock out any old accounts with a newly created / registered account, so that only this one account is able to issue certificates? Or am I misunderstanding something completely here?


#4

You can deactivate your own account if you have the private key and if your client supports that ACME-command.

7.3.6. Account Deactivation

https://tools.ietf.org/html/draft-ietf-acme-acme-15#section-7.3.6

But you cannot deactivate an account of another user, who was the older domain owner of your domain.

This isn’t a problem. They can create a lot of accounts. But one account hasn’t the right to create a certificate with a special domain name. So there is no direct relation between account and domain. Only between account and validated domain.

If I buy a commercial certificate (valide 1 oder 2 years), I can sell the domain - and I have a valid certificate. Letsencrypt certificates are only 90 days valide.

Yes, 30 days. I don’t think this is really a problem. If someone sells a domain and see, that there are older Letsencrypt - certificates, he should wait 30 days -> then the problem is solved.

There is no association between two accounts. And there is no relation between an account and domains. So this is impossible.

Yes, I think so. To get a certificate, you have to prove your ownership, that you are able to manage this domain name. If you can’t -> you don’t get a certificate. Your prove is only 30 days valide, your certificate only 90 days. So you have to do this again and again.


#5

Yes, I know about this, but but this does not take into account key loss, etc.

The relation is the authorization, which allows the owner of an account to issue certificates for any domain that he has proven ownership for.

True.

Ok, that’s the missing and important part to the puzzle. Is this somewhere documented. I couldn’t find this in the ACME specification itself (obviously), so how do I know the current renewal policy for Let’s Encrypt? What would be the keyword I’m looking for? Because I was able to re-issue a certificate for own of my domains without any additional proof (although I’m within the 30 days that we are talking about here).

Does this mean that an account that hasn’t been used to issue certificates for more than thirty days can not issue any other certificate without providing some proof of ownership? Once again, where is this documented :-)?.


#6

I could find some reference to this in the FAQ: https://letsencrypt.org/docs/faq/

I successfully renewed a certificate but validation didn’t happen this time - how is that possible?

Once you successfully complete the challenges for a domain, the resulting authorization is cached for your account to use again later. Cached authorizations last for 30 days from the time of validation. If the certificate you requested has all of the necessary authorizations cached then validation will not happen again until the relevant cached authorizations expire.


#7

Yes. This account can create a new order (I can create a new order for google.com, letsencrypt.org etc.), but this account can’t validate the ownership of this domain. So it’s stupid to create such an order.

The challenge requires write access to the webserver (http-01 - validation) or write access to the dns-settings. And if I can change the dns-settings of Google or Letsencrypt, the wrong certificate is the smallest problem :wink:

Yep, this is it. These two time spans (90 days valide and 30 days caching) are not part of the specification.

Letsencrypt doesn’t support Pre-Authorization

https://tools.ietf.org/html/draft-ietf-acme-acme-15#section-7.4.1

But (Authorization):

7.5.1. Responding to Challenges

https://tools.ietf.org/html/draft-ietf-acme-acme-15#section-7.5.1

If the final state is “valid”, then the server MUST include an “expires” field.

But there is no specification if this “expires” field has a date 1 day, 7 days or 30 days later.


#8

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.