Account ids mismatch

I ran this command: ./certbot-auto certonly --webroot -w /var/www/html/ -d www.xxx.com --account 95153

It produced this output: AccountStorageError: Account ids mismatch (expected: 95153, found: 1a8788f6a949221114dd75b7ac6d96d

My operating system is (include version): Ubuntu 14.04

I can’t seem to find any information regarding this error anywhere. I have manually created meta.json, private_key.json and regr.json using the correct format…

Thanks in advance

Hi @pgar,

I can’t say that I’ve seen that error before either.

@erica - Do you have any guesses about what could be causing this?

Wait, where did you get an account with ID 95153? The Let’s Encrypt CA wouldn’t have given you such an account! Or, why did you choose to specify --account 95153 as part of your command line?

--account refers to your account on the Let’s Encrypt CA which is issued to you when you register with the CA (automatically in the course of getting your first certificate, or manually via something like certbot register).

I thought the acccount ID is the number at the end of registrationURI https://acme-v01.api.letsencrypt.org/acme/reg/1234567

however using certbot apparently is something else. I havent initially created this account on this machine so certbot did not create the directory. I have to create it manually.

Shall I assume that the correct account ID which the directory needs to be named after, is the one I get in the error message?

Account ids mismatch (expected: 95153, found: 1a8788f6a949221114dd75b7ac6d96d

I cant find that anywhere on the system so I assume its a response from letsencrypt

Unless I have confused the account directory name with the account id in regr.json. What needs to be what?

Just for my curiousity, where did it come from? :slight_smile:

well apparently it was created on another machine? :slight_smile: now I need to create a certificate for a domain which is on another machine but is under the same account. So I have manually added the account information on to the second machine.

If I read the code in account.py correctly, it takes account_id from the directory name and compares it with the account ID from the JSON files… And produces an error if it doesn’t match, including what it should be…

So safe to say you can rename the directory in /etc/letsencrypt/accounts/ to the name certbot found for you in the JSON files? I guess? :stuck_out_tongue:

But perhaps someone with deeper knowledge of these things can agree or disagree with me on this subject.

Ah, I understand. The JSON files themselves don’t have the account ID embedded in them, the code just calculates the account ID from information in the JSON files (just the public key to be exact):

    self.id = hashlib.md5(
        self.key.key.public_key().public_bytes(
            encoding=serialization.Encoding.PEM,
            format=serialization.PublicFormat.SubjectPublicKeyInfo)
    ).hexdigest()

And it checks this hash with the found account ID (i.e., the name of the directory).

So the account id is the MD5 hash of the public key?

but according to the documentation the account_id is part of the registrationURI which is included in the regr.json

You shouldn’t have to do anything with accounts. Why do you need to?

You can have multiple “accounts” issue certificates for the same domain.

When you install Certbot on a machine, it will automatically create everything necessary (prompting you to agree to the terms of service, optionally give your email address, etc.) when first needed. (That’s how you got your first account, after all.)

The simplest thing to do is to let Certbot manage things automatically, giving you one account per machine. The next-simplest thing to do when migrating between servers is to copy /etc/letsencrypt from the old one to the new one (perhaps with rsync -a or something) and continue letting Certbot manage things.

I wanted to use that specific account to avoid “too many certificates already issued for this domain” error which I kept getting for 2 weeks straight whereas systems using the account which the domain is under, were able to get new certificates during these two weeks.

Update: I have renamed the directory to the hash the error was giving me, then removed the --account from the command and it miraculously worked! :slight_smile:

1 Like

The “per domain” rate limits are applied regardless of account, unless possibly you’ve applied for a specific rate limit exemption. (Which requires filling out a form.)

2 Likes

The current ACME draft (which actually is speaking of “new-reg” as wel as “new-account”, very confusing…?), doesn’t speak of an “account ID”, it only speaks of an “account URI”, which contains a number… Is that the ACME idea of an “account ID”? Perhaps.

But in any case, that ID is apparently different from the idea certbot has about what an account ID is… Perhaps certbot devvers were afraid of collisions in the account directory? I dunno…

Any mentions of "registration" instead of "account" are errata from the change in terminology - can you file an issue or a PR with a fix? The perils of a pre-RFC status draft :slight_smile:

From the ACME perspective yes (As I understand), your account is identified by its URI and there's no prescription about whether that URI needs to have a numeric ID component or not. Implementations may vary.

I was just about to! See IRC :stuck_out_tongue:

1 Like

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