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 lhsouthbury.com and gave it a fresh new ssl cert.
I decided to do a dry run to make sure the cert will renew correctly.
output: Saving debug log to /var/log/letsencrypt/letsencrypt.log Plugins selected: Authenticator webroot, Installer None Account at /etc/letsencrypt/accounts/acme-staging.api.letsencrypt.org/directory/f74a9bad0648afe4f8e9395762eeec44 does not exist
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).
I ran sudo grep -R "acme-staging\." /etc/letsencrypt but no output
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.
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.
edit:
I updated your command to reflect your configuration file.
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?
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/acme-v01.api.letsencrypt.org/directory/f74a9bad0648afe4f8e9395762eeec44/.
When you do --dry-run while forcing a specific account ID, it tries to look up /etc/letsencrypt/account/acme-staging.api.letsencrypt.org/directory/f74a9bad0648afe4f8e9395762eeec44/, and when it doesn't find it, it predictably errors out.
That's not good. Let us know when you see the state so we can take a look.
