[SOLVED] LetsEncrypt Certificate Restored from "FBX Backup" Cant be Renewed

Support
1

FBX Version: Debian GNU/Linux 12 (bookworm) and FreedomBox version 23.20. FreedomBox is up to date.
SBC: Raspbi-4B
Installation Image From: FBX website for the Raspi-4B

I’m using a number of domains on my FBX. Recently, I had to do a fresh install and restored all my backups (including certificates) from an external disk I had been using.

It’s great to get your certificates restored; this way you dont have to jump through hoops to reconfigure your other devices and clients. However, something is troubling me.

Now that my certificates are restored and not obtained through the long plinth->configure route, I cant seem to renew any of them. A dry run of certbot renew works just fine but plinth throws me the following error. I can live with it, but if anyone is interested in solving, reporting or helping on this, I’d much appreciate.

/usr/share/plinth/actions/actions
Go to plinth.service
Error executing action: Error obtaining certificate: Saving debug log to /var/log/letsencrypt/letsencrypt.log
Missing command line flag or config entry for this setting:
Please choose an account
Choices: ['local.my_site.com@2023-11-15T16:56:17Z (9565)', 'local.my_site.com@2023-06-12T18:43:26Z (9fca)']
Ask for help or search for solutions at https://community.letsencrypt.org. See the logfile /var/log/letsencrypt/letsencrypt.log or re-run Certbot with -v for more details.
Traceback (most recent call last):
  File "/usr/share/plinth/actions/actions", line 93, in _call
    return_values = func(*arguments['args'], **arguments['kwargs'])
                    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/lib/python3/dist-packages/plinth/modules/letsencrypt/privileged.py", line 171, in obtain
    raise RuntimeError('Error obtaining certificate: {error}'.format(
RuntimeError: Error obtaining certificate: Saving debug log to /var/log/letsencrypt/letsencrypt.log
Missing command line flag or config entry for this setting:
Please choose an account
Choices: ['local.my_site.com@2023-11-15T16:56:17Z (9565)', 'local.my_site.com@2023-06-12T18:43:26Z (9fca)']
Ask for help or search for solutions at https://community.letsencrypt.org. See the logfile /var/log/letsencrypt/letsencrypt.log or re-run Certbot with -v for more details.

Thanks.

2

Check your plinth system configuration app.

Hostname: name of your FB without domain.

Hostname: freedom box

Domain name: fully qualified name of your freedombox.

Domain name: freedombox.freedombox.rocks

Do you have it like this? I found the guidance on the domain name field to be a bit misleading, but this is how it is running for me.

1 Like
3

It looks like there are 2 different accounts available in the Let’s Encrypt configuration on disk, and certbot can’t decide which one to use. Look in /etc/letsencrypt/accounts/acme-v02.api.letsencrypt.org/directory/ to see if this is the case.

2 Likes
4

Yep - the directory was holding 2 accounts for the same domain.
I didnt know which to go with but decided to remove the one with the prior time-stamp.
Reason being;

It’s interesting how this happened. I cant reproduce it but my guess is, on initial installation I directly configured my domain and other settings before restoring back-ups. I guess after I configured my domain, the certificates being restore created a duplicate.

If tested and this is true, it might be a good idea to have FBX check the existing domain certificate before restoring - just in case they’re for the same domain.

Thanks @jvalleroy - your lead solved my problem.

1 Like