Unable to open SSL socket to Azure Storage Account with WiFi FEZ-SpwF04Sx (which worked before)

I have an application which writes sensor data to an Azure Storage table using FEZ with SPWF04Sx WiFi module.
Transmission is through an TLS 1.2 secured SSL socket. In a test the application ran fine for some days with several hundred transmissions. On 05/02/2019 the transmission stopped and from that on my app was not longer able to open a secure socket to the url of my azure account. Unsecure transmissions to this url work and secure sockets
to other domains can be opened. I found out that Microsoft used a new certificate for the account and discussed with Microsoft people if the new certificate could be the reason, but they yet didn’t find the new certificate to be the reason.
So I first would like to ask if someone here who owns the module could try to open a secure socket to the url ‘prax47.table.core.windows.net’ with the SPWF04Sx module and perhaps can see a reason if it doesn’t work.
The root certificate is ‘BaltimoreCyberTrustRoot.crt’.
To simplify the task I made a ready modification of the GHI FEZ WiFi sample (-https://github.com/ghi-electronics/TinyCLR-Samples/tree/master/FEZ/FEZWiFi).
The modified sample is on -https://github.com/RoSchmi/FezWiFiTestRoSchmi
Kind Regards

What is the SHA256 fingerprint of the root certificate? It shows as 16:AF:57:A9:F6:76:B0:AB:12:60:95:AA:5E:BA:DE:F2:2A:B3:11:19:D6:44:AC:95:CD:4B:93:DB:F3:F2:6A:EB for me. What errors are you getting back?

@John_Brochue Thanks John, I’m stuck with this issue since several days.
Yes, it is the same fingerprint. To be sure I once more loaded this certificate with the browser.
In the WiFi.OpenSocket method at the code lines:
var a = cmd.ReadString();
var b = cmd.ReadString();
it returns from var a = cmd.ReadString(); with an empty string but doesn’t return from
var b = cmd.ReadString();
I’d be very interested to see if you see the same behavior.
When I monitored the network traffic with Wireshark I could see that the DNS query answered with a redirection to CNAME table.db6prdstr07a.store.core.windows.net and ip
I suspected that the reason could be that the certificate of the redirected url didn’t match with the names on the first certificate. However people at Microsoft didn’t think this to be the reason.
The certificate of the url was renewed just in the time where my app stopped to work.

1 Like

If somebody is interested, I asked the same question in the STM Forum.

We’ve tried various combinations of certs, common names, domains vs IPs, etc and in every case we have the same failure you do. The second ReadString never gets any data. While we haven’t tested Azure recently on the module, it did at one point work for us.

I ran an SSL test against the server and it appeared to support the ciphers and protocols supported by the module, so there shouldn’t be an issue there.

On the ST thread you mentioned “Alert (Level: Fatal, Description: Certificate Unknown)”, was that an error you saw on a tool like Wireshark?

@John_Brochue Thanks John for looking on this issue. To monitor the network traffic I set up a virtual WiFi Access point on my PC and connected via this Access Point and not directly to via my Router. So I could capture the traffic with Wireshark. If you are interested I can send you my captures but would prefer to send per E-mail. I hope that the people at ST are interested to have a look. A Microsoft Azure employee is interested and asked another team where the answer is still pending. The strange thing is, that it worked before.

After all I think the cause is that Microsoft now uses longer certificates which are above the limits the SPWF04Sx can handle.
St document AN4963 states on page 22: “The maximum allowed size for any file uploaded to the module is 2.5 KB.”
The length of the new certificate is 3.813 Bytes. So the file size of the certificate might be the reason.

That would make sense. I remember seeing somewhere on the ST forums a note to the same effect, that cert processing is limited to certs somewhere between 2-3K, but I can’t find it at the moment. The Wireshark capture may show the chain of certs sent from the server, if you still have it and can check.

Seems that we have to accept that secure socket connection to Azure Storage actually is not possible using the SPWF04Sx module. I fear, the in depths interpretation of the Wireshark capture is beyond my skills.

if you want to send me the CAP file I’ll take a look. brett underscore pound at Hotmail dot com will get me

Also send them to support at ghi… and reference this thread, I’ll take a look too.

@Brett @John_Brochue
Thanks for your help.
The captures are on the way.

I’ve received the captures. I was also able to finally find https://community.st.com/s/question/0D50X00009XkY5USAV/spwf04sx-atshttp-client-error1

The relevant reply from someone at ST is “the 2.5K limits refer to each certificate in the bundle received from a peer. This apply to certificates received from a server (1way/mutual authentication) and to certificates received from a client (mutual authentication)”. Further, “the size of the certificate bundle stored in ‘cert’ section or in ‘tls.cert’ file must be limited to 1475 bytes”.

Looking at your capture, the final, server, cert for Azure comes in at 3,813 bytes, which is over the stated limit. The intermediate cert, which hasn’t changed, is 1,464 bytes.

At this point I’d say the problem is the server cert is too big. Without a capture of the original working cert, though, it’s not possible to say for sure.


In the meantime I got this answerer from a Microsoft Employee who was concerned with my issue:
“I received the information from our product group related to the larger certificate is due to the amount of information inside. The renewed certificates have more information and for that reason the file size increased.
There are no much more we can do on this as the information on certificate cannot be reduced, and apparently there are no limitations on SSL protocol for the file size of the certificates.
In addition to my previous suggestions, product group suggested as another workaround to use the http and a VNET from your devices (or private device’s network) and the storage, to secure the data in transit.”

So at the moment we can only hope that your next WiFi module candidate will support the new larger certificates.

1 Like

I concur, the 3813 byte cert in the trace will go over the limit and that’s why you eventually get the certificate unknown error thrown by the module.

1 Like

Being able to work with Azure is a high priority for us and that is one of the many sites we test when evaluating new network modules.

Indeed, for now, using a proxy that you connect to over HTTP that forwards to Azure HTTPS is one workaround, if it works for you.


If I were Microsoft, I would put emphasis on the ability of our online-services to be used by as many IoT-Devices as possible (as long as security demands are not neglected)

except here ST have done what looks to be an arbitrary restriction on bytes used, that isn’t restricted in the standard… And the cert is perfectly valid, it’s just the interpretation of that by the ST module, because of the size restriction. If they could only fix their code in/on the device…

1 Like

The product I have on my desk works fine with azure… Too bad you do not have one :wink:

Oops I said too much

1 Like

New WiFi Board and FEZ with more Ram (F411). When can we have it?

1 Like