Mutual TLS authentication with Azure?

XBee & XBee Gateway XBee - Cellular
, , , ,
1

I have been attempting for a while to get mutual TLS authentication to an Azure IoT Hub to work with the XBee3 Cellular modules. I have both the LTE-M module and the Cat 1 module and I have failed with both. We had some issues getting it to work in general, but now we can get messaging to the Azure IoT Hub to work with every other way except using the Xbee3 Cellular module. I’m looking for assistance in fixing the error we’re seeing with the cellular module.

Using the AWS example in the MicroPython Programming Guide (located here: https://www.digi.com/resources/documentation/digidocs/90002219/default.htm#tasks/t_test_connection.htm%3FTocPath%3DUse%2520AWS%2520IoT%2520from%2520MicroPython|_____5), I was able to make the necessary modifications to aws_https_pc.py to send a device-to-cloud message from my computer to my Azure IoT Hub. I uploaded the server certificate, client certificate and client key to my cellular module as directed in the example. I modified the MicroPython script to match the changes I made to the Python script on my computer. When I run the MicroPython script on my computer, I get a ECONNREFUSED error on the ‘w.connect’ line. I’ve tried changing the paths for the certificates and keyfile in the ussl.wrap_socket() call (i.e., for a private key named ‘priv.key’, I’ve tried ‘priv.key’, ‘cert/priv.key’ and ‘/flash/cert/priv.key’ for the keyfile variable). No matter what I’ve tried, I always get an ECONNREFUSED error on the ‘w.connect’ call.

Has anyone been able to get access working to an Azure IoT Hub and is able to provide guidance on what my problem may be?

EDIT 5/28/2019: After a lot of digging I started testing using the DigiCert Baltimore Root CA certificate for the azure-devices.net domain. I am now getting an EIO error on the ‘w.connect’ call. Does this mean I’m getting further and the server certificate is working, or does this mean it is breaking earlier?

EDIT 5/30/2019: I am now getting further but it still is not working. There were some extra characters at the beginning of the DigiCert Baltimore Root CA certificate, which was why I was getting the EIO error. After fixing that change, the w.connect now returns without an error and the MicroPython script attempts to send data. I get a return from the write with how many bytes were written, but I do not get a response from the Azure server. Below is the script I am using to attempt to send a device-to-cloud message:


# Azure IoT Hub hostname
host = "[IoTHubName].azure-devices.net"
 
# The IoT device for this test message
deviceID = "[DeviceName]"
 
import usocket, ussl

body = "{\"deviceID\":\"%s\",\"data\":\"new\"}" % (deviceID)
head = "POST /devices/%s/messages/events?api-version=2018-06-30 HTTP/1.1
Host:%s
Content-Length:%d

" % (deviceID, host, len(body))
byteMsg = head.encode('ASCII') + body.encode('ASCII')

s = usocket.socket(usocket.AF_INET, usocket.SOCK_STREAM, usocket.IPPROTO_SEC)
s.setblocking(False)
w = ussl.wrap_socket(s,
    keyfile='cert/private.key',
    certfile='cert/device.pem',
    ca_certs='cert/AzureBaltCA.pem')
w.connect((host, 443))

print("Sending the message

")
print(str(byteMsg, 'utf-8'))

w.write(byteMsg)

while True:
    data = w.read(1024)
    if data:
        print(str(data, 'utf-8'))
        break
w.close()

In the above script, substitute [IoTHubName] with the name of your IoT Hub, and substitute [DeviceName] with the name of the IoT device. In this example, I will see a printout after the call to w.write of the number of bytes written; I have verified that it is claiming to write the correct number of bytes for the HTTP message. However, the call to w.read never returns. I’m assuming that if it gets this far that the TLS mutual authentication is working. Is that a correct assumption? I’ve confirmed through testing with Python on my desktop that if the message is formatted incorrectly the Azure server will respond with an error message. As best I can tell the modem isn’t actually sending the message.

Could this possibly be related to this issue?
https://forums.digi.com/70247/ussl-wrap_socket-truncates-sent-data

https://forums.digi.com/70247/ussl-wrap_socket-truncates-sent-data