mqtt_ssl example

[Alpignolo79]

Hi, i tried the mqtt_ssl and mqtt_ssl_mutual_auth examples and they both work correctly. Then i tried to configure the mqtt_ssl to connect to mqtts://test.mosquitto.org:8883 by downloading the pem CA certificate from here: https://test.mosquitto.org but i have a problem with the server connection.

This is the error: E (1623211) TRANS_SSL: mbedtls_ssl_handshake returned -0x2700 E (1623221) MQTT_CLIENT: Error transport connect

The same problem also occurs on a mosquitto broker running on my pc with a self-signed CA certificate created by me. If i use mosquitto to publish or subscrive using my self-signed CA certificate it work.

The error -0x2700 is MBEDTLS_ERR_X509_CERT_VERIFY_FAILED but i downloaded it from test.mosquitto web site so i think it's correct

Is there anyone who can tell me where the problem is?

Thanks Andrea

[david-cermak]

Hi Andrea,

The certificate from https://test.mosquitto.org is also self signed, so the mbed-tls cannot validate it against a root CA. In this case it's just enough to configure mqtt client:

    mqtt_cfg.cert_pem = NULL

This configuration may not protect from MITM. It might be possible to check manually (byte compare) the certificate, but not supported in this library.

Thanks, David

PS: This may be also related to the issue #39.

[Alpignolo79]

Hi David, Thanks for the reply! I set mqtt_cfg.cert_pem = NULL and it works but there is no MITM protection as you told me. I tried to investigate the problem by inserting a call to the "mbedtls_x509_crt_verify_info" function during the handshake and I saw that the mbedtls library rejects the connection with the broker test.mosquitto.org for this reason: "The certificate is signed with an unacceptable key (eg bad curve, RSA too short)" which could be due to the fact that the cert is an RSA-1024 and probably insecure. On the broker installed on my PC, the "mbedtls_x509_crt_verify_info" function returns the following error: "The certificate Common Name (CN) does not match with the expected CN". I tried then to generate a new server certificate having as Common Name the ip address of the pc on which the broker runs and the connection has been successful. Just let me know if I'm wrong,

thanks again for the support, Andrea

[projectgus]

Hi Andrea,

openssl x509 -text -in mosquitto.org.crt tells me this:

Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number:
            e0:fa:dc:f9:57:8c:98:bc
        Signature Algorithm: sha1WithRSAEncryption
        Issuer: C = GB, ST = United Kingdom, L = Derby, O = Mosquitto, OU = CA, CN = mosquitto.org, emailAddress = roger@atchoo.org
        Validity
            Not Before: Jun 29 22:11:59 2012 GMT
            Not After : Jun 27 22:11:59 2022 GMT
        Subject: C = GB, ST = United Kingdom, L = Derby, O = Mosquitto, OU = CA, CN = mosquitto.org, emailAddress = roger@atchoo.org
        Subject Public Key Info:
            Public Key Algorithm: rsaEncryption
                RSA Public-Key: (1024 bit)
                Modulus:
                    00:c6:24:2e:65:fb:4a:a3:93:fe:32:42:66:84:35:
                    35:67:42:ae:bf:e9:ab:8e:e6:df:1c:72:5d:c2:3e:
                    14:b1:26:c1:b1:37:47:db:cc:ac:4e:ac:45:b3:f6:
                    4b:cf:69:7e:b0:ad:ee:2b:88:4d:73:ca:c9:ca:54:
                    70:85:34:9a:d7:13:d4:ea:b1:18:15:76:95:be:91:
                    68:e4:f6:80:2e:69:c7:21:9a:14:9f:a1:03:e1:88:
                    6d:d6:0a:3b:72:69:ac:fc:52:06:84:69:a2:76:49:
                    bc:31:84:66:e3:37:37:ba:77:4b:f9:51:a2:2e:c6:
                    e7:01:b9:9a:f5:26:68:4e:51
                Exponent: 65537 (0x10001)
        X509v3 extensions:
            X509v3 Subject Key Identifier: 
                DA:77:64:27:79:5C:ED:20:F4:33:45:11:A3:E9:91:CA:A8:94:EF:E6
            X509v3 Authority Key Identifier: 
                keyid:DA:77:64:27:79:5C:ED:20:F4:33:45:11:A3:E9:91:CA:A8:94:EF:E6

            X509v3 Basic Constraints: 
                CA:TRUE
    Signature Algorithm: sha1WithRSAEncryption
         0a:b0:d6:b2:b8:36:54:54:09:40:4b:84:41:54:41:ab:23:3f:
         bc:5f:16:a9:55:6c:4d:9c:47:2d:11:b3:8a:37:29:2d:09:c3:
         34:15:07:01:bc:e7:18:1e:44:4c:8f:38:57:46:76:10:58:d8:
         fd:45:35:1c:b4:30:3a:fa:c6:bf:83:d9:93:b0:c6:ce:b7:74:
         6d:67:9c:09:d6:66:0e:ea:c2:82:e0:a5:9e:1f:11:23:c3:dc:
         f9:00:d5:98:0a:25:cd:b3:6d:24:3d:7c:23:f1:b7:65:b7:99:
         d5:5a:bf:ae:9c:e9:fb:1b:ed:e9:6c:d9:6d:88:cf:b8:04:44:
         94:97

I noticed sha1WithRSAEncryption. Since a few versions ago, mbedTLS defaults to no longer trusting SHA-1 digests in signatures (as SHA-1 is considered broken).

This can be re-enabled by setting MBEDTLS_TLS_DEFAULT_ALLOW_SHA1_IN_CERTIFICATES in mbedTLS config (we don't expose this in ESP-IDF menuconfig, unfortunately) or it's possible to use mbedTLS APIs to explicitly configure the certificate profile to allow it: https://github.com/ARMmbed/mbedtls/commit/ef86ab238fcbc186f324640bc264fd6f5f2123d1#diff-7964539f894e528a75890893d0c21926R1095

(I'm not sure if esp-mqtt API allows this level of access to mbedTLS configuration structures.)

However, the best solution is probably to find a sandbox broker with more up to date security. https://iot.eclipse.org/getting-started/#sandboxes seems like a good candidate (they use letsencrypt certs).

[Alpignolo79]

Hi Angus,

Thanks for the explanation! I will try to enable "MBEDTLS_TLS_DEFAULT_ALLOW_SHA1_IN_CERTIFICATES" for testing but as you say it is better to use a broker with more up to date security. Now I have all the information I needed.

thanks Andrea