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…
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).
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?
well apparently it was created on another machine? 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?
But perhaps someone with deeper knowledge of these things can agree or disagree with me on this subject.
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!
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.)
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
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.