Has anyone managed to connect Tulip Machine Data Source (or Connector) to either the Moquette MQTT broker within the device side AWS greengrass deployment or cloud side within AWS Iot Sitewise? I can set this up for both with MQTT Explorer, but when using the same client and certificates/keys all I get from Tulip is “Test Failed [500] Error: Timeout”
Occaisionally I get
“Test failed: Client connection test failed: write EPROTO C0B7F7A9B67F0000:error:0A000412:SSL routines:ssl3_read_bytes:sslv3 alert bad certificate:../deps/openssl/openssl/ssl/record/rec_layer_s3.c:1586:SSL alert number 42”
(42? surely not… IYKYK)
which suggested a certificate issue - but it is the same certificate that works on MQTT Explorer.
When I setup Kepware IoTGateway with AWS greengrass I did have to do an odd extra certificate registration in Windows (which was undocumented and found by one of the AWS support people) - I thought something similar might be needed here but apart from the fields once MQTTS is selected there doesnt seem to be anywhere for additional certificate registration.
Hi Andy, thanks for posting this. From what you’ve described, Tulip’s handshake with the Moquette broker is stalling because the broker can’t validate the certificate chain that Tulip sends. MQTT Explorer works since it relies on your operating system’s trust store, masking any missing links in the chain.
Here’s what usually fixes it:
-
Build a single ca_chain.pem
that contains the AWS Root CA plus any intermediate CAs.
-
In your Tulip Connector, choose CA Chain and upload that file.
-
Upload device.pem.crt
under Client Certificate and private.pem.key
under Private Key
.
-
Point Tulip to the broker on port 8883 (Tulip and most brokers use port 8883 for secure MQTT, but if your Moquette or Greengrass config shows a different TLS port, swap that in).
-
Save, then hit Test. If it still times out, enable TLS debug on the connector.
-
Check the Moquette logs for cipher or hostname complaints and adjust as needed.
Tulip doesn’t pull from the host’s trust store, so it needs the full chain delivered up front; once the broker can validate your client cert, the timeout should disappear.
Give that a shot and let me know what you see in the logs.