This is a bugfix release. The changes below include the changes for 1.4.6, which wasn’t announced.
If you want to use TLS certificates you’ve generated using the Let’s Encrypt service, this is how you should configure your listener (replace “example.com” with your own domain of course):
First you need a copy of the root certificate. This will either be the ISRG Root X1, or IdenTrust DST Root CA X3. You need to check which of these root CAs signed the intermediate certificate you are using:
openssl x509 -in /etc/letsencrypt/live/example.com/chain.pem -noout -issuer
If your intermediate was issued by the ISRG root then use:
Otherwise you should go to https://www.identrust.com/certificates/trustid/root-download-x3.html to get the DST root certificate. Open a text editor, and paste the contents from that link, surrounding the text with the BEGIN and END lines as below:
<pasted content goes here
Then, each time after your script to automatically generate your certificates runs you should also run:
cat /etc/letsencrypt/live/example.com/chain.pem /etc/letsencrypt/<your root>.pem > /etc/letsencrypt/live/example.com/chain-ca.pem
Then use the following for your mosquitto.conf:
You need to be aware that current versions of mosquitto never update listener settings when running, so when you regenerate the server certificates you will need to completely restart the broker.
The current unreleased libwebsockets master branch defines the VERSION macro in its header files. I believe this to be a bug in libwebsockets.
This bug causes compilation of mosquitto with websockets support to fail.
Please use a released version of libwebsockets, either 1.2, 1.3 or 1.4. Mosquitto will compile with all of these versions.
I do not recommend using an unreleased version of libwebsockets, the project is not shy about making ABI/API incompatible changes between releases so it is impractical to provide support for.
The mosquitto project has, or can get, access to a wide variety of different systems to help with development. One important platform for which this is not true is Mac OS X. There are sufficient differences between Macs and other systems that this makes life difficult.
To this end, I would like to reach out to the mosquitto community to ask for help with obtaining either
I have been offered a remote account by a few individuals in the past, for which I’m very grateful, but only on a short term basis and, understandably, with limited control. Something on a longer term, with the ability to install packages would be much more useful. Unfortunately I realise this is relatively difficult to offer.
On the hardware side of things, there isn’t a need for a modern, powerful computer. A second hand Mac Mini of Core2Duo vintage with 1GB RAM and a reasonably modern version of Mac OS X would be quite sufficient, and ideal for me in terms of the space it takes up. Regrettably I feel I would have to turn down offers of an old iMac or Mac Pro.
2007-era Mac Minis go on Ebay UK for around £100. I’m hopeful that there is a company out there using mosquitto, likes Macs and for whom £100 would be a drop in the ocean. If so, or any individuals want to help out with a small donation towards this, please get in touch directly to firstname.lastname@example.org or head over to the downloads page to see the paypal donation link, and thanks very much in advance.
I have now awaiting delivery of a Mac mini. Thanks very much to all of you that have contributed, it is very much appreciated. If you would still like to support mosquitto development please don’t let this put you off…
Version 1.3.4 introduced the change that when using TLS with require_certificate set to false, the client is no longer asked for a client certificate. This seemed to be causing problems in some situations, particularly with embedded devices.
If use_identity_as_username is set to true when require_certificate is set to false, then the client will not be asked for a certificate, even if it has one configured. This means that the client will be refused access with connack code 4, “bad username or password”, because if use_identity_as_username currently requires that a certificate is present, even if allow_anonymous is set to true.
This change may cause unexpected results, but does not represent a security flaw because the change results in more clients being rejected than would otherwise have been.
This is a bugfix release. The reason for the rapid release of the past two versions is down to a Debian developer reviewing the mosquitto package. This is a good opportunity to ensure that as bug free a version as possible is present in Debian.
Binaries will follow shortly.
The Mosquitto Python client was donated to the Eclipse Paho project in June of this year. As mosquitto.py has been very popular, I have been maintaining both code bases together.
With the Mosquitto project also moving to Eclipse it is now even more redundant to keep maintaining mosquitto.py so I would like to recommend that everybody currently using mosquitto.py move over to using the Paho Python client.
The current state of the Paho client is now available on pypi and can be installed using “pip install paho-mqtt”.
To port code from mosquitto.py, you should change:
import mosquitto mqttc = mosquitto.Mosquitto()
import paho.mqtt.client as paho mqttc = paho.Client()
All error codes e.g. MOSQ_ERR_SUCCESS change to MQTT_ERR_SUCCESS.
The Paho module has a compatibility Mosquitto class that means a very simple (but not recommended for the long term) port can be achieved with the following line, assuming none of the error codes are used:
import paho.mqtt.client as mosquitto
I will keep applying updates to mosquitto.py until the Paho 1.0 release.
In time for the second day of Thingmonk, which I regret not being able to go to, version 1.2.3 of mosquitto is released. This is a bugfix release.