2018-03-26 03:15 AM
2018-03-26 04:59 AM
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.
2018-03-26 08:57 AM
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/VTANBgkqhkiG9w0BAQsFADBaMQswCQYDVQQGEwJJRTESMBAGA1UEChMJQmFsdGltb3JlMRMwEQYDVQQLEwpDeWJlclRydXN0MSIwIAYDVQQDExlCYWx0aW1vcmUgQ3liZXJUcnVzdCBSb290MB4XDTE2MDUyMDEyNTEyOFoXDTI0MDUyMDEyNTEyOFowgYsxCzAJBgNVBAYTAlVTMRMwEQYDVQQIEwpXYXNoaW5ndG9uMRAwDgYDVQQHEwdSZWRtb25kMR4wHAYDVQQKExVNaWNyb3NvZnQgQ29ycG9yYXRpb24xFTATBgNVBAsTDE1pY3Jvc29mdCBJVDEeMBwGA1UEAxMVTWljcm9zb2Z0IElUIFRMUyBDQSAxMIICIjANBgkqhkiG9w0BAQEFAAOCAg8AMIICCgKCAgEAjvPxhHV3vL7JpPUWpVMrUGCZ3Nh92SS14XJJN0j+2oaTo30dmksQTXd5fmWpfG424kfUNknQzCQCJxTirnHN2Vd0PBBWGZJKh2L545CNXt7RQRsaph9AoiwejlXXJthoQqvsDd7dXmGVs6xsgc6o4K2vX8qm5FFoLif9VCpxpMy7fpLx9lNRBTHQGYKwymPQ8koAC830aUv0WpZWOSbJnUsKYzQygKUE5eoot8EAwG0a8CjUSo+ArHMZ2PUWL62uCJdiBiz+56XwrUFTf40rMcMUcyHd43hjnFGGtaJIScB5CBVDACuZuEvgx1cHbMS5plQtAVPyo/KkzNnBVPOIzeRME9OKMyFYrRi/vjmBcDlpN/hbpGPvCQffhxpix5oIxdEdXmJ2Ad1p5ji7RLAtTTrGLoDgYHJb8szmjlw6IR5dsDkrveoTy5bLtmp0jI68DhCfG6VAQY+RXHanDvGqOoe3DHffcWovKGFCLZAPcgWrZ+DBe8ucQJrECghEjHw9uqkOHrHZIr0fX0Fqc1T2ZuKg+aY53tJ382kEv7e7PMST/3IEHLU2nWh/3/o5T7L2j7kc/63tDhUI44Z88khJd5cW9v0A9k+mXm/nOcBRZT3rsZcw7Oqec/weLKDfi89zX7UOBkIXJpXs2Kkn0NBllFziP8ooKaUg9MjdXbT/5t0CAwEAAaOCAUIwggE+MB0GA1UdDgQWBBRYiJ/W3JxIIrcUPv+EiOjmhf/6fTAfBgNVHSMEGDAWgBTlnVkwgkdYzKz6CFQ2hns6tQRN8DASBgNVHRMBAf8ECDAGAQH/AgEAMA4GA1UdDwEB/wQEAwIBhjAnBgNVHSUEIDAeBggrBgEFBQcDAQYIKwYBBQUHAwIGCCsGAQUFBwMJMDQGCCsGAQUFBwEBBCgwJjAkBggrBgEFBQcwAYYYaHR0cDovL29jc3AuZGlnaWNlcnQuY29tMDoGA1UdHwQzMDEwL6AtoCuGKWh0dHA6Ly9jcmwzLmRpZ2ljZXJ0LmNvbS9PbW5pcm9vdDIwMjUuY3JsMD0GA1UdIAQ2MDQwMgYEVR0gADAqMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy5kaWdpY2VydC5jb20vQ1BTMA0GCSqGSIb3DQEBCwUAA4IBAQAwmsadav3vkwgMvoJ3+XagbZ57MCN7qCla9Go+xwsMlt+4S1LkDZw47XhjtXPAHB874Kf/f0lRlTK40Jup5c+WA4GA1UphGP7Easbff0FGIpyAZusPQqDk86Qho5jQenT2jOjD0iuqK84RWRlE51wHCULr1/0VTblvbEQ1Joe6oztosIHnIMl/EwLzzKufHJVQy65kgLuHCl3OpmuyfeM9NuIpUbcl/NAJ47CtxGIuPn6FJrL2r/dtMXPGGZipcpMCzsoLPTzs2XDogPUWq3hqh03GgTeoCnaBBqjvF2B8cBATPDjXM0zkN2UI+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:1AT-S.Cert:0AT-S.Key:0AT-S.Id:1AT-S.OKBut the problem remains: when I send MQTTCONN command, the reply is always the same:
AT-S.Skip CA
AT-S.Skip CAAT-S.Certificate Error:23AT-S.ERROR:111:Request failedWhere I'm wrong?
Thank you.
Fabio.
2018-03-26 11:19 AM
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 :
2018-03-27 04:14 AM
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.
2018-03-27 05:45 AM
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
2018-03-27 09:33 AM
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.
2018-03-29 04:46 AM
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
2018-07-06 06:53 AM
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+gAwIBAgIEAgAAuTANBgkqhkiG9w0BAQUFADBaMQswCQYDVQQGEwJJRTESMBAGA1UEChMJQmFsdGltb3JlMRMwEQYDVQQLEwpDeWJlclRydXN0MSIwIAYDVQQDExlCYWx0aW1vcmUgQ3liZXJUcnVzdCBSb290MB4XDTAwMDUxMjE4NDYwMFoXDTI1MDUxMjIzNTkwMFowWjELMAkGA1UEBhMCSUUxEjAQBgNVBAoTCUJhbHRpbW9yZTETMBEGA1UECxMKQ3liZXJUcnVzdDEiMCAGA1UEAxMZQmFsdGltb3JlIEN5YmVyVHJ1c3QgUm9vdDCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAKMEuyKrmD1X6CZymrV51Cni4eiVgLGw41uOKymaZN+hXe2wCQVt2yguzmKiYv60iNoS6zjrIZ3AQSsBUnuId9Mcj8e6uYi1agnnc+gRQKfRzMpijS3ljwumUNKoUMMo6vWrJYeKmpYcqWe4PwzV9/lSEy/CG9VwcPCPwBLKBsua4dnKM3p31vjsufFoREJIE9LAwqSuXmD+tqYF/LTdB1kC1FkYmGP1pWPgkAx9XbIGevOF6uvUA65ehD5f/xXtabz5OTZydc93Uk3zyZAsuT3lySNTPx8kmCFcB5kpvcY67Oduhjprl3RjM71oGDHweI12v/yejl0qhqdNkNwnGjkCAwEAAaNFMEMwHQYDVR0OBBYEFOWdWTCCR1jMrPoIVDaGezq1BE3wMBIGA1UdEwEB/wQIMAYBAf8CAQMwDgYDVR0PAQH/BAQDAgEGMA0GCSqGSIb3DQEBBQUAA4IBAQCFDF2O5G9RaEIFoN27TyclhAO992T9Ldcw46QQF+vaKSm2eT929hkTI7gQCvlYpNRhcL0EYWoSihfVCr3FvDB81ukMJY2GQE/szKN+OMY3EU/t3WgxjkzSswF07r51XgdIGn9w/xZchMB5hbgF/X++ZRGjD8ACtPhSNzkE1akxehi/oCr0Epn3o0WC4zxe9Z2etciefC7IpJ5OCBRLbf1wbWsaY71k5h+3zvDyny67G7fyUIhzksLi4xaNmjICq44Y3ekQEe5+NauQrz4wlHrQMz2nZQ/1/I6eYs9HRCwBXbsdtTLSR9I4LtD+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!