What is an "Account?"

I'm trying to better understand the concept of an 'account' in the context of Let's Encrypt.

For some background, I'm using the non-CLI edition of the Certes API (link: GitHub - fszlin/certes: A client implementation for the Automated Certificate Management Environment (ACME) protocol). I'm authoring using VB.NET.

Using Certes, there are essentially two ways to start an ACME request: one by using an existing account and the other by creating a new one:


Dim accountKey = KeyFactory.FromPem(pemKey)
Dim acme = new AcmeContext(WellKnownServers.LetsEncryptStagingV2, accountKey)
Dim account = await acme.Account()


Dim acme = new AcmeContext(WellKnownServers.LetsEncryptStagingV2)
Dim account = await acme.NewAccount("admin@example.com", true)

' Save the account key for later use
Dim pemKey = acme.AccountKey.ToPem()

To be clear, my question today is not about how to use Certes. I've got that covered. My question is about 'accounts' in Let's Encrypt. What are they?

Follow me for a moment. An apparent oversight in the Certes documentation is the absence of any discussion surrounding how to get the pemKey in the first place for an existing account. For example, I've been using a different ACME client successfully for years (this is merely my first foray into doing it with my own code). I simply don't have that key. And I've always used the same email address.

Using Certes, I first thought to reference my existing account by using the PEM as exported from my website manually via my browser. I used the 'Existing' code from above. This resulted in errors, somewhat expected since that PEM is a public key only.

So, scratching my head about where to get that account-identifying private key for my first Certes run, I gave it a shot with the 'New' code. Much to my surprise, it worked. Even in production. I have a valid wildcard cert in my happy hands. And a private key for the new account.

But this is odd. I would have expected that request to fail, given that I've been using that same email address for all these years with that other ACME client.

Do the ACME servers not use email addresses as unique identifiers for accounts? If not, and since I apparently can create a new 'account' for each new renewal request, even using the same email address, then what is the purpose of an 'account' in the first place?

Inquiring minds want to know.

it's allowed an acme account without attaching an email at all (--register-unsafely-without-emailoption of certbot), contact email of account is mostly renewl notifier or notice when API update affects you


Aha. So the email address is tied to the life of the issued cert.

Would that be a correct way of looking at it?

Accounts may have special Rate Limits (if requested and approved) and may indicate whether you are white-listed for ECDSA chains.

There may be other factors I can't recall at the moment

More info on Rate Limits:


No. You can change the email associated with an account at any time. Of course, this must be supported by your ACME Client :slight_smile:


I see. That helps, thanks.

So it sounds like I should be OK, in my app, to create a new account if I don't have the private key PEM, and then store that PEM for use in subsequent renewals for the domain in question.

Would you agree?

1 Like

you can request multiple certificates from single account (for example entire hostling provider using Cpanel likely have single account for that panel


You can change the email associated with an account at any time


Bottom line, it seems we can have multiple accounts with the same email address. Fair 'nuff. Is there a way to get an account's private key if one doesn't have it?

You can make a new private key or reuse it as you wish. It is not permanently paired to the account.

Certbot, for example, has these options for the private key (other ACME clients have similar)

--reuse-key When renewing, use the same private key as the
existing certificate. (default: False)
--no-reuse-key When renewing, do not use the same private key as the
existing certificate. Not reusing private keys is the
default behavior of Certbot. This option may be used
to unset --reuse-key on an existing certificate.
(default: False)
--new-key When renewing or replacing a certificate, generate a
new private key, even if --reuse-key is set on the
existing certificate. Combining --new-key and --reuse-
key will result in the private key being replaced and
then reused in future renewals. (default: False)

1 Like

no, it never given to the acme server at all


Are the account private key and the certificate private key one and the same?

If not, how does one go about getting the account private key if one doesn't have it and wants to generate certs using it?

I believe you must be referring to the certificate private key here, not the account private key. They are different things, aren't they?

They are separate keys. No, if you’ve lost the private key for an ACME account (which we usually call a “registration” internally), the account can no longer be used. But as you’ve discovered, you can just start using a new account. The only thing you’ll lose is any rate limit adjustment, but these are rare (you’d know if you had requested one).


Bingo. That clears it up perfectly.


1 Like

Certes is just an implementation of an ACME client (library). Here is the ACME spec which explains every ACME concept: RFC 8555: Automatic Certificate Management Environment (ACME)


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