Site secured but dry run is telling me the account does not exist

We recently did a server migration and have had to issue a new cert for this domain a few times, not sure why it keeps disappearing. Did not notice the problem until today, so I don't have any notes or theories as to why it keeps going missing (or how many times). Will start keeping tabs from here on out though!

I ran certbot-auto delete and removed everything related to and gave it a fresh new ssl cert.

I decided to do a dry run to make sure the cert will renew correctly.

/root/certbot/certbot-auto certonly -n --keep -c --dry-run

Saving debug log to /var/log/letsencrypt/letsencrypt.log
Plugins selected: Authenticator webroot, Installer None
Account at /etc/letsencrypt/accounts/ does not exist

I checked my letsencrypt accounts and I don't see anything named

The only dirs I do see are:

Our letsencrypt was originally setup by someone else, so I am not sure how to go about correcting this. Any ideas?

certbot 1.8.0

Ubuntu 18.04.4 LTS

I am able to SSH into my machine

1 Like

That is quite bizarre. is the old legacy ACMEv1 staging server. Certbot shouldn't be trying to use it.

Does this show anything?

sudo grep -R "acme-staging\." /etc/letsencrypt

Did you copy the /etc/letsencrypt files from the old server to the new server?

Or did you start from scratch?


Welcome to the Let's Encrypt Community :slightly_smiling_face:

Let's see... :thinking:

:astonished: That's not good. Let us know when you see the state so we can take a look.

What says certbot-auto certificates?

I see you got your certificate today:

1 Like

Where does that ini file come from? Does it contain any reference to the old staging server like @_az mentioned? Or perhaps the account?



Your redirects could use some help (301 good, 302 bad).

@_az, @Osiris

This would be a case for purging the old certbot installs and account information, no? Then generating a new certificate just to set the configuration for renewal?


I've never seen it used before, but it does exist in the nether reaches of the current certbot documentation.

Configuration file

Certbot accepts a global configuration file that applies its options to all invocations of Certbot. Certificate specific configuration choices should be set in the .conf files that can be found in /etc/letsencrypt/renewal.

By default no cli.ini file is created (though it may exist already if you installed Certbot via a package manager, for instance). After creating one it is possible to specify the location of this configuration file with certbot --config cli.ini (or shorter -c cli.ini).


Your updated command would look something like this:

/root/certbot/certbot-auto certonly --cert-name -a webroot -w /ebs/files/www/0000_DEFAULT/public/ -d, --email --keep

To clean up your certbots, look into the snap install on the reference that follows. In particular, consider step 3.


I ran sudo grep -R "acme-staging\." /etc/letsencrypt but no output :frowning:

We copied everything from the old server to the new server (moved the aws volume to an upgraded server). The symlinks for the dirs in /etc/letsencrypt/live pointing to archive did not preserve during the migration, so far this is the only thing we fixed/changed.

1 Like

rsa-key-size = 4096
email =
domains =,
text = True
authenticator = webroot
webroot-path = /ebs/files/www/0000_DEFAULT/public/
agree-tos = True
account = f74a9bad0648afe4f8e9395762eeec44

1 Like

It looks like you had some old fragments of the ACME v1 api. I recommend that you purge your old certbot versions per the instructions in step 3 and use the new command I gave you. It will create a new certificate configuration file.

I updated your command to reflect your configuration file. :slightly_smiling_face:

1 Like

Thanks! Really stoked to already be receiving so much help :sunglasses:

after running certbot-auto certificates, here is the output:

Certificate Name:
Serial Number: 4c35e364485c0093012de91b308db2c0be1
Expiry Date: 2020-12-24 18:59:05+00:00 (VALID: 89 days)
Certificate Path: /etc/letsencrypt/live/
Private Key Path: /etc/letsencrypt/live/

Looks correct...

I'll have to look into the redirects, I had no idea.


Looking good so far. :slightly_smiling_face:

Do me a favor:

certbot-auto --version

certbot 1.8.0

Thank you for the updated command. I will give that a go.

1 Like

The new command will probably create a new ACME account for you since your old one referenced a missing account in your .cli file.

You might have multiple versions of certbot-auto installed, which will give us headaches.

1 Like

Using Certbot by specifying renewal parameters in an .ini file via -c is pretty peculiar. That's typically not how things are done - Certbot is capable of remembering your certificate parameters on its own.

Your problem comes down to that account line right there. Get rid of it, and allow Certbot to figure out the correct account IDs on its own.

To give a technical explanation: your --dry-run and live accounts are different. Totally different account IDs. When you try to do a --dry-run while forcing your production account ID, it's going to complain that the account/server combination doesn't exist.



Is there any chance @donottaptheglass may have multiple certbots installed? Where did the v1 api come in? I saw the account in the .cli file, but no reference to the v1 staging. That's either hardcoded or in a reference somewhere, right?

Anybody who has been running Certbot for a long time will have ACMEv1 accounts lying around.

Certbot was slowly adapted to automatically migrate everybody to ACMEv2, even if ACMEv1 accounts are still referenced in the renewal parameters.

In this case, the presence of account in the .ini. file caused problems with --dry-run specifically.


So certbot knows it's a v1 account by... its format... or ?

I guess what I'm asking is: How did the latest version of certbot know to look here for the account (if indeed the latest version is being invoked by /root/certbot/certbot-auto):

The f74a9bad0648afe4f8e9395762eeec44 just matches the directory name in /etc/letsencrypt/account/

When you do --dry-run while forcing a specific account ID, it tries to look up /etc/letsencrypt/account/, and when it doesn't find it, it predictably errors out.


But why did it look under the old staging directory as opposed to the new staging directory?

Is the folder above symlinked to the following, maybe?

I'm just wanting to know how it ticks. :slightly_smiling_face:

There is some logic for account re-use between ACMEv1 and ACMEv2, including the creation of symlinks between them. It will check one and the other.

If OP got that error message, it means that account ID does not exist in either ACMEv1 staging or ACMEv2 staging.

Which is indeed the case, that account ID is their production account ID.