Bingo. You got it right.
1 Like
This is a symlink:
/etc/letsencrypt/live/$domain/fullchain.pem
Yes I do, and what happens in the case that someone gets access to a users password that is not admin ? If what you say is the case, then there would of been no need for this entire thread as Letsencrypt wouldn't need to set the permissions of that folder leading to the issue I am now facing.
Griffin, the files moved are not symlinks, they are the certs.
When I open the files that I have moved, they are not symlinks.
Which files are you moving?
I have just shown you the command.
Your question is contradictory.
You say you understand permissions and yet don't understand how the Mosquitto user (or group) is NOT the same as any other user.
When you apply permission only to the Mosquitto user/group it will do nothing for the average user.
Correct and now you have the super secret stuff in TWO places.
The second may not even be locked down at all.
Ah...
Why not just symlink to fullchain.pem instead of copying? Not like the cert contains anything private anyhow.
My point exactly so this is why it is not a valid fix for the issues with LetsEncrypt. So I would like to know what is going on,, and why it has suddenly changed. I have wasted a day on this
I link to a link to a file...?
How will that make it any better?
And how will that NOT expose unnecessary access to the average user?
I'm done - have a great rest of your day 
1 Like
Its not which is why I never did, but looks like letsencrypt leaves no option.
Well that clearly isn't gonna happen is it.
If you have an actual file in fullchain.pem, something is probably amiss. It's supposed to be a symlink...
For most tasks, it is safest to limit yourself to pointing symlinks at the files there, or using --deploy-hook to copy / make new files based upon those files, if your operational situation requires it (for instance, combining certificates and keys in different way, or having copies of things with different specific permissions that are demanded by other programs).
If the contents of /etc/letsencrypt/archive/CERTNAME are moved to a new folder, first specify the new folderās name in the renewal configuration file, then run certbot update_symlinks to point the symlinks in /etc/letsencrypt/live/CERTNAME to the new folder.
If you would like the live certificate files whose symlink location Certbot updates on each run to reside in a different location, first move them to that location, then specify the full path of each of the four files in the renewal configuration file. Since the symlinks are relative links, you must follow this with an invocation of certbot update_symlinks.
For example, say that a certificateās renewal configuration file previously contained the following directives:
archive_dir = /etc/letsencrypt/archive/example.com cert = /etc/letsencrypt/live/example.com/cert.pem privkey = /etc/letsencrypt/live/example.com/privkey.pem chain = /etc/letsencrypt/live/example.com/chain.pem fullchain = /etc/letsencrypt/live/example.com/fullchain.pem
The following commands could be used to specify where these files are located:
mv /etc/letsencrypt/archive/example.com /home/user/me/certbot/example_archive sed -i 's,/etc/letsencrypt/archive/example.com,/home/user/me/certbot/example_archive,' /etc/letsencrypt/renewal/example.com.conf mv /etc/letsencrypt/live/example.com/*.pem /home/user/me/certbot/ sed -i 's,/etc/letsencrypt/live/example.com,/home/user/me/certbot,g' /etc/letsencrypt/renewal/example.com.conf certbot update_symlinks
https://certbot.eff.org/docs/using.html#modifying-the-renewal-configuration-file
Yer I did ls -la and they are symlinks, but they are not moved they were copied. Service still fails so all of this was currently pointless.
Process: 5653 ExecStart=/usr/local/sbin/mosquitto -c /etc/mosquitto/mosquitto.conf (code=exited, status=1/FAILURE)
Main PID: 5653 (code=exited, status=1/FAILURE)
Oct 10 20:18:30 ssl systemd[1]: mosquitto.service: Main process exited, code=exited, status=1/FAILURE
Oct 10 20:18:30 ssl systemd[1]: mosquitto.service: Failed with result 'exit-code'.
Oct 10 20:18:31 ssl systemd[1]: mosquitto.service: Service hold-off time over, scheduling restart.
Oct 10 20:18:31 ssl systemd[1]: mosquitto.service: Scheduled restart job, restart counter is at 5.
Oct 10 20:18:31 ssl systemd[1]: Stopped Mosquitto MQTT Broker.
Oct 10 20:18:31 ssl systemd[1]: mosquitto.service: Start request repeated too quickly.
Oct 10 20:18:31 ssl systemd[1]: mosquitto.service: Failed with result 'exit-code'.
Oct 10 20:18:31 ssl systemd[1]: Failed to start Mosquitto MQTT Broker.
The instructions I just gave you from the official certbot guide tell you exactly how to accomplish what you need. I believe.
Symlinks are not working with the service.
That's not a good thing. Hmm...