Certbot 2.9.0 on Unbuntu 22.04.01 Won't Renew

Help
1

The cert is actually for 4 domains (and I have two others as well -- all get the same errors). My situation is that our web server hardware failed, so I got new hardware, installed a new, clean Ubuntu 22.04.01 (the dead system was running 18.04.01) and transferred as much as possible from the old to the new. Everything (including my certificates) was working. Unfortunately, I cannot say what version of certbot was running on the dead machine.

Running sudo certbot renew --dry-run does not produce any errors or diagnostics and in fact, reports success.

I don't know if this is useful, but:

me@www:~$ sudo ls -l /etc/letsencrypt/accounts
total 8
drwx------ 3 root root 4096 Oct 18 08:06 acme-staging-v02.api.letsencrypt.org
drwx------ 3 root root 4096 Sep 13 10:07 acme-v02.api.letsencrypt.org

So I can see why it doesn't find any acme-v01 directories, since none exist. I do not understand why the dry run succeeds -- it would seem to me that the entire purpose of the dry run is to detect and help correct issues like this before trying for real.

Can anyone help me? Our web sites are inaccessible until I get this fixed.

My domain is: bugs.electronicvisions.com

I ran this command: sudo certbot renew -v

It produced this output:

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Processing /etc/letsencrypt/renewal/bugs.electronicvisions.com.conf
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Certificate is due for renewal, auto-renewing...
Plugins selected: Authenticator apache, Installer None
Failed to renew certificate bugs.electronicvisions.com with error: Account at /etc/letsencrypt/accounts/acme-v01.api.letsencrypt.org/directory/eb4c25cfca709f93859e44c91e35ea28 does not exist

My web server is (include version): Apache/2.4.58 (Ubuntu)

The operating system my web server runs on is (include version): Ubuntu 22.04.1

My hosting provider, if applicable, is: self

I can login to a root shell on my machine (yes or no, or I don't know): yes

I'm using a control panel to manage my site (no, or provide the name and version of the control panel): no

The version of my client is (e.g. output of certbot --version or certbot-auto --version if you're using Certbot): 2.9.0

2

OK, I think I caused this by copying a bit too much from the old system. The automatically generated folder name eb4c25cfca709f93859e44c91e35ea28 did not exist but there was a folder with a different name. I copied the existing folder to one with the new name and the renewal worked flawlessly.

This still doesn't explain to me why the dry run reports complete success. That is VERY frustrating for people like me who rarely need to interact with these tools.

3

And none should. ACME V1 was obsoleted long ago.

That is the purpose but the LE Staging system (which --dry-run uses) has a different account. For some reason when using LE production the wrong account is used.

Would you post contents of this file? I have a feeling the account that renewal conf relates to does not exist. Perhaps as a quirk in your migration to the new machine. And, then the error message is just poor.

We may just have to delete and re-issue that cert rather than trying renew.

Why is that? Because I see this domain fine with a cert from today

4 Likes
4

try rerun certbot renew with --server https://acme-v02.api.letsencrypt.org/directory option, so certbot make a new account for renewal

3 Likes
5

@MikeMcQ Here's the .conf file content you requested:

# renew_before_expiry = 30 days
version = 2.9.0
archive_dir = /etc/letsencrypt/archive/bugs.electronicvisions.com
cert = /etc/letsencrypt/live/bugs.electronicvisions.com/cert.pem
privkey = /etc/letsencrypt/live/bugs.electronicvisions.com/privkey.pem
chain = /etc/letsencrypt/live/bugs.electronicvisions.com/chain.pem
fullchain = /etc/letsencrypt/live/bugs.electronicvisions.com/fullchain.pem

# Options used in the renewal process
[renewalparams]
account = 9114fd3ab1902c62d312824eb91b2b39
authenticator = apache
server = https://acme-v02.api.letsencrypt.org/directory
key_type = rsa

With my limited understanding, I don't see anything that references acme-v01, so I will remain confused about why it is trying to use that and not complaining about the missing acme-v02 account.

HOWEVER... as I stated in my follow-up message, I resolved the issue by changing the name of the account folder that was created on the new system to the name referenced in the .conf files from the old system and everything is working perfectly again.

  • So I don't need a new account, now that I am referencing my correct account.
  • You were able to access the site because I had already resolved the issue (and posted my follow-up) before you responded (without reading the follow-up/resolution)
  • I still don't understand why the dry run succeeded with the wrong account and I likely never will. As I see it, if dry run is using a "special" account then it isn't really testing an actual renewal. I had naively assumed that a dry run was done in cooperation with the sever rather than without the server's knowledge.

But... thanks for your interest and your suggestions.

1 Like
6

I think it is just leftover code in Certbot from V1 days. It looked for V2 account, did not find it, tried to find a V1 account and reported that missing. That was needed during the V1 to V2 transition but should probably be removed now. I doubt the Certbot devs would put high priority on that though given the rare conditions needed to cause it.

No, it wouldn't test getting a production cert. It tests the mechanism and infrastructure by which you obtain one (comms, challenge methods, ...). The Staging system is extremely useful. Yours was a rare situation caused by your backup / recovery technique.

You can read more about the purpose of staging system below. Perhaps that will help

In any case, I am glad your system is now working.

2 Likes
7

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