cancel
Showing results for 
Search instead for 
Did you mean: 

SPWF04Sx MQTTCONN problem with Azure

Fabio Ciani
Associate II
Error while parsing Rich Text Content
8 REPLIES 8
Elio Cometti
Senior II
Posted on March 26, 2018 at 13:59

Dear Fabio,

The SPWF04S does not allows TLS connections w/ anonymous authentication.

Actually, during the handshake with the remote server, the SPWF04 try to verify the peers certificate and it need the certificate of the Root CA that signed the server certificate (when connecting from my network access point it requires the Microsoft IT TLS CA 1 certificate).

The SPWF04 does not have the ability to automatically download the Root CA certificate from the distribution point, hence you have to manually load the Root CA certificate prior to establish the connection to Azure servers.

Posted on March 26, 2018 at 15:57

Hello Elio,

First of all, thanks for your quick reply.

Following your tips I've downloaded file 'Microsoft IT TLS CA 1.crt' from '

https://www.microsoft.com/pki/mscorp/cps/default.htm'';

.

Then I've converted it to PEM format with openssl and loaded in 

SPWF04S with this commands:

AT+S.TLSCERT=content,2

AT+S.TLSCERT=ca,2037

-----BEGIN CERTIFICATE-----

MIIFtDCCBJygAwIBAgIQCLh6UBu+nNotFk0+OVG/VTANBgkqhkiG9w0BAQsFADBa

MQswCQYDVQQGEwJJRTESMBAGA1UEChMJQmFsdGltb3JlMRMwEQYDVQQLEwpDeWJl

clRydXN0MSIwIAYDVQQDExlCYWx0aW1vcmUgQ3liZXJUcnVzdCBSb290MB4XDTE2

MDUyMDEyNTEyOFoXDTI0MDUyMDEyNTEyOFowgYsxCzAJBgNVBAYTAlVTMRMwEQYD

VQQIEwpXYXNoaW5ndG9uMRAwDgYDVQQHEwdSZWRtb25kMR4wHAYDVQQKExVNaWNy

b3NvZnQgQ29ycG9yYXRpb24xFTATBgNVBAsTDE1pY3Jvc29mdCBJVDEeMBwGA1UE

AxMVTWljcm9zb2Z0IElUIFRMUyBDQSAxMIICIjANBgkqhkiG9w0BAQEFAAOCAg8A

MIICCgKCAgEAjvPxhHV3vL7JpPUWpVMrUGCZ3Nh92SS14XJJN0j+2oaTo30dmksQ

TXd5fmWpfG424kfUNknQzCQCJxTirnHN2Vd0PBBWGZJKh2L545CNXt7RQRsaph9A

oiwejlXXJthoQqvsDd7dXmGVs6xsgc6o4K2vX8qm5FFoLif9VCpxpMy7fpLx9lNR

BTHQGYKwymPQ8koAC830aUv0WpZWOSbJnUsKYzQygKUE5eoot8EAwG0a8CjUSo+A

rHMZ2PUWL62uCJdiBiz+56XwrUFTf40rMcMUcyHd43hjnFGGtaJIScB5CBVDACuZ

uEvgx1cHbMS5plQtAVPyo/KkzNnBVPOIzeRME9OKMyFYrRi/vjmBcDlpN/hbpGPv

CQffhxpix5oIxdEdXmJ2Ad1p5ji7RLAtTTrGLoDgYHJb8szmjlw6IR5dsDkrveoT

y5bLtmp0jI68DhCfG6VAQY+RXHanDvGqOoe3DHffcWovKGFCLZAPcgWrZ+DBe8uc

QJrECghEjHw9uqkOHrHZIr0fX0Fqc1T2ZuKg+aY53tJ382kEv7e7PMST/3IEHLU2

nWh/3/o5T7L2j7kc/63tDhUI44Z88khJd5cW9v0A9k+mXm/nOcBRZT3rsZcw7Oqe

c/weLKDfi89zX7UOBkIXJpXs2Kkn0NBllFziP8ooKaUg9MjdXbT/5t0CAwEAAaOC

AUIwggE+MB0GA1UdDgQWBBRYiJ/W3JxIIrcUPv+EiOjmhf/6fTAfBgNVHSMEGDAW

gBTlnVkwgkdYzKz6CFQ2hns6tQRN8DASBgNVHRMBAf8ECDAGAQH/AgEAMA4GA1Ud

DwEB/wQEAwIBhjAnBgNVHSUEIDAeBggrBgEFBQcDAQYIKwYBBQUHAwIGCCsGAQUF

BwMJMDQGCCsGAQUFBwEBBCgwJjAkBggrBgEFBQcwAYYYaHR0cDovL29jc3AuZGln

aWNlcnQuY29tMDoGA1UdHwQzMDEwL6AtoCuGKWh0dHA6Ly9jcmwzLmRpZ2ljZXJ0

LmNvbS9PbW5pcm9vdDIwMjUuY3JsMD0GA1UdIAQ2MDQwMgYEVR0gADAqMCgGCCsG

AQUFBwIBFhxodHRwczovL3d3dy5kaWdpY2VydC5jb20vQ1BTMA0GCSqGSIb3DQEB

CwUAA4IBAQAwmsadav3vkwgMvoJ3+XagbZ57MCN7qCla9Go+xwsMlt+4S1LkDZw4

7XhjtXPAHB874Kf/f0lRlTK40Jup5c+WA4GA1UphGP7Easbff0FGIpyAZusPQqDk

86Qho5jQenT2jOjD0iuqK84RWRlE51wHCULr1/0VTblvbEQ1Joe6oztosIHnIMl/

EwLzzKufHJVQy65kgLuHCl3OpmuyfeM9NuIpUbcl/NAJ47CtxGIuPn6FJrL2r/dt

MXPGGZipcpMCzsoLPTzs2XDogPUWq3hqh03GgTeoCnaBBqjvF2B8cBATPDjXM0zk

N2UI+5Gz6BZ2YSpl9ViUs0UB78BPA3u4

-----END CERTIFICATE-----

AT+S.TLSCERT=auth,20

<e5 9d 59 30 82 47 58 cc ac fa 08 54 36 86 7b 3a b5 04 4d f0> // in binary format

Then if I list all certificate data with

AT+S.TLSCERT=content,1

the reply is

AT-S.List

AT-S.CA:1

AT-S.Cert:0

AT-S.Key:0

AT-S.Id:1

AT-S.OK

But the problem remains: when I send MQTTCONN command, the reply is always the same:

AT-S.Skip CA

AT-S.Skip CA

AT-S.Certificate Error:23

AT-S.ERROR:111:Request failed

Where I'm wrong?

Thank you.

Fabio.

Posted on March 26, 2018 at 18:19

Hello Fabio,

my answer was partially incorrect, as 'Microsoft IT TLS CA 1' is the intermediate Authority, while the Root CA is 'Baltimore CyberTrust Root'.

Please refer to the security application note on how to download the latter certificate from

<LINK NO LONGER ACTIVE>

using a browser. Please note that you might need to parse this certificate as it may contain unsupported line terminators (openssl -in BaltimoreCyberTrustRoot.crt -out b.crt). I'm attaching the parsed certificate for your convenience.

Here below, the certificate in binary format is loaded, so that the key is automatically extracted:

AT+S.TLSCERT=ca,891

AT-S.SubjectKeyId:E5:9D:59:30:82:47:58:CC:AC:FA:08:54:36:86:7B:3A:B5:04:4D:F0

AT-S.OK

AT+S.TLSCERT=content,1

AT-S.List

AT-S. CA:1

AT-S.Cert:0

AT-S.Key:0

AT-S.Id:1

AT-S.OK

AT+S.MQTTCONN=***.azure-devices.net,8883,,2,***.azure-devices.net/DeviceID/api-version=2016-11-14,SharedAccessSignature sr=***.azure-devices.net&sig=KA%2BSBo

tfK%2BFPFUvKf4Xtb1z3zPLzfplNkMsWmMXu5oo%3D&se=1521901101,DeviceID,,,,,

AT-S.Skip CA

AT-S.Loading:1:2

AT-S.Loading:2:1

AT-S.Loading:3:1

AT-S.Loading:3:1

AT-S.ERROR:111:Request failed

+WIND:87:MQTT Closed:0:0

The mqttconn is now failing because the client certificate and key are not loaded.

Once you have loaded your certificate and key the connect will succede.

Regards,

Elio

________________

Attachments :

b.crt.zip : https://st--c.eu10.content.force.com/sfc/dist/version/download/?oid=00Db0000000YtG6&ids=0680X000006HxnT&d=%2Fa%2F0X0000000b1X%2FOyDsiqBTcQvS0p1fwR5mv7PaSVxP0ZSQyZjWxutZvSA&asPdf=false

b.der.zip : https://st--c.eu10.content.force.com/sfc/dist/version/download/?oid=00Db0000000YtG6&ids=0680X000006HxbM&d=%2Fa%2F0X0000000b1W%2FofVpl.K1RQ1nHFRmb5_Fuj_NEYZxxR1agn63yEtBdDs&asPdf=false

Posted on March 27, 2018 at 11:14

Hello Elio,

thank you for your support.

But I have to generate a self-signed certificate or there is one already available for 

SPWF04S (in order to load it as client certificate)?

I also tried to set 'wifi_eap_type' to '2' (TTLS MSCHAPv2) in order to avoid to load client certificate but when I try to connect with MQTTCONN the reply is always

AT-S.Skip CA

AT-S.Loading:1:2

AT-S.Loading:2:1

AT-S.ERROR:111:Request failed

+WIND:87:MQTT Closed:0:0

Regards,

Fabio.

Posted on March 27, 2018 at 12:45

Hello Fabio,

maybe you are mixing two different subjects.

wifi_eap_* set of configuration variable are used for configuring the access to a WPA Enterprise network.

For establishing a MQTT connection to a broker using TLS authentication/encryption you need:

1) the certificate of the Root CA that signed/issued the server certificate. This is used to verify the identity of the server and is mandatory.

2) in order to identify the client, during the TLS handshake the server may request the client to send its certificate. In this case, the client certificate/private key pair is also needed (the certificate will be sent to the server, while the private key will only be used internally).

Since the certificate in 2) will be used by the server to verify the client identity, the client certificate/key pair is normally issued by the service provider that own the server. If you use a self signed certificate for SPWF04 then the server will not be able to verify the client identity.

Of course, if you whish to exercise with your own broker, then you can use a set of certificates/key created by your own. Appendix A in the Security Application Note (AN4963) gives an example.

Regards,

Elio

Posted on March 27, 2018 at 16:33

Hello Elio,

but can I create a self-signed certificate (with openssl or makecert.exe) and upload it to 'Azure certificates' in order to verify 

SPWF04S?

Sorry but I'm totally a beginner in TLS management.

Regards,

Fabio.

Posted on March 29, 2018 at 11:46

Hello Fabio,

the SPWF04 supports the usage of self signed certificates.

I'm not an expert of Azure, anyway for you use case I believe you should create your service certificate following the Azure policies and upload to Azure.

Then you have to extract the X509 certificate and load to the SPWF04 in the CA section.

Regards,

Elio

Shep Smith
Associate II
Posted on July 06, 2018 at 15:53

Hello Fabio,

I know this reply is a couple months too late, but if you are still having the same issue I think I have a solution. I had to do this for a previous project. For my application I was connecting to the Azure IoTHub sending data using MQTT. Their documentation states that you need a security certificate and a SAS token, but for the longest time I couldn't get it to work because of these 2 issues.

My first issue was getting past the certification:

In order to get past the cert error you have to have the root CA of the Azure server loaded into the flash. I have had success with it living in the APP flash as well as the SD card if you are using external storage. The interface for loading it dynamically never worked for me (the tls.cert commands and such), so I just followed the instructions in the TCP-IP documentation for this module and made my own cert file with the filename being the subject key. I don't know how to attach it to this comment, but the contents of the file are between the triple quotes. Save it to a new file and remove the triple quotes.

filename: e59d5930824758ccacfa085436867b3ab5044df0.ca

content:

'''-----BEGIN CERTIFICATE-----

MIIDdzCCAl+gAwIBAgIEAgAAuTANBgkqhkiG9w0BAQUFADBaMQswCQYDVQQGEwJJ

RTESMBAGA1UEChMJQmFsdGltb3JlMRMwEQYDVQQLEwpDeWJlclRydXN0MSIwIAYD

VQQDExlCYWx0aW1vcmUgQ3liZXJUcnVzdCBSb290MB4XDTAwMDUxMjE4NDYwMFoX

DTI1MDUxMjIzNTkwMFowWjELMAkGA1UEBhMCSUUxEjAQBgNVBAoTCUJhbHRpbW9y

ZTETMBEGA1UECxMKQ3liZXJUcnVzdDEiMCAGA1UEAxMZQmFsdGltb3JlIEN5YmVy

VHJ1c3QgUm9vdDCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAKMEuyKr

mD1X6CZymrV51Cni4eiVgLGw41uOKymaZN+hXe2wCQVt2yguzmKiYv60iNoS6zjr

IZ3AQSsBUnuId9Mcj8e6uYi1agnnc+gRQKfRzMpijS3ljwumUNKoUMMo6vWrJYeK

mpYcqWe4PwzV9/lSEy/CG9VwcPCPwBLKBsua4dnKM3p31vjsufFoREJIE9LAwqSu

XmD+tqYF/LTdB1kC1FkYmGP1pWPgkAx9XbIGevOF6uvUA65ehD5f/xXtabz5OTZy

dc93Uk3zyZAsuT3lySNTPx8kmCFcB5kpvcY67Oduhjprl3RjM71oGDHweI12v/ye

jl0qhqdNkNwnGjkCAwEAAaNFMEMwHQYDVR0OBBYEFOWdWTCCR1jMrPoIVDaGezq1

BE3wMBIGA1UdEwEB/wQIMAYBAf8CAQMwDgYDVR0PAQH/BAQDAgEGMA0GCSqGSIb3

DQEBBQUAA4IBAQCFDF2O5G9RaEIFoN27TyclhAO992T9Ldcw46QQF+vaKSm2eT92

9hkTI7gQCvlYpNRhcL0EYWoSihfVCr3FvDB81ukMJY2GQE/szKN+OMY3EU/t3Wgx

jkzSswF07r51XgdIGn9w/xZchMB5hbgF/X++ZRGjD8ACtPhSNzkE1akxehi/oCr0

Epn3o0WC4zxe9Z2etciefC7IpJ5OCBRLbf1wbWsaY71k5h+3zvDyny67G7fyUIhz

ksLi4xaNmjICq44Y3ekQEe5+NauQrz4wlHrQMz2nZQ/1/I6eYs9HRCwBXbsdtTLS

R9I4LtD+gdwyah617jzV/OeBHRnDJELqYzmp

-----END CERTIFICATE-----'''

After creating this file create a new flash image and load it onto the board. There is a tutorial of how to do this in the wifi-training documentation, in short you are using the tools provided in the latest firmware package STSW-WIFI004 to create a .img file, then transferring it onto the board using various methods. The one that worked the best for me was hosting a local apache server on a laptop connected to the same wifi network as my spwf04sa module, and using the 

at+s.fsupdate=i,xxx.xxx.xx.208,FatVolume.img,80,0,,

where the ip address is where the server is listening, and FatVolume.img is your newly compiled image file.

My second issue was connecting to Azure with the secret, non-documented parameters:

Here is my code that worked finally.

AT+S.MQTTCONN=xxx-xxx.azure-devices.net,443,/$iothub/websocket?iothub-no-client-cert=true,2,xxx-xxx.azure-devices.net/deviceID,SharedAccessSignature sr=xxx-xxx.azure-devices.net%2Fdevices%2FdeviceID&sig=igZeiL7d8T66eWHlf4TDtc55pMlbXBae8f%2FE8pEAJWI%3D&se=1529349013,deviceID,60,15,0,,

And broken down into parameters:

AT+S.MQTTCONN=

host_name: (my host name)

port: (443 for MQTT over TLS)

path: (/$iothub/websocket?iothub-no-client-cert=true) <- These are the secret, non-documented parameters that let Azure know that you are connecting using Websockets (which is by default how this module connects when using MQTT), and as well letting it know that since you are using a SAS key there is no client certificate that will be sent.

security: 2 for TLS

username: my device ID at the end of the endpoint provided by the documentation

password: SAS token URL encoded

clientID: my device ID

the rest are timeout paramters.

Good luck!