Ruuvi Gateway local MQTT TLS

I’m trying to connect my Ruuvi Gateway to a local broker (Apache ActiveMQ Artemis) with MQTT using TLS. Unencrypted connection works fine and also other clients are able to connect with MQTTS.

What version of TLS (and possibly cipher suites) does the Ruuvi Gateway support? When clicking on “Check” on Ruuvi GW setup I get “Validation failed
Failed to connect (Error 32784 (ESP_ERR_MBEDTLS_SSL_HANDSHAKE_FAILED))” and
Artemis logs show " javax.net.ssl.SSLHandshakeException: Received fatal alert: bad_certificate"

Also, I’m using Let’s Encrypt certificates which expire in 3 months so uploading a custom cert every x months is not really an option.

My broker supports TLSv1.2 and the following ciphers (this is from nmap output):

PORT STATE SERVICE
8883/tcp open secure-mqtt
| ssl-enum-ciphers:
| TLSv1.2:
| ciphers:
| TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 (secp256r1) - A
| TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 (secp256r1) - A
| TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256 (secp256r1) - A
| TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384 (secp256r1) - A
| TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256 (secp256r1) - A
| TLS_ECDH_ECDSA_WITH_AES_256_GCM_SHA384 (prime256v1) - A
| TLS_ECDH_RSA_WITH_AES_256_GCM_SHA384 (prime256v1) - A
| TLS_ECDH_ECDSA_WITH_AES_128_GCM_SHA256 (prime256v1) - A
| TLS_ECDH_RSA_WITH_AES_128_GCM_SHA256 (prime256v1) - A
| TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA384 (prime256v1) - A
| TLS_ECDH_RSA_WITH_AES_256_CBC_SHA384 (prime256v1) - A
| TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA256 (prime256v1) - A
| TLS_ECDH_RSA_WITH_AES_128_CBC_SHA256 (prime256v1) - A
| TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA (secp256r1) - A
| TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA (secp256r1) - A
| TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA (prime256v1) - A
| TLS_ECDH_RSA_WITH_AES_256_CBC_SHA (prime256v1) - A
| TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA (prime256v1) - A
| TLS_ECDH_RSA_WITH_AES_128_CBC_SHA (prime256v1) - A
| compressors:
| NULL
| cipher preference: server
|_ least strength: A

Nmap done: 1 IP address (1 host up) scanned in 0.98 seconds

Nevermind, user error. And as usual, I found the problem immediately after posting the question :smiley: I still had the connection configured with an IP address instead of FQDN from the time I did not yet have local DNS, so obviously it failed since certificate name did not match.

2 Likes