Mosquitto: TLS certificates are not reloaded on SIGHUP

Created on 23 Aug 2017  路  10Comments  路  Source: eclipse/mosquitto

It seems when sending a SIGHUP to the broker for reloading the configuration, changed TLS certificate files (still having the same name) are not reloaded. So the broker keeps using "old" and potentially invalid certificates for its connections until it gets restarted.

Most helpful comment

I would argue that certificate validity only matters when establishing a new connection. Existing connections shouldn't care what the certificate is as they've already got the encrypted link up and running, since the cert is only used during key exchange (not in the encrypted phase). New connections would use the refreshed cert upon a SIGHUP.

All 10 comments

I have the same problem with the CRL file. To workaround it, I need to restart the Mosquitto every time an certificate is revoked. So, all clients need to reconnect and this causes overload on server.

Thinking loud. Changing TLS certificate will probably mean closing all working connections, so the clients need to be disconnected and reconnected regardless. I wonder if old connections can survive a change of certificate. Interesting question.

Thinking about it again. Probably correct, that existing connections cannot survive a change of certificate. Closing the ticket therefore.

This is an old issue but I am currently dealing with a similar problem. Basically, that the only way (I currently know how) to reload the TLS certificates is to restart the server.

I have a process to automatically check and renew my (LetsEncrypt) certificates but without the server being restarted the broker still becomes non-functional when its current certificate expires. I'd rather not setup a "dumb" cronjob to restart the broker periodically as I'd have to balance "response time to new certificates" with "downtime frequency caused by unnecessary restarts."

So, what is the accepted way (or what are people doing) to keep there broker up-to-date with new TLS certificates will not negatively impacting server uptime?

I am facing similar issues with the Mosquitto Broker. Setting up a cronjob with certbot renew --noninteractive --post-hook "/usr/bin/killall -HUP mosquitto" doesnt seem to do the trick.

I have to restart the entire machine for it to pickup the new certificates.
This doesnt seem right to me.

What is the right way to reapplying the SSL certificates ?

I'm basically running into the same issue for the "remote_password" setting - this is not reloaded on SIGHUP

I would argue that certificate validity only matters when establishing a new connection. Existing connections shouldn't care what the certificate is as they've already got the encrypted link up and running, since the cert is only used during key exchange (not in the encrypted phase). New connections would use the refreshed cert upon a SIGHUP.

@bergph please reopen the issue, it was closed because of concerns about "having to close existing tls connections" which is wrong as explained by @mwbrown.

Ironically, as of now, the only way to rotate certificates with mosquitto is restarting the server, which disconnects all clients.

@ralight is this something that could be looked at again?

I currently have a cronjob setup to restart mosquitto every month but this is way less than ideal - i'd really appreciate a way to get this service to reload certs without needing to teardown any existing connections.

Was this page helpful?
0 / 5 - 0 ratings