The following renewal configurations were invalid

Help
1

On centos8.1 I’ve installed certbot using the method explained at https://www.tecmint.com/secure-nginx-with-lets-encrypt-on-centos-8/ so not sure if that’s the right way to install it, anyway, i’ve installed some certificates but when i try to gather info about them I’ll get:

# certbot-auto certificates
Saving debug log to /var/log/letsencrypt/letsencrypt.log
Renewal configuration file /etc/letsencrypt/renewal/bpl.expert.conf produced an unexpected error: expected /etc/letsencrypt/live/bpl.expert/cert.pem to be a symlink. Skipping.

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

The following renewal configurations were invalid:
  /etc/letsencrypt/renewal/bpl.expert.conf
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

So, what does this error mean? And also… I see many of the threads people referring to certbot but here certbot is not available and I’m using certbot-auto instead… Could you please clarify?

Thanks in advance.

2

The file /etc/letsencrypt/live/bpl.expert/cert.pem, generated by certbot itself, should be a symbolic link to the most recent certificate file in /etc/letsencrypt/archive/bpl.expert/. It seems that this is not the case, most probably due to manual tampering (certbot itself would never put anything else than a symbolic link in the /live/ directory).

certbot-auto is a wrapper script for the certbot ACME client for Linux distributions without a certbot package in their distributions package list. It also has the added feature of upgrading certbot to the most recent version available, whereas distribution packages are often rather old and not updated that often.

CentOS 8 however does have certbot as a package. The official guide for certbot on CentOS 8 with nginx can be found here: https://certbot.eff.org/lets-encrypt/centosrhel8-nginx

But if your certbot-auto is working perfectly, I wouldn't recommend changing. Could break more than it would fix.

1 Like
3

Oh, ok, thanks for the explanation... I wonder at which point the manual tampering was produced... I use winscp to sync files to local... maybe at certain point this was the guilty one? In any case, how could i fix it in order to get the relevant certbot-auto certificates info?

Or said otherwise, how should i proceed in my current state? Isn't there any way to "reset to default" and start from scratch?

But if your certbot-auto is working perfectly, I wouldn’t recommend changing. Could break more than it would fix.

Well, until now it was working ok... i've only run it once and certainly made the necessary changes on the nginx files to give ssl support but now I want to add more domains or even getting information out of it seems things are getting messier... :slight_smile:

4

You could try running certbot-auto update_symlinks

5

You could try running certbot-auto update_symlinks

Ok, thanks, I'll do

But if your certbot-auto is working perfectly, I wouldn’t recommend changing. Could break more than it would fix.

I've been reading that official guide and I definitely would like to follow those steps so I'll be in a "official state"... so support will be easier but as you said, maybe it'll break things... how would you uninstall the current one and upgrade to the official one without breaking anything?

6

About that, here's what I've tried:

[root@local1 ~]# certbot-auto update_symlinks
Saving debug log to /var/log/letsencrypt/letsencrypt.log
Expected /etc/letsencrypt/live/bpl.expert/cert.pem to be a symlink
[root@local1 ~]# certbot-auto certificates
Saving debug log to /var/log/letsencrypt/letsencrypt.log
Renewal configuration file /etc/letsencrypt/renewal/bpl.expert.conf produced an unexpected error: expected /etc/letsencrypt/live/bpl.expert/cert.pem to be a symlink. Skipping.

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

The following renewal configurations were invalid:
  /etc/letsencrypt/renewal/bpl.expert.conf
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
[root@local1 ~]# sudo certbot-auto update_symlinks
sudo: certbot-auto: command not found
7

It seems certbot needs a working renewal configuration files including working symbolic links for update_symlinks to work.

What is the output of ls -l /etc/letsencrypt/live/bpl.expert/ ?

8

Here's the whole /etc/letsencrypt tree:

showcase
showcase1314×614 19.8 KB

And just in case that's not enough information, here's the ls -l output:

[root@local1 ~]# ls -l /etc/letsencrypt/live/bpl.expert/
total 20
-rw-r--r--. 1 root root 2037 May  9 19:59 cert.pem
-rw-r--r--. 1 root root 1647 May  9 19:59 chain.pem
-rw-r--r--. 1 root root 3684 May  9 19:59 fullchain.pem
-rw-r--r--. 1 root root 1704 May  9 19:59 privkey.pem
-rw-r--r--. 1 root root  692 May  9 19:59 README
9

OK, looks like something managed to put the actual files in /live/ in stead of the symbolic links. You can fix that by updating the actual files from /live/ to symbolic links to the files in /archive/:

cd /etc/letsencrypt/live/bpl.expert/
for name in cert chain fullchain privkey; do ln -sf ../../archive/bpl.expert/${name}1.pem ${name}.pem; done
2 Likes
10

Wow, that was a really good advice :smiley: . Thanks!

Now certbot-auto certificates works wonderfurly and it’s showing me the info from all domains i’ve installed certificates for few days ago. Anyway, before proceeding any further, do you think it’d be possible to uninstall the current certbot-auto I’ve installed following the unofficial way from https://www.tecmint.com/secure-nginx-with-lets-encrypt-on-centos-8/ and installing it from the official packages as recommended few threads ago (at that time i wasn’t even aware such package were available for centos) without breaking anything?

But if it’s that’s not just possible, what’d be the next steps for me to add the new domain names set?

11

Both packages (certbot-auto and certbot from the official distribution package) should use the same files in /etc/letsencrypt/. I don't have experience with the certbot-auto, so I can't say how you'd uninstall that completely. Just removing /usr/local/bin/certbot-auto isn't enough, as the wrapper script installs certbot somewhere. Could be /opt/eff but I'm not sure.

12

Ok, no worries… I’m quite familiar with python so it won’t be very difficult to understand what’s certbot-auto script does… although bash scripting isn’t my forte though hehe. In any case, I’ll try to fully understand how certbot-auto works first so I won’t mess up when trying to uninstall it… In any case, I hope the official package will work ok with all the files generated by certbot-auto… it should, right?

Btw, I’ve noticed this last time i’ve run certbot-auto certificates it autoupgraded automatically, ie:

[root@remote1 bpl.expert]# certbot-auto certificates
Upgrading certbot-auto 1.4.0 to 1.5.0...
Replacing certbot-auto...
Creating virtual environment...
Installing Python packages...
Installation succeeded.
Saving debug log to /var/log/letsencrypt/letsencrypt.log

I mean, probably this certbot-auto is more than good enough… but i still feel more comfortable installing from packages… so my provisioning scripts are more “robust” in case to add/deploy to new servers.

13

The EPEL repo EL-8 has version 1.4.0 of certbot. So if you do switch to the EPEL version of certbot in stead of certbot-auto, you could get a warning message saying the certificate renewal file was generated with a newer version of certbot. I believe however this only matters if you'd update a certificate or would get a new certificate with this new version 1.5.0. Also, I'm not expecting any breaking changes in the renewal configuration files between 1.4.0 and 1.5.0 so the warning can be ignored.

14

Oh, ok, that’s really relevant info definitely… btw, from what i’ve been able to decypher by reading certbot-auto is when you run it, it tries to autoupgrade automatically (unless specified otherwise) and a python virtualenv will be created at /opt/eff.org by default. Such virtualenv will contain all certbot python scripts as well as its python dependencies. Now I’m just trying to confirm whether other data files have been installed. You see? This is why also installing from packages is really handy… uninstalling, querying package files would be trivial that way… :slight_smile: , totally my bad… i screwed up here by trusting random unofficial tutorials from the internet :confused:

Ok, in any case, if i wanted to invalidate all the existing certificates before uninstalling certbot-auto and installing from packages so i wouldn’t get any warning (even if that doesn’t matter)… would there be any easy way to do it?

15

So far i’ve found these directories:

/etc/letsencrypt
/var/lib/letsencrypt
/var/log/letsencrypt
/opt/eff.org

Not sure if I’m still missing anything…

16

There's no reason to do that.

Only removing the virtualenv is enough. Removing/invalidating certificates could lead to running into rate limits.

17

Mmm, why do you think i shouldn't uninstall /var/lib/letsencrypt and /var/log/letsencryp as well?

Btw... I've also discovered that by activating the virtualenv certbot binary will be available in PATH...

Ok, I won't consider removing the installed certificates then.

18

Because it contains contents generated by the certbot python program, not the certbot-auto wrapper script.

Nothing strange there. However, it would be the certbot Python script installed by the certbot-auto wrapper script, not the same certbot Python script installed by your CentOS package manager. Having both installed could and/or would lead to strange behaviour.

1 Like
19

Ok... btw there is also this official reference at https://certbot.eff.org/docs/install.html#certbot-auto which says:

To remove certbot-auto, just delete it and the files it places under /opt/eff.org, along with any cronjob or systemd timer you may have created.

Summing up, it seems that removing the certbot-auto as well as the virtualenv and then installing the centos package should be good enough, right? In any case, I'll be trying first on the staging box to be 100% sure i won't screw up the production server :confused:

20

Ah, good to know, thanks!

Yes, I agree.