Aloha,
When I started -tt ing lighttpd latest version 1.4.68 under Ubuntu 22..04. It was complaining that the fullchain.pem didn't exist at /var/www/html/exampl.com/certs. Despite my late night making all the links from /etc/letsencrypt/live/exampl.com for all my vhosts. So I ventured into the directories with a proper term .dircolors turned on and got:
I immediately use stat on the nearest one and it show the link is:
File: fullchain.pem -> ../../archive/exampl.com/fullchain1.pem
And it is indeed two directories down and just to the left of the original link file. so not sure if this is how the policy issued with shorthand since it is possible to have in a different directory on install if the path arguments are there, but as I see it now I gotta go modify all the links from /
Your problem is best handled in the Help section. I moved your post to that area. Had you posted there to start you are shown a questionnaire which I show below. Please answer the questions as best you can. thanks
==================
Please fill out the fields below so we can help you better. Note: you must provide your domain name to get help. Domain names for issued certificates are all made public in Certificate Transparency logs (e.g. https://crt.sh/?q=example.com), so withholding your domain name here does not increase secrecy, but only makes it harder for us to provide help.
My domain is:
I ran this command:
It produced this output:
My web server is (include version):
The operating system my web server runs on is (include version):
My hosting provider, if applicable, is:
I can login to a root shell on my machine (yes or no, or I don't know):
I'm using a control panel to manage my site (no, or provide the name and version of the control panel):
The version of my client is (e.g. output of certbot --version or certbot-auto --version if you're using Certbot):
My problem doesn't need to be handled. I've already got it well in hand, for any who need it the simple solution is to:
ln -sfn /complete/path/to/point/to linkfile.etc (with appropriate super cow powers as needed)
I was reporting a weak point in the scripts etc. that use short hand reference rather than full paths. And with something as important as the #1 internet security protocol such shortcuts shouldn't be taken for granted. (I would have just as eloquently expounded on it without all the verbose bluster I've seen in some of the "policy issue" topics with in the general UNIX universe, but earlier but my timeline got cut short.)
Going back to root now,
Feiwuzei
EPSF I forgot to mention in the original that that orphans are in all directories both the original /etc/letsencrypt/live/.... (where it would seem the short hand is correct) as well as the server side links
I'm not understanding where the trouble is coming from.
I think on ~all UNIX-like platforms, copying a symlink (with cp) causes it to be followed/dereferenced by default. So hopefully users should not encounter situations where they copy a symlink that contains the relative path as a target.
Creating a symlink to a symlink should work as expected through renewals as well.
Modifying anything inside /etc/letsencrypt/{live,archive} is dangerous, it would not be surprising if things broke, there are numerous README files in there warning against that.
How did you end up in a problematic situation? Can you provide examples of commands?
Maybe I did break something since I did indeed symlink the symlink to the server directory, but as I pointed out the shorthand /../../ is correct from the /live/exampl.com directories. But since the Webserver wasn't running yet It wasn't "live" usage just static. and even the .pem links not used are orphans as well.