Incorrect SSL certificate used by nextcloud / lighttp

Required Information

  • DietPi version | 8.5.1
  • Distro version | bullseye 0
  • Kernel version | 5.15.32-v8+
  • SBC model | RPi 4 Model B (aarch64)
  • Power supply used | 5.1V 3A
  • SD card used | none, run from SSD

Additional Information (if applicable)

  • Software title | Nextcloud
  • Was the software title installed freshly or updated/migrated? No

Steps to reproduce

I am running a Nextcloud installation (installed through dietpi-software). Everything runs fine as such, however, I must have messed up something with my SSL certificates. I created the certificates using dietpi-letsencrypt. They live under /etc/letsencrypt/live/my-domain-name
The auto-renewal is set up and seems to work correctly, as the current certificate has 58 day validity left, and I haven’t run a manual update recently.

But now I get an error from the clients that access the nextcloud instance, saying that the certificate has expired. The error messages show a serial number of the certificate which is not the same as the for the one in /etc/letsencrypt/live/my-domain-name

So somehow, it seems that the server is not using the correct certificate. I checked the conf-file at /etc/lighttpd/conf-enabled/50-dietpi-https.conf , which shows the correct certificate: ssl.pemfile = "/etc/letsencrypt/live/my-domain-name/fullchain.pem"

So I wonder what other certificate seems to be used, where it is located and why it’s not using the correct one. Can anyone help me to resolve this?

Did you reload the server after the certificate was renewed?

alright, thx @trendy, that was too simple… :wink:
I just rebooted (which I would have done now anyway, as there were several updates installed from dietpi-update). After the reboot, the clients stopped complaining and when I check what certificate they use now, it states an issuing date of 3rd of May and expiry on August 1st, which is exactly what I found for the certificate in /etc/letsencrypt/live/my-domain-name generated through the auto-renewal of the dietpi certbot.

So as usual: a simple reboot solves 90% of all problems…
But is this the intended way? The auto-renewal process is - well - automatic, so I might not be around to do a reboot of the pi or a reload of the server after a certificate has been renewed. Of course, I could set up a cron job for that, but is that how it’s supposed to be?

Usually there is no need to restart the system manually as the new certificate should be applied automatically. Keep an eye on the next certificate renewal if it is behaving same or differently.

I think it is normal that a webserver reload is required to push the old certificate out of the cache. In case of Apache and Nginx we use the native Certbot Apache/Nginx modules where a reload may be implied. But there is no such module for Lighttpd. A renewal/deploy hook should solve it. I’ll run some tests and add this in case.

1 Like

Perfect, sounds awesome. Also I will report back if it runs into this issue again after the current certificate expires (which should be in August).

I didn’t mean to reboot the whole dietpi server, just the web server. Something like sudo service lighttpd reload or sudo service lighttpd restart if the first doesn’t help.

I need to copy the new certs to another location, so I use this:

root@blowfish:[~]$ cat /etc/letsencrypt/renewal-hooks/post/01-copy-crt.sh 
#!/bin/bash
cp ...
service blah-blah restart

You get the idea that you can add the script in the post renewal hooks.

2 Likes

Thx for the advice,
I have added a script in /etc/letsencrypt/renewal-hooks/post called 01-reload-server.sh and made it executable with the following content:

#!/bin/sh
sudo service lighttpd reload

Manually I can run the script without error, so I assume that it will work on the next auto-renewal. If not I will report it here.

1 Like