Mosquitto suddenly cannot load certificates

Help
64

No I agree it's not lol

65

This /usr/local/sbin/mosquitto -c /etc/mosquitto/mosquitto.conf however does work on its own

66

I'm going to page someone who will almost certainly know how to help you get this straightened out. He may not be around right now, so I beg for your patience here.

@_az

I think you're the right one to help here.

67

Thanks! I appreciate the help.

68

You're very welcome. Sorry we couldn't be of more immediate help. :slightly_smiling_face:

69

Is this even required if the symlinks have not been moved, just a copy of them placed in another folder.

70

You need to update the configuration file then run update_symlinks. Alex (_az) will know for sure the details though. He may have written them. :wink:

1 Like
71

Ok well good news is, changing the user of the service, it is now working as a service, well I have to test it does actually work, but the service runs. So all that is left is how to make sure the renewal updates the symlinks.

1 Like
72

I usually solve the permissions problem as follows. Mostly it's not a problem because lots of servers read the configuration as root and then drop privileges, but that's not the case with every server.

Is it okay if the service has access to all my certificates (i.e. there's only one security domain)? Then just use filesystem ACLs to allow read access:

sudo setfacl -R -m u:THEUSER:rX /etc/letsencrypt/{live,archive}

On the other hand, if I need to only grant access to a single certificate to a single user, then I tell Certbot to just copy it at issuance/renewal:

--deploy-hook "/usr/local/sbin/copy-to-mqtt.sh"

where it's something like:

cp -L "$RENEWED_LINEAGE/{fullchain,privkey}.pem" /path/to/mqtt/certs/
chown mqtt:mqtt /path/to/mqtt/certs/*.pem
3 Likes
73

Thanks! Is $RENEWED_LINEAGE passed by letsencrypt?

74

Yes, for --deploy-hook only. It points to the directory inside live/.

2 Likes
75

Do you know why this has suddenly become a problem ?

76

Cool thanks and it is needed even though the copied files are symlinks to the links in live?

77

I didn't read the early part of the thread thoroughly, but this aspect of Certbot's permissions has not changed in forever.

I would expect if anything changed, it would be something other than Certbot.

That -L flag means that the target of the symlink is copied, rather than the symlink itself.

If you only copy the symlink, you'll still have permission issues.

Edit: I screwed up the flag

1 Like
79

While you here :slight_smile: Could you suggest why one the original server that has been running for a year, there is no cron job to renew and yet the certificate is still valid? Bit confused on that on.

80

That is not the case here the command was sudo cp /etc/letsencrypt/live/$domain/fullchain.pem /server/libraries/mosquitto/certs/ and it is working correctly.

81

Are you sure it's still a symlink?

e.g. It looks like GNU cp dereferences symlinks by default. So the flag might not be necessary, but I'm not sure whether that's a reliable assumption everywhere.

Well, you can look up your domain on https://crt.sh and see whether somebody has been renewing it.

Either there was a cronjob setup automatically or your clients aren't actually validating the certificate.

It's distro-specific, but most methods of installing Certbot come with a cronjob preconfigured. (Except for certbot-auto and EPEL).

1 Like
82

Yes I did ls -la, they are symlinks.

Ok thanks.

83

If the copied file is still a symlink and your MQTT server isn't running as root, you should be getting a permission error. :confused:

1 Like
86

Those look like full copies to me, not symlinks.

2 Likes