usually this should not be needed. We have quite a number of systems running this configuration without issue. @MichaIng any idea?
@kazgor
A bit of topic, but usually Nginx proxy manager should be the one who manage SSL certificates and not the backend web server. 
A little side note:
service lighttpd force-reload actually reloads the config without the need of restarting the service, so systemctl restart lighttpd.service is not necessary 
Can you try to create the file manually and access it via plain HTTP:
mkdir -p /var/www/.well-known/acme-challenge
echo 'this works' > /var/www/.well-known/acme-challenge/xclDxBCplrSQSNvv9klstrMm16SUjsf7ekMkTU6RldE
curl -IL 'http://mydomain.org/.well-known/acme-challenge/xclDxBCplrSQSNvv9klstrMm16SUjsf7ekMkTU6RldE'
and via browser.
Isn’t this the same that is done when HTTPS redirect is disabled as per above?
I can only test your snippet when the next renewal is pending. For now all is working as the renewal was done manually.
This can be done at any time. It’s a manual test like letsencrypt would do. It should just verify if you are able to download the file yourself.
Ah, understood.
The above results in:
HTTP/1.1 301 Moved Permanently
Location: https://mydomain.org/.well-known/acme-challenge/xclDxBCplrSQSNvv9klstrMm16SUjsf7ekMkTU6RldE
Date: Fri, 10 Feb 2023 11:35:03 GMT
Server: lighttpd/1.4.59
HTTP/2 200
content-type: application/octet-stream
accept-ranges: bytes
etag: "4127794750"
last-modified: Fri, 10 Feb 2023 11:35:01 GMT
content-length: 11
strict-transport-security: max-age=31536000; includeSubdomains
date: Fri, 10 Feb 2023 11:35:03 GMT
server: lighttpd/1.4.59
Looks all perfectly fine, also the content-length matches the actual “this works” string (+ line ending) of the file.
I verified on my home server and dietpi.com that HTTPS redirect is not an issue and HTTP/2 isn’t eiter.
See also docs: Challenge Types - Let's Encrypt
Our implementation of the HTTP-01 challenge follows redirects, up to 10 redirects deep. It only accepts redirects to “http:” or “https:”, and only to ports 80 or 443.
All fine in your case, a single redirect to (same) hostname to HTTPS on port 443, just standard.
Can you access that URL as well via browser from outside your LAN? E.g. try with mobile phone and mobile Internet used. It should show “this works” in browser window. You can create another file with shorter name, to avoid typing the long random string 
.
Can you access that URL as well via browser from outside your LAN
Yes I can open it without issue:
The web browser redirects to HTTPS and then offers the download of the file. Content is ‘this works’
Okay, I’ve no idea then why the ACME server would fail to do the same. I will try to replicate with Lighttpd. This is a Bullseye image on which hardware?
RPi 3 Model B+ (armv7l)
Tested on my RPi3B+ 32bit without issues
root@DietPi3:~# certbot renew --force-renewal
Saving debug log to /var/log/letsencrypt/letsencrypt.log
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Processing /etc/letsencrypt/renewal/my-domain.com.conf
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Plugins selected: Authenticator webroot, Installer None
Renewing an existing certificate for my-domain.com
Running deploy-hook command: /etc/letsencrypt/renewal-hooks/deploy/dietpi-lighttpd.sh
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
new certificate deployed without reload, fullchain is
/etc/letsencrypt/live/my-domain.com/fullchain.pem
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Congratulations, all renewals succeeded:
/etc/letsencrypt/live/my-domain.com/fullchain.pem (success)
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
root@DietPi3:~#
Btw, can you share some more information on your system
cat /boot/dietpi/.version
echo $G_DISTRO_NAME $G_RASPBIAN
uname -a
Now that I have renewed the certificate by hand, certbot renew --force-renewal also works on my PI.
cat /boot/dietpi/.version
G_DIETPI_VERSION_CORE=8
G_DIETPI_VERSION_SUB=13
G_DIETPI_VERSION_RC=2
G_GITBRANCH=‘master’
G_GITOWNER=‘MichaIng’
G_LIVE_PATCH_STATUS[0]=‘applied’
G_LIVE_PATCH_STATUS[1]=‘not applicable’
Bullseye
1
uname -a
Linux DietPi 5.15.84-v7+ #1613 SMP Thu Jan 5 11:59:48 GMT 2023 armv7l GNU/Linux
interesting. Usually, the automatic renewal process is working same way and should work next time.
That’s what I thought.
I will keep you posted next time the renewal day is near.