Cloudron makes it easy to run web apps like WordPress, Nextcloud, GitLab on your server. Find out more or install now.


Skip to content
  • Categories
  • Recent
  • Tags
  • Popular
  • Bookmarks
  • Search
Skins
  • Light
  • Cerulean
  • Cosmo
  • Flatly
  • Journal
  • Litera
  • Lumen
  • Lux
  • Materia
  • Minty
  • Morph
  • Pulse
  • Sandstone
  • Simplex
  • Sketchy
  • Spacelab
  • United
  • Yeti
  • Zephyr
  • Dark
  • Cyborg
  • Darkly
  • Quartz
  • Slate
  • Solar
  • Superhero
  • Vapor

  • Default (No Skin)
  • No Skin
Collapse
Brand Logo

Cloudron Forum

Apps | Demo | Docs | Install
  1. Cloudron Forum
  2. App Packaging & Development
  3. Mosquitto and TLS certs question

Mosquitto and TLS certs question

Scheduled Pinned Locked Moved App Packaging & Development
13 Posts 3 Posters 2.5k Views 3 Watching
  • Oldest to Newest
  • Newest to Oldest
  • Most Votes
    Reply
    • Reply as topic
    Log in to reply
    This topic has been deleted. Only users with topic management privileges can see it.
    • jadudmJ Offline
      jadudmJ Offline
      jadudm
      wrote on last edited by
      #1

      Hi all,

      I'm working on a mosquitto (MQTT) package. I'm... wrestling with testing a variety of clients, and am uncertain where I have a failure with an SSL handshake from one of my devices. Hence, I'm fishing.

      When I configure mosquitto, I need to give it the following for TLS to work (in theory?):

      certfile /etc/letsencrypt/live/mqtt.example.com/cert.pem
      cafile /etc/letsencrypt/live/mqtt.example.com/chain.pem
      keyfile /etc/letsencrypt/live/mqtt.example.com/privkey.pem
      

      Using the TLS addon, I seem to be able to provide... two of these three (certfile and keyfile)? If I'm using the cloudron base image, is there a path I can pass to mosquitto in its config to get a valid cafile?

      Why I'm fishing up this stream: I'm wondering if the absence of the cafile is something that could break a TLS handshake? (Some clients I test work fine; some don't. I'm wondering if there's a cipher mismatch or TLS v1.2 vs v1.3 problem here...)

      Many thanks,
      Matt

      I use Cloudron on a Dell 7040 I bought on eBay.

      girishG 1 Reply Last reply
      1
      • jadudmJ jadudm

        Hi all,

        I'm working on a mosquitto (MQTT) package. I'm... wrestling with testing a variety of clients, and am uncertain where I have a failure with an SSL handshake from one of my devices. Hence, I'm fishing.

        When I configure mosquitto, I need to give it the following for TLS to work (in theory?):

        certfile /etc/letsencrypt/live/mqtt.example.com/cert.pem
        cafile /etc/letsencrypt/live/mqtt.example.com/chain.pem
        keyfile /etc/letsencrypt/live/mqtt.example.com/privkey.pem
        

        Using the TLS addon, I seem to be able to provide... two of these three (certfile and keyfile)? If I'm using the cloudron base image, is there a path I can pass to mosquitto in its config to get a valid cafile?

        Why I'm fishing up this stream: I'm wondering if the absence of the cafile is something that could break a TLS handshake? (Some clients I test work fine; some don't. I'm wondering if there's a cipher mismatch or TLS v1.2 vs v1.3 problem here...)

        Many thanks,
        Matt

        girishG Offline
        girishG Offline
        girish
        Staff
        wrote on last edited by
        #2

        @jadudm the CA file I think is the intermediate certificate. this is already embedded in the cert file. Is it not optional in MQTT config?

        1 Reply Last reply
        0
        • girishG Offline
          girishG Offline
          girish
          Staff
          wrote on last edited by
          #3

          You can get the intermediate certs here - https://letsencrypt.org/certificates/#intermediate-certificates , if it's really needed. I think "Let’s Encrypt R3" is the one which is active now (ideally, this should not be hardcoded though).

          jadudmJ 2 Replies Last reply
          0
          • girishG girish

            You can get the intermediate certs here - https://letsencrypt.org/certificates/#intermediate-certificates , if it's really needed. I think "Let’s Encrypt R3" is the one which is active now (ideally, this should not be hardcoded though).

            jadudmJ Offline
            jadudmJ Offline
            jadudm
            wrote on last edited by
            #4

            @girish Many thanks; that was useful to know about/something I did not know existed (the LE cert page), but sadly didn't solve my problem. (I was hoping for magic.)

            I'm going to call it a day; it is clear that mosquitto should support the cipher that tasmota is offering, but I keep getting

            error:1417A0C1:SSL routines:tls_post_process_client_hello:no shared cipher
            

            on the broker side. I hoped that this might be a "missing piece."

            When I have this figured out, I'll feel better about suggesting there possibility of a viable MQTT container.

            (My goal here is to pair it with Home Assistant, and know that Tasmota, an open source firmware for home automation devices, will work with the MQTT broker.)

            I use Cloudron on a Dell 7040 I bought on eBay.

            1 Reply Last reply
            0
            • girishG girish

              You can get the intermediate certs here - https://letsencrypt.org/certificates/#intermediate-certificates , if it's really needed. I think "Let’s Encrypt R3" is the one which is active now (ideally, this should not be hardcoded though).

              jadudmJ Offline
              jadudmJ Offline
              jadudm
              wrote on last edited by
              #5

              @girish I have learned more things.

              I know/understand certs and PKI at a high level, not at a here's now it works level. I'm in the process of learning more of here's how it works to solve this.

              I was able to stand up a container with mosquitto running just fine, and as long as the clients that talked to it were running on full-featured hosts, everything "just worked" (e.g. running mosquitto_sub on another Linux host). This works for a cloudron-packaged version of Home Assistant, which bundles an MQTT client, and performs auto-discovery. It has happily discovered my MQTT container, which is good, and sends messages to it.

              However, my mosquitto container did not work with my (one) piece of IoT test hardware. Specifically, it did not work for my little "smart switch," based on an ESP8266 (a Sonoff Basic). This is an 80MHz device with KB of RAM and 1MB of flash. As a result, the Tasmota team uses BearSSL as the SSL implementation, and it only deals with one encryption algorithm and TLSv1.2. It is known to work with mosquitto (being an Eclipse foundation "standard" of sorts in the MQTT broker world). As proof that it works, I can build an insecure container (meaning I configure mosquitto to use comms unencrypted by TLS), and the Tasmota device will talk to the container just fine. That confirmed for me that it wasn't a network issue... it is definitely a cert/encryption question.

              But, it looks like there's a cert question w.r.t. the LetsEncrypt certs that cloudron pulls down. Or, that's where I'm going to investigate next.

              From a developer on the Tasmota end of things:

              I used the laptop version of BearSSL and I got the same error:

              build/brssl client mqtt.example.com:443 -cs ECDHE_RSA_WITH_AES_128_GCM_SHA256
              WARNING: no configured trust anchor
              connecting to: 1.2.3.4 connected.
              Algorithms:
                  RNG:           rdrand
                  AES/CTR:       pwr8
                  GHASH (GCM):   pclmul
                  EC:            all_m31
                  RSA (vrfy):    i62
               ERROR: SSL error 296 (received alert 40)
              

              Using OpenSSL shows that Server public key is 384 bit
              We don't support EC keys for servers, they need to be RSA 2048 or 4096. In general we don't support ECDSA. You need to generate a new certificate with RSA private/public key

              Now, this is where I need to do more learning. Does cloudron pull an elliptic-curve-based cert (as opposed to an RSA-based cert), and that's going to be something I need to work around? (For example, I could bundle self-signed certs into the mosquitto container, or generate them when the container is launched, or...). Or, is there something I don't (yet) know about cloudron that will let me solve/work around this?

              If y'all have insight, I welcome it. In the meantime, I'm going to go digging into the box source, and find out what happens when cloudron requests LE certs on my behalf. 🙂

              When I'm done, I'll document all of this somewhere, so that people following after me don't have to walk the same path.

              Cheers,
              M

              I use Cloudron on a Dell 7040 I bought on eBay.

              girishG 1 Reply Last reply
              0
              • jadudmJ Offline
                jadudmJ Offline
                jadudm
                wrote on last edited by
                #6

                @girish, Based on

                https://git.cloudron.io/cloudron/box/-/blob/master/src/acme2.js#L279

                which is part of the function Acme2.prototype.createKeyAndCsr, suggesting... it is where the key and CSR are created...

                let key = safe.child_process.execSync('openssl ecparam -genkey -name secp384r1');
                

                which suggests a key based on an EC.

                But, this is a few minutes of code spelunking. I'm going to hold for a bit, and see if you have any thoughts. I'll do some more reading, but I have a suspicion solving this is going to require more access to box than an app packager currently has.

                I wonder if I can include a self-signed cert in the app package that matches the domain as a stop-gap? 🤔

                Anyway. Thoughts welcome, and thank you.

                I use Cloudron on a Dell 7040 I bought on eBay.

                1 Reply Last reply
                0
                • jadudmJ Offline
                  jadudmJ Offline
                  jadudm
                  wrote on last edited by
                  #7

                  And, now that I've thought about it some more.

                  1. Being able to run a TLS-protected MQTT server is good. It allows full-featured clients to talk to the sever. That said,
                  2. Embedded devices will need the CA compiled in. (Or, I might be able to get away with a fingerprint. That said...)
                  3. It would require an RSA cert, no larger than 2048 bits.

                  This could be more annoying than it is worth. Certainly, having an RSA cert that would play with BearSSL would be nice, but it might not be in the cards.

                  I'll have to think about whether there are other options/approaches available.

                  I use Cloudron on a Dell 7040 I bought on eBay.

                  1 Reply Last reply
                  0
                  • jadudmJ Offline
                    jadudmJ Offline
                    jadudm
                    wrote on last edited by
                    #8

                    For anyone following along at home... I have, in "draft" form:

                    1. A Home Assistant app, and
                    2. An MQTT instance that:
                      • uses self-signed certs, and
                      • listens on 8883 (the default secure port) with TLS

                    The self-signed certs are because I'm working against the constraints of BearSSL, which means I need 2048-bit RSA CA/keys and SHA256.

                    However, the test is that I now have a Sonoff Basic switch that is chattering away at my Home Assistant instance over TLS-secured MQTT.

                    There's a bunch of cleanup I'd like to do in order to make these apps usable for others. The MQTT container alone might be generally usable... perhaps I can put the LetsEncrypt certs on the default port, and put the self-signed certs on a different port (e.g. 8883 for LE, and 9993 for the self-signed certs...)

                    I use Cloudron on a Dell 7040 I bought on eBay.

                    1 Reply Last reply
                    0
                    • jadudmJ jadudm

                      @girish I have learned more things.

                      I know/understand certs and PKI at a high level, not at a here's now it works level. I'm in the process of learning more of here's how it works to solve this.

                      I was able to stand up a container with mosquitto running just fine, and as long as the clients that talked to it were running on full-featured hosts, everything "just worked" (e.g. running mosquitto_sub on another Linux host). This works for a cloudron-packaged version of Home Assistant, which bundles an MQTT client, and performs auto-discovery. It has happily discovered my MQTT container, which is good, and sends messages to it.

                      However, my mosquitto container did not work with my (one) piece of IoT test hardware. Specifically, it did not work for my little "smart switch," based on an ESP8266 (a Sonoff Basic). This is an 80MHz device with KB of RAM and 1MB of flash. As a result, the Tasmota team uses BearSSL as the SSL implementation, and it only deals with one encryption algorithm and TLSv1.2. It is known to work with mosquitto (being an Eclipse foundation "standard" of sorts in the MQTT broker world). As proof that it works, I can build an insecure container (meaning I configure mosquitto to use comms unencrypted by TLS), and the Tasmota device will talk to the container just fine. That confirmed for me that it wasn't a network issue... it is definitely a cert/encryption question.

                      But, it looks like there's a cert question w.r.t. the LetsEncrypt certs that cloudron pulls down. Or, that's where I'm going to investigate next.

                      From a developer on the Tasmota end of things:

                      I used the laptop version of BearSSL and I got the same error:

                      build/brssl client mqtt.example.com:443 -cs ECDHE_RSA_WITH_AES_128_GCM_SHA256
                      WARNING: no configured trust anchor
                      connecting to: 1.2.3.4 connected.
                      Algorithms:
                          RNG:           rdrand
                          AES/CTR:       pwr8
                          GHASH (GCM):   pclmul
                          EC:            all_m31
                          RSA (vrfy):    i62
                       ERROR: SSL error 296 (received alert 40)
                      

                      Using OpenSSL shows that Server public key is 384 bit
                      We don't support EC keys for servers, they need to be RSA 2048 or 4096. In general we don't support ECDSA. You need to generate a new certificate with RSA private/public key

                      Now, this is where I need to do more learning. Does cloudron pull an elliptic-curve-based cert (as opposed to an RSA-based cert), and that's going to be something I need to work around? (For example, I could bundle self-signed certs into the mosquitto container, or generate them when the container is launched, or...). Or, is there something I don't (yet) know about cloudron that will let me solve/work around this?

                      If y'all have insight, I welcome it. In the meantime, I'm going to go digging into the box source, and find out what happens when cloudron requests LE certs on my behalf. 🙂

                      When I'm done, I'll document all of this somewhere, so that people following after me don't have to walk the same path.

                      Cheers,
                      M

                      girishG Offline
                      girishG Offline
                      girish
                      Staff
                      wrote on last edited by
                      #9

                      @jadudm said in Mosquitto and TLS certs question:

                      We don't support EC keys for servers, they need to be RSA 2048 or 4096. In general we don't support ECDSA. You need to generate a new certificate with RSA private/public key

                      Ah, yet another service not supporting ECDSA certs. I wonder why this. IIRC, zapier also had the same limitation. I wonder if this is because those certs don't work well on older devices?

                      jadudmJ 1 Reply Last reply
                      1
                      • girishG girish

                        @jadudm said in Mosquitto and TLS certs question:

                        We don't support EC keys for servers, they need to be RSA 2048 or 4096. In general we don't support ECDSA. You need to generate a new certificate with RSA private/public key

                        Ah, yet another service not supporting ECDSA certs. I wonder why this. IIRC, zapier also had the same limitation. I wonder if this is because those certs don't work well on older devices?

                        jadudmJ Offline
                        jadudmJ Offline
                        jadudm
                        wrote on last edited by jadudm
                        #10

                        @girish In the case, it has to do with embedded systems.

                        Tasmota is a FOSS firmware that runs on a variety of ESP8266 and ESP32-based devices. (https://en.wikipedia.org/wiki/ESP8266) Think "cheap, wifi-enabled switches and sensors." The 8266 is a wifi-enabled chip (2.4GHz only) that runs at 80MHz, has around 80K of RAM, and typically between 512K and 4MB of external flash (for static code and data storage).

                        As a result, fitting a full SSL implementation is not an option. BearSSL is used in this context, and a limited number of algorithms are therefore made available from that library. There's only one RSA-based cipher that is included in Tasmota (IIRC).

                        Hence, I'm going to see if I can package Mosquitto so that one of the TLS ports can use the system-wide LE certs (which could, for example, be used by server-side home orchestration/automation packages like Home Assistant to talk to the MQTT server), but also allow a second port to use the self-signed certs (that can interact with low-spec embedded devices).

                        Long story short, the SSL limitations are more about the resource constraints of the systems involved (e.g. small IoT devices) than it is about out-of-date software. (mosquitto is an Eclipse foundation project, and effectively the reference standard for MQTT as a protocol, and BearSSL as a library implements more ciphers; MQTT is not the problem, Bear's limitations, somewhat. The limitations of the ESP8266-based IoT hardware is definitely a problem for doing EC ciphers.)

                        I use Cloudron on a Dell 7040 I bought on eBay.

                        girishG 1 Reply Last reply
                        1
                        • jadudmJ jadudm

                          @girish In the case, it has to do with embedded systems.

                          Tasmota is a FOSS firmware that runs on a variety of ESP8266 and ESP32-based devices. (https://en.wikipedia.org/wiki/ESP8266) Think "cheap, wifi-enabled switches and sensors." The 8266 is a wifi-enabled chip (2.4GHz only) that runs at 80MHz, has around 80K of RAM, and typically between 512K and 4MB of external flash (for static code and data storage).

                          As a result, fitting a full SSL implementation is not an option. BearSSL is used in this context, and a limited number of algorithms are therefore made available from that library. There's only one RSA-based cipher that is included in Tasmota (IIRC).

                          Hence, I'm going to see if I can package Mosquitto so that one of the TLS ports can use the system-wide LE certs (which could, for example, be used by server-side home orchestration/automation packages like Home Assistant to talk to the MQTT server), but also allow a second port to use the self-signed certs (that can interact with low-spec embedded devices).

                          Long story short, the SSL limitations are more about the resource constraints of the systems involved (e.g. small IoT devices) than it is about out-of-date software. (mosquitto is an Eclipse foundation project, and effectively the reference standard for MQTT as a protocol, and BearSSL as a library implements more ciphers; MQTT is not the problem, Bear's limitations, somewhat. The limitations of the ESP8266-based IoT hardware is definitely a problem for doing EC ciphers.)

                          girishG Offline
                          girishG Offline
                          girish
                          Staff
                          wrote on last edited by
                          #11

                          @jadudm I re-opened https://git.cloudron.io/cloudron/box/-/issues/799 . Should be easy to add

                          jadudmJ 1 Reply Last reply
                          0
                          • girishG girish

                            @jadudm I re-opened https://git.cloudron.io/cloudron/box/-/issues/799 . Should be easy to add

                            jadudmJ Offline
                            jadudmJ Offline
                            jadudm
                            wrote on last edited by
                            #12

                            @girish For reference, these are the constraints if we're trying to support Tasmota-based IoT devices using BearSSL:

                            Your SSL/TLS server must support TLS 1.2 and the RSA_WITH_AES_128_GCM_SHA256 cipher - which is the case with the default Mosquitto configuration
                             
                            The server certificate must have an RSA private key (max 2048 bits) and the certificate must be signed with RSA and SHA256 hash. This is the case with default LetsEncrypt certificates.

                            The docs are obviously dated, because I don't know that those LE defaults still apply.

                            I use Cloudron on a Dell 7040 I bought on eBay.

                            1 Reply Last reply
                            0
                            • B Offline
                              B Offline
                              bartmathijssen
                              wrote on last edited by
                              #13

                              @jadudm I'm looking for a mosquitto Cloudron package and found this topic. Do you have any plans to open-source the package you created?

                              1 Reply Last reply
                              0
                              Reply
                              • Reply as topic
                              Log in to reply
                              • Oldest to Newest
                              • Newest to Oldest
                              • Most Votes


                                • Login

                                • Don't have an account? Register

                                • Login or register to search.
                                • First post
                                  Last post
                                0
                                • Categories
                                • Recent
                                • Tags
                                • Popular
                                • Bookmarks
                                • Search