Parsing renewal configurations from older certbot versions

Help
1

EDIT: I've just realised that the newer server actually has a much older version of certbot. I'm installing a newer one now which will probably solve the issue.

EDIT2: that did indeed solve the problem. Sorry to have wasted your time.

Orginal post:

My domain is: refsec.org

I ran this command:

sudo certbot certonly --manual --preferred-challenges=dns --email steve@xxxxxxx.co.uk --server https://acme-v02.api.letsencrypt.org/directory --agree-tos --manual-public-ip-logging-ok -d "refsec.org" -d "*.refsec.org"

It produced this output:

Are you trying to change the key type of the certificate named refsec.org from ECDSA to RSA? Please provide both --cert-name and --key-type on the command line to confirm the change you are trying to make.

My web server is (include version): Passenger Standalone (Nginx)

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

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): 1.21.0

Also possibly relevent is this line in the debog log:

Attempting to parse the version 2.11.0 renewal configuration file found at /etc/letsencrypt/renewal/refsec.org.conf with version 1.21.0 of Certbot. This might not work.

I've moved a rails app to a newer server which clearly has a more recent version of certbot than the old one. I tarred up the entire /etc/letsencrypt directory and moved it en masse to to new server - hence the older config versions. The command line I used is identical to the one I've used many times succesfully on the old server.

The config file has "key_type = ecdsa" in it and I am not trying to change to rsa.

Can I just zap the renewal configs?

1 Like
2

Please @Trip never just delete / erase when debugging. Back it up, as needing some or all the information is often still needed.

2 Likes
3

Adding on to Bruce's comment ... you should not manually modify any files in Certbot's folder tree. Those files are interconnected and manual changes can easily damage that leaving a broken Certbot system.

2 Likes
4

Rather than editing your initial post, @Trip, it is preferable to make a reply with your solution so that it can be marked as such. The orignal poat cannot be marked as the solution.

4 Likes
5

I had failed to notice that the "new" server actually had an older version of certbot, not newer. Installing the newest version using snap fixed the problem

3 Likes
6

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