joe
April 29, 2020, 12:13pm
1
Since yesterday MQTT publish over TLS doesn’t work anymore. I use a STEM account.
I tested the the connection from my desk by:
mosquitto_pub -h industrial.api.ubidots.com -p 8883 -t '/v1.6/devices/test' -m '{"test": 23.0}' -u '<token>' -q 1 --insecure -d
And the result is:
Client mosqpub|1892-desk sending CONNECT Error: The connection was lost.
I started the test from German internet connection.
Is there something wrong with my connection test?
Is the MQTT TLS connection still available?
Can anybody repeat this test?
joe
April 29, 2020, 8:10pm
2
I found the problem. The fingerprint, which I have checked in my code, has changed. It is necessary to check against the provided ca certs (roots.pem ) instead of checking the fingerprint.
BearSSL::X509List x509;
WiFiClientSecure client;
PubSubClient mqtt(SERVER, SERVER_PORT, client);
configTime(1 * 3600, 0, "de.pool.ntp.org");
delay(2000);
x509.append(ca1);
x509.append(ca2);
client.setTrustAnchors(&x509);
mqtt.connect("device", TOKEN, "");
We do not report issues at the Ubidots side during the last days. I have made a test at my side and everything works as expected:
If you are attempting to send data through TLS, you should download the Ubidots CA certificates from our docs and specify the path where they are stored at your system using the --cafile
flag:
mosquitto_sub -h "industrial.api.ubidots.com" -t "/v1.6/devices/renesas8/do1" -u "<TOKEN>" -p 8883 -q 1 --cafile <PATH_TO_CERTIFICATES>
Avoid the usage of the --insecure
flag, as from the mosquitto docs , that flag is not a proper parameter for a production application:
f you need to resort to using this option in a production environment, your setup is at fault and there is no point using encryption
All the best
1 Like