Pico W TLS connection using umqtt.simple

[JustinS-B]

Hi, I just can't seem to crack this as I have been going around in circles for several days, so it's definitely now time to ask for help. I have mosquitto installed on a Linux server and on my Linux workstation (so that I have the CLI tools to remotely test my connection) and a Pico W micropython client. Using mosquitto_pub and mosquitto_sub on my workstation I can connect perfectly using TLS using self signed certificates. My Pico W fails to connect, giving the following error on my mosquitto server.

What am I doing wrong please, as it's driving me crazy?

1674476712: New connection from 192.168.1.73:53639 on port 8883.
1674476712: OpenSSL Error[0]: error:0A00010B:SSL routines::wrong version number
1674476712: Client <unknown> disconnected: Protocol error.

My micropython code is this:

# MQTT Code originally copied from: https://www.tomshardware.com/how-to/send-and-receive-data-raspberry-pi-pico-w-mqtt

# WLAN connection code
import network
import time
import secrets                               # separate file with WiFi username & password
#
wlan = network.WLAN(network.STA_IF)
wlan.config(pm = 0xa11140)					 # disable energy-saving mode
wlan.active(True)
wlan.connect(secrets.SSID, secrets.PASSWORD) # separate file with WiFi username & password
time.sleep(5)
#
print('WiFi connected')
status = wlan.ifconfig()
print('ip = ' + status[0])
# End of WLAN connection code

#############################################


from machine import Pin
from umqtt.simple import MQTTClient

mqtt_server = '192.168.1.1'
port=8883
user='user1'
client_id = 'client1'
topic_sub = b'test/topic01'

# read in DER formatted certs & user key
with open('/certs/der_user1.key', 'rb') as f:
    key_data = f.read()
with open('/certs/der_user1.crt', 'rb') as f:
    cert_data = f.read()
with open('/certs/ed_ca.crt.der', 'rb') as f:
    ca_data = f.read()

# & put them in a dict
ssl_params = dict()
ssl_params["certfile"] = cert_data
ssl_params["keyfile"] = key_data
ssl_params["cadata"] = ca_data
ssl_params["server_hostname"] = mqtt_server
ssl_params["cert_reqs"] = "ssl.CERT_REQUIRED"


# Built in Pico W LED
led = machine.Pin("LED", machine.Pin.OUT)

def sub_cb(topic, msg):
    print("New message on topic {}".format(topic.decode('utf-8')))
    msg = msg.decode('utf-8')
    print(msg)
    if msg == "on":
        led.on()
    elif msg == "off":
        led.off()

def mqtt_connect():
    client = MQTTClient(client_id, mqtt_server, port, keepalive=60, ssl_params=ssl_params)
    client.set_callback(sub_cb)
    client.connect()
    print('Connected to %s MQTT Broker'%(mqtt_server))
    return client

def reconnect():
    print('Failed to connect to MQTT Broker. Reconnecting...')
    time.sleep(5)
    machine.reset()
    
try:
    client = mqtt_connect()
except OSError as e:
    reconnect()
while True:
    client.subscribe(topic_sub)
    time.sleep(1)

This is my mosquitto.conf just in case:

per_listener_settings true
persistence true
persistence_file mosquitto.db
persistence_location /var/lib/mosquitto
autosave_interval 300
retain_available true

listener 8883
socket_domain ipv4
allow_anonymous false
allow_zero_length_clientid false
require_certificate true
use_identity_as_username true
cafile /etc/mosquitto/certs_ed/ed_ca.crt
certfile /etc/mosquitto/certs_ed/ed_broker.crt
keyfile /etc/mosquitto/certs_ed/ed_broker.key

[peterhinch]

This post may be of help. This may be relevant to setting the "server_hostname" value. This TLS stuff is a black art.

[JustinS-B]

Oh woe, woe & thrice woe. Alas, but it was that forum post and the Hive MQ page that got me this far. Unfortunately, I fear that calling this TLS stuff a Black Art is a slight understatement. However, I really feel that I am right on the verge of finding the secret sauce that makes the magic recipe work. I will keep you posted...

[Carglglz]

@JustinS-B

ssl_params["cert_reqs"] = "ssl.CERT_REQUIRED"  # --> this should be ssl.CERT_REQUIRED without ""

ssl.CERT_REQUIRED is a constant, not a string.

# read in DER formatted certs & user key
with open('/certs/der_user1.key', 'rb') as f:
    key_data = f.read()
with open('/certs/der_user1.crt', 'rb') as f:
    cert_data = f.read()

For client side, you don't need key, cert unless you are doing mTLS to authenticate both client and server.

1674476712: New connection from 192.168.1.73:53639 on port 8883.
1674476712: OpenSSL Error[0]: error:0A00010B:SSL routines::wrong version number
1674476712: Client disconnected: Protocol error.

Hard to tell tbh, it could be multiple things, e.g. a mismatch of server_hostname with Common Name of the server certificate, the Pico without current date/time set (see #9071 ), or maybe there is no compatible cipher suite (although I doubt that)

Could you test if this works? tests/net_inet/ssl_cert.py
Remember to set the current time i.e.

import ntptime
ntptime.settime()

Also can you see what's the output in your Pico?

PD: Wireshark can help with debugging TLS , where you can see at which step of the handshake things go sideways 🤦🏼‍♂️

[peterhinch]

It would be great if you (or another expert) could write a guide to setting up a TLS client. The issue causes regular problems and few of us have a detailed understanding of the underlying theory. I could link to it (or publish it) in my unofficial FAQ.

[Carglglz]

@peterhinch I'm by no means an expert, I've just been dealing with TLS for some years now... 🐰 🕳️

could write a guide to setting up a TLS client. The issue causes regular problems and few of us have a detailed understanding of the underlying theory

Yes, I could do that and probably SSLContext will help with those issues once it's done. 👍🏼

[JustinS-B]

@peterhinch as soon as this is cracked I'll publish everything in the unofficial FAQ, as it unfortunately appears to be a very common problem with almost no documented solutions.

@Carglglz oooooh. I haven't done anything involving the time yet. I'll add it & fix the ssl.CERT_REQUIRED is a constant, not a string glitch. But I ran your ssl_cert.py test first. Once I had remembered to connect it to the wifi, it gave this error...
I'm using Thonny 4.0.2 on a fully updated Arch Linux workstation.

>>> %Run -c $EDITOR_CONTENT
WiFi connected
ip = 192.168.1.40
Local time after synchronization：(2023, 1, 24, 14, 36, 47, 1, 24)
Traceback (most recent call last):
  File "<stdin>", line 90, in <module>
  File "<stdin>", line 83, in main
AttributeError: 'module' object has no attribute 'CERT_REQUIRED'
>>> 

[Carglglz]

@JustinS-B see https://github.com/orgs/micropython/discussions/9222#discussioncomment-3573129, in case it helps.. but
you may be running a version of MicroPython previous to this commit? #8252 (it was merged late July)
go to https://micropython.org/download/rp2-pico-w/ , install one of those and try again 👍🏼

[JustinS-B]

@Carglglz - I think that I have multiple things that are nailing my attempt to connect via TLS. I'm going to rebuild it all from scratch with the most basic mosquitto config possible and brand new certificates. That way I can do my best to reduce potential points of failure, Keep It Simple, & build it up from there.

This looks to be my first point of failure: https://mosquitto.org/blog/2014/10/unintended-change-of-behaviour-in-1-3-4/

I found the cadata vs ca_data gotcha last night too, so I've already caught that one.

I am using micropython-firmware-pico-w-290622.uf2 which was the latest official version when I flashed it a week & a half ago, but will update to the current official release & see if it changes anything - before trying the micropython nightly builds, to see if that makes a difference.

[JustinS-B]

import sys
print(sys.version)

gives this output: 3.4.0; MicroPython v1.19.1-837-g67fac4ebc on 2023-01-24

[Carglglz]

Good, did you try ssl_cert.py again?, if that it's working then we could solve MQTT TLS next. You should disable client authentication in mosquitto.conf, so the pico doesn't need to present client certificates, and probably use ssl.CERT_NONE in the pico to check if the bare minimum TLS handshake does work?

[JustinS-B]

OK, progress on ssl_cert.py

>>> %Run -c $EDITOR_CONTENT

###########################################

Connecting ...
WiFi connected,  ip = 192.168.1.40
Pico time now：(2023, 1, 27, 9, 22, 17, 4, 27)
sys.version:  3.4.0; MicroPython v1.19.1-837-g67fac4ebc on 2023-01-24

###########################################

b'HTTP/1.1 200 OK\r\n'
>>> 

mosquitto conf

listener 8883
socket_domain ipv4
require_certificate false
cafile   /etc/mosquitto/certs_rsa/mosquitto-certificate-authority.crt
keyfile  /etc/mosquitto/certs_rsa/mqtt-server.key
certfile /etc/mosquitto/certs_rsa/mqtt-server.crt

Fingers crossed

[JustinS-B]

OK, I've done my best to simplify everything & really reduce the scope for for me to make mistakes.
This is the full TypeError: extra keyword arguments given error that it gives now.

>>> %Run -c $EDITOR_CONTENT

###########################################

Connecting ...
WiFi connected,  ip = 192.168.1.40
Pico time now：(2023, 1, 29, 16, 5, 37, 6, 29)
sys.version:  3.4.0; MicroPython v1.19.1-837-g67fac4ebc on 2023-01-24

###########################################

Loading CA Certificate
Obtained CA Certificate
Traceback (most recent call last):
  File "<stdin>", line 31, in <module>
  File "<stdin>", line 28, in connectMQTT
  File "/lib/umqtt/simple.py", line 61, in connect
TypeError: extra keyword arguments given
>>> 

This is my micropython code on the Pico W

import homewifi # This does my wifi & ntp sync
from umqtt.simple import MQTTClient

Broker='192.168.1.1'
BrokerPort=8883
BrokerUser="user1"
BrokerKeepalive=60

print('Loading CA Certificate')
with open(b'/certs_new/ca.crt.der', 'rb') as f:
    ca_data = f.read()
f.close()
print('Obtained CA Certificate')

def connectMQTT():
    client = MQTTClient(client_id=b"client1",
    server='192.168.44.1',
    port=BrokerPort,
    user=BrokerUser,
    keepalive=BrokerKeepalive,
    ssl=True,
    ssl_params={'server_hostname':'192.168.1.1','ca_certs':ca_data}
    )

    client.connect()
    return client

client = connectMQTT()

My mosquitto.conf is

per_listener_settings true
persistence true
persistence_file mosquitto.db
persistence_location /var/lib/mosquitto
autosave_interval 300
retain_available true
log_timestamp_format %Y-%m-%d_%H:%M:%S

listener 8883
socket_domain ipv4
require_certificate true
cafile /etc/mosquitto/certs_new/ca.crt
certfile /etc/mosquitto/certs_new/server.crt
keyfile /etc/mosquitto/certs_new/server.key

[Carglglz]

@JustinS-B
is cadata keyword not ca_certs and if you want the Pico to validate the server you should use "cert_reqs": ssl.CERT_REQUIRED

ssl_params = {'server_side':False, 'key':None, 'cert':None, 'cadata':cacert, 'cert_reqs':ssl.CERT_REQUIRED, 'server_hostname': server}

check also #9259, since I'm not sure
this would work server_hostname with

Broker='192.168.1.1'
server='192.168.44.1'

usually it should be the same probably raspberrypi.local (the default name IIRC)?
although I'm not sure if the PICO W has mDNS enabled, in any case I would use the raspberrypi IP
for both.

Also if you enable this in mosquitto.conf

require_certificate true

Mosquitto will expect a client certificate see https://mosquitto.org/man/mosquitto-conf-5.html

When using certificate based encryption there are three options that affect authentication. The first is require_certificate, which may be set to true or false. If false, the SSL/TLS component of the client will verify the server but there is no requirement for the client to provide anything for the server: authentication is limited to the MQTT built in username/password. If require_certificate is true, the client must provide a valid certificate in order to connect successfully. In this case, the second and third options, use_identity_as_username and use_subject_as_username, become relevant. If set to true, use_identity_as_username causes the Common Name (CN) from the client certificate to be used instead of the MQTT username for access control purposes. The password is not used because it is assumed that only authenticated clients have valid certificates. This means that any CA certificates you include in cafile or capath will be able to issue client certificates that are valid for connecting to your broker. If use_identity_as_username is false, the client must authenticate as normal (if required by password_file) through the MQTT options. The same principle applies for the use_subject_as_username option, but the entire certificate subject is used as the username instead of just the CN.

So the steps I would follow:

1- Disable authentication in both PICO and Mosquitto, .i.e

'cert_reqs':ssl.CERT_NONE  # in ssl_params

in PICO
and

require_certificate false

in mosquitto.conf

2- If that works then enable server authentication in the PICO as discussed above

3- If that works too then enable client authentication in mosquitto.conf, and provide the PICO with a key, and a certificate signed by a CA that Mosquitto can trust, .i.e

This means that any CA certificates you include in cafile or capath will be able to issue client certificates that are valid for connecting to your broker.

[peterhinch]

I don't know if this is any help but I looked at the source recently and established that the valid keys for the ssl_params dict are:

• 'key'
• 'cert'
• 'server_side'
• 'server_hostname'
• 'do_handshake'
• 'cert_reqs' mbedtls only
• 'cadata' mbedtls only

I don't know which platforms use mbedtls.

[JustinS-B]

thanks @peterhinch, I thought that I was being clever by looking the SSl source code at python-stdlib/ssl/ssl.py but it has completely different arguments from mbedtls, even though they sound similar!. I got all mixed up between TLS and SSL. I think this is actually why it all appears to be such a dark art

    kw = {}                                          # YOU NEED Mbed-TLS NOT SSL FOR TLS TO WORK ON A PICO W
    if keyfile is not None:
        kw["keyfile"] = keyfile                      # THIS WILL NOT WORK ON A PICO W - use 'key' instead
    if certfile is not None:
        kw["certfile"] = certfile                    # THIS WILL NOT WORK ON A PICO W - use 'cert' instead
    if server_side is not False:
        kw["server_side"] = server_side     
    if cert_reqs is not CERT_NONE:
        kw["cert_reqs"] = cert_reqs          
    if ca_certs is not None:
        kw["ca_certs"] = ca_certs                    # THIS WILL NOT WORK ON A PICO W - use 'cadata' instead
    if server_hostname is not None:
        kw["server_hostname"] = server_hostname
    return _ussl.wrap_socket(sock, **kw)

I will rework my code to use the mbedtls ones instead, as this could be the key to many of my bigger problems.

[Carglglz]

@peterhinch AFAIK the platforms that use mbedtls currently are:

• esp32 port
• pico w
• unix port
• stm32

I thought that I was being clever by looking the SSl source code at python-stdlib/ssl/ssl.py but it has completely different arguments from mbedtls, even though they sound similar!. I got all mixed up between TLS and SSL. I think this is actually why it all appears to be such a dark art.

@JustinS-B Unfortunately that file is outdated as a I mentioned in #9222

I was using the MIcroPython ssl module documentation and using the following sslparams = {'server_side':False, 'keyfile':None, 'certfile':None, 'ca_certs':None, 'cert_reqs':ussl.CERT_NONE} because If I use the "cadata" keyword I get a "TypeError: unexpected keyword argument 'cadata'" so I swapped for "ca_certs:None" which seemed to be accepted.

👀

maybe you are using ssl module from micropython-lib/ssl which has not been yet updated? Try to use

import ussl as ssl 

And use cadata keyword, that should work.

[JustinS-B]

OK, following everything that @peterhinch and @Carglglz have advised, it is now 100% working. Yes, we have MQTT working over TLS on a Raspberry Pi Pico W. If you give me a day or two, I will pull what I have to pieces & rebuild it - just to make sure that I can do it from scratch & that it is now as simple as it appears to be. Then I'll post it all back here so that we'll have a nice, simple, easy to follow guide that anyone can follow. Or, at least, a guide to the way that I have got it to play nicely with your TLS magic sprinkled onto it.

[JustinS-B]

My way of getting my Pico W to connect to my mosquitto broker over TLS uses the standard approach of a Self Signed CA, server key/cert, and user key/cert, along with a DH handshake. I haven't managed to work out yet how to only use the server key/cert on its own, without the user key/certs, but it's got to be easy now that the basic ssl_params work.

I am in the process of documenting the way I created my different keys, certificates & DH dhparamfile, and as soon as it is clear & easy to follow I will upload it to my Github Gist and link it in here.

This is the micropython code for my Pico W that finally got MQTT working over SSL/TLS for me - all down to @peterhinch and @Carglglz as I was completely lost on the ssl_params errors.

NOTE: it takes around 7 seconds to do the DH handshake & get the TLS up and running.

import homewifi    # Separate connection script that  does my wifi connection & ntp sync

from umqtt.simple import MQTTClient
#import ssl                 # @peterhinch it doesn't seem to matter which one you use
import ussl as ssl          # as both ssl and ussl seem to happily work here
import utime

server='192.168.1.1'      # this has to match the MQTT server CN or SAN credentials in server_crt.pem
server_port=8883
server_keepalive=60     # if you don't include a keepalive nothing works.
mqtt_topic='test/topic01'
local_client_name='client1'

# This uses the CA cert, along with a user key & cert
# TLS certs & keys need to be in DER format on the Pico W

with open('/certs/ca_crt.der', 'rb') as f:
    ca_data = f.read()
f.close()
print('Read CA Certificate... OK')

with open('/certs/user2_crt.der', 'rb') as f:
    user_cert = f.read()
f.close()
print('Read User Certificate... OK')

with open('/certs/user2_key.der', 'rb') as f:
    user_key = f.read()
f.close()
print('Read User Key... OK')

#  This is the magic from @peterhinch and @Carglglz 
#  which fixes the 'TypeError: extra keyword arguments' problems. 
#  NOTE: 'do_handshake' needs DH dhparamfile on the server
#
ssl_params={'key':user_key,
            'cert':user_cert,
            'cadata':ca_data,
            'server_hostname':server,
            'server_side':False,
            'cert_reqs':ssl.CERT_REQUIRED,
            'do_handshake':True}

# this is my really basic MQTT connection.
# NOTE: we don't need username or password here
# as we use the directive 'use_identity_as_username true' in mosquitto.conf
# this takes the CN from the TLS cert and uses it as the username

def connectMQTT():
    client = MQTTClient(
        client_id=local_client_name,
        server=server,
        port=server_port,
        keepalive=server_keepalive,
        ssl=True,
        ssl_params=ssl_params
    )
    
    client.connect()
    return client

client = connectMQTT()
print("Connecting to MQTT Server...")

while True: 
    print("Sending ON") 
    client.publish(topic=mqtt_topic, msg="ON")
    utime.sleep(1) 
    print("Sending OFF") 
    client.publish(topic=mqtt_topic, msg="OFF")
    
    utime.sleep(1) 

this is my mosquitto.conf

per_listener_settings true
persistence true
persistence_file mosquitto.db
persistence_location /var/lib/mosquitto
autosave_interval 300
retain_available true
log_timestamp_format %Y-%m-%d_%H:%M:%S

listener 8883
socket_domain ipv4
require_certificate true
dhparamfile dhparam.pem
allow_anonymous false
allow_zero_length_clientid false
use_identity_as_username true
acl_file /etc/mosquitto/aclfile
cafile /etc/mosquitto/certs/ca_crt.pem
certfile /etc/mosquitto/certs/server_crt.pem
keyfile /etc/mosquitto/certs/server_key.pem

and this is the choir singing the hallelujah chorus.
NOTE: the u'user2' is lifted from the CN in user2_crt.der as the TLS session is authenticated

2023-02-02_09:50:13: New connection from 192.168.1.40:60534 on port 8883.
2023-02-02_09:50:22: New client connected from 192.168.1.40:60534 as client1 (p2, c1, k60, u'user2').
2023-02-02_09:50:22: No will message specified.
2023-02-02_09:50:22: Sending CONNACK to client1 (0, 0)
2023-02-02_09:50:22: Received PUBLISH from client1 (d0, q0, r0, m0, 'test/topic01', ... (2 bytes))
2023-02-02_09:50:23: Received PUBLISH from client1 (d0, q0, r0, m0, 'test/topic01', ... (3 bytes))
...

[Carglglz]

it takes around 7 seconds to do the DH handshake

@JustinS-B are you using RSA keys maybe?? Now that you have TLS running you may want to test ECDSA keys and see if that speeds up the handshake? (one of the reason is that RSA certs are bigger and therefore more data transfer in the handshake)
Also if that works you may want to try key/cert generation in device so see this lib that I made mpy-mbedtls (although this requires making your own "custom" firmware with USER_C_MODULES see MicroPython external C modules

[JustinS-B]

@Carglglz yes, I'm currently using RSA. I tried ED25519 but micropython hated it. The mosquitto server & the command line utilities were fine with it though. Possibly it was an error on my part, as it's easy to mistype something. I've been working on some simple bash scripts to idiotproof my certificate creation, so I'll try some of the more interesting EC certs now that I can generate them almost automatically. RSA size was why I tried ED25519. Any specific curves that I ought to be checking out?

[Carglglz]

@JustinS-B sadly ED25519 is still not supported for TLS in mbedTLS see #5819 for ongoing work and #9506 (comment) for MicroPython EC support

Any specific curves that I ought to be checking out?

Currently these are the ones supported:

# NIST 
ECDSA-secp521r1          :    1093 sign/s
ECDSA-secp384r1          :    1556 sign/s
ECDSA-secp256r1          :    2121 sign/s
ECDSA-secp224r1          :    3103 sign/s
ECDSA-secp192r1          :    4107 sign/s
ECDSA-secp521r1          :     299 verify/s
ECDSA-secp384r1          :     431 verify/s
ECDSA-secp256r1          :     612 verify/s
ECDSA-secp224r1          :     935 verify/s
ECDSA-secp192r1          :    1316 verify/s

So probably ECDSA-secp384r1 or ECDSA-secp256r1 are the best candidates from a security-performance trade-off point of view.

[JustinS-B]

Apologies for the delay in continuing this, but I have spent the past few days discovering more than 20 or 30 ways of stopping MQTT TLS from working, just by trying to be clever. Apparently, it really doesn't let you stray too far from the true path. I'm still pinpointing precisely what it is that stands between a set of lovely keys and certificates that work beautifully & a set that appear to look nearly identical, but which cause everything to collapse in a smoking wreck. Thankfully, because I know that the micropython works, & that my Mosquitto CLI clients work, I can just cook up some new credentials, restart everything & see if/how/when it breaks. When I work out the recipe for the credential creation, I'll post it & identify the secret sauce.

[JustinS-B]

Interestingly, mbedtls on the Pico W doesn't currently support tlsv1.3. It also has issues with certificates including X509v3 extensions, in that it will authenticate calls to any of the X509v3 Subject Alternative Name DNS entries, but fails to authenticate any calls to X509v3 Subject Alternative Name IP Address entries. The normal mosquitto_pub and mosquitto_sub clients will do either without issue. However, as a workaround, if you also add a DNS entry of your IP Address along with the normal IP Address, mbedtls will authenticate just fine.

Giving this when you check the mbedtls workaround certificate:

X509v3 Subject Alternative Name: 
                DNS:server, DNS:server.example.com, DNS:192.168.1.1, IP Address:192.168.1.1

[Carglglz]

Interestingly, mbedtls on the Pico W doesn't currently support tlsv1.3.

Yes you can check current common configuration in extmod/mbedtls/mbedtls_config_common.h

#define MBEDTLS_SSL_PROTO_TLS1
#define MBEDTLS_SSL_PROTO_TLS1_1
#define MBEDTLS_SSL_PROTO_TLS1_2

and for Pico W in particular ports/rp2/mbedtls/mbedtls_config.h

it also has issues with certificates including X509v3 extensions, in that it will authenticate calls to any of the X509v3 Subject Alternative Name DNS entries, but fails to authenticate any calls to X509v3 Subject Alternative Name IP Address entries.

This can be tricky, mbedtls docs (lib/mbedtls/apidoc/group__x509__module.html#gae88f1d8e6696eb2beeffe0a708219e6b) says

mbedtls_x509_crt_verify()
cn The expected Common Name. This will be checked to be present in the certificate's subjectAltNames extension or, if this extension is absent, as a CN component in its Subject name. Currently only DNS names are supported. This may be NULL if the CN need not be verified.

Also I got this working with ec keys/certs and the command to generate the keys with openssl is this:

openssl ecparam -genkey -name prime256v1 -noout -out ec-key-private.pem

[JustinS-B]

I ran some tests to time the TLS/SSL connection with different key types/strengths using micropython on Pico W to my Raspberry Pi based Mosquitto server.

Curve P-256 is another way of referring to the ECDSA-secp256r1 curve
P-384 is ECDSA-secp384r1
P-521 is ECDSA-secp521r1

Seconds   Curve or RSA Bits
7.232	EC P-256
8.016	RSA 2048
11.288	EC P-384
16.425	EC P-521
26.646	RSA 4096	

So there's not a lot in it really, although the ECDSA-secp256r1 curve (P-256) is the winner by nearly a second. I didn't include the ED25519 curve because it isn't supported on the Pico W because of mbedtls, and all my tests were done on the Pico W. I only included the 4096 bit RSA and the CDSA-secp521r1 for fun, just to see how long they took.

[Carglglz]

Seconds Curve or RSA Bits
7.232 EC P-256

I've just tested this with an ESP32 and it took only 1.9 s, so it seems like the hardware accelerator makes a big difference here... 👀

[JustinS-B]

@peterhinch and @Carglglz - I have set up a Github Repo for my bash script which automatically creates a self-signed CA, a mosquitto server key and cert and a DH parameters file, along with its associated script that creates client keys and certs. You can set it to create an entirely EC based setup, using either P-256, P-384 or P-521 curves, or an ED25519 based setup, or an RSA setup with either 2048 0r 4096 bit keys. It renames any cert or key dirs that it finds, so it definitely won't delete anything. It should all work well, but naturally, it is very much a work in progress. It really helps when you are testing & timing different curves as it can generate an entire P-256 setup including a handful of client in a couple of seconds, then do it all again for a P-384 based setup instead in another couple of seconds. It takes longer to write the new keys/certs to the Pico W than it does to create them.

https://github.com/JustinS-B/Mosquitto_CA_and_Certs

[Carglglz]

@JustinS-B Nice work! Also you may want to check cryptography.io to be able to do this in python (and to learn and explore other types of cryptography too)

[ondrej1024]

Hi,

I am trying to connect to my MQTT broker from an RPi Pico. The broker does not require a client certificate and key so I am running this code on the Pico:

cadata = open('/res/ca.der','rb').read()
ssl_params = {'cert_reqs':ussl.CERT_REQUIRED,
              'cadata': cadata,
              'server_hostname':server,
              'server_side':False,
              #'do_handshake':True
              }
mqttc =  MQTTClient(client_id='rpipico', server=server, port=8883, keepalive=60, ssl=True, ssl_params=ssl_params)
mqttc.connect()

On the broker I can see the connection attempt, but no error message. On the Pico I get this error:

Traceback (most recent call last):
  File "<stdin>", line 45, in <module>
  File "umqtt/simple2.py", line 267, in connect
OSError: [Errno 107] ENOTCONN

There must be a way to make this work 🙄

[ondrej1024]

I searched a lot but some things are just not clear from the available documentation:

• what does the server_side ssl parameter mean?
• what does the do_handshake ssl parameter actually do ? When is a handshake needed?

[ondrej1024]

Using the umqtt.simple package the code above works just fine. The issue I described occurs only with the umqtt.simple2 package (for whatever reason).

[theAshokSharma]

Need some help!!
How do I copy .DER file to Pico W?

[peterhinch]

With the official mpremote tool.

mpremote cp file.der :