Unable to open SSL socket to Azure Storage Account with SPWF04Sc module (which worked before)

[RoSchmi]

I'm using a microcontrollerboard FEZ with integrated SPWF04Sc from GHI-Electronics to load sensor data to Azure Table Storage.

My test-application ran fine with transmission through SSL sockets for some days with several hundred transmissions until it stopped working on 05/02/2019. From that on I was not able to get it working again (unsecure transmissions are working).

I found out that Microsoft changed their certificates in these days. An inquiry at Microsoft didn't reveal a cause of the issue.

The used url 'prax47.table.core.windows.net' can be accessed via https protocol on a Windows PC with the browser and with Microsoft Azure Storage libraries. A wireshark analysis of the SPWF04Sc request showed that DNS resolved the named url to CNAME 'table.db6prdstr07a.store.core.windows.net' and ip-address 52.245.40.70. The ssl handshake is aborted with the message: "Alert (Level: Fatal, Description: Certificate Unknown)".

I now suspect that there could be something with the new certificates which prevents ssl access with the SPWF04Sc module working for this url (ssl sockets still can be opened to other none Azure domains). I would appreciate if you could help me the find the cause of this problem.

Best regards

Roland

[After Forever]

The certificate chain shows this:

(1) <- your server's certificate, created on 05/01/2019, signed by (2), sent by the server

(2) <- intermediate certificate, signed by (3), sent by the server

(3) <- last in chain, so should be in your trusted certificates store

[Click Show More]

(3) is "Baltimore CyberTrust Root", which most likely is not included in SPWF04Sc's trusted certificate store. If SPWF04Sc allows to insert new certificate into the trusted store you can download it and insert into there. Otherwise, the solution is to request an updated firmware so that it includes the latest known trusted store. A temporary solution could be to disable checking certificate validity (if the firmware allows such a thing), but I don't recommend it - it undermines all the security.

[RoSchmi]

Thanks for your answer,

the BaltimoreCyperTrustRoot certificate is loaded by the driver of the FEZ board via the AT+S.TLSCERT command to the SPWF04Sx. This root certificate was not changed in the security chain. To doublecheck I freshly loaded this certificate with a browser to use it in my application. As my application ran before with this root certificate I don't think that this might be the cause.

Best regards

Roland

[RoSchmi]

I would politely ask if perhaps someone at ST-Microelectronics ore somebody else could try to open a secure socket to the url named in my first post with the SPWF04Sx module. I'm quite lost if I do not know whether it is definitely not possible or if I made something wrong.

Thanks in advance, every help or answer is appreciated.

Best regards

Roland

[RoSchmi]

Others could reproduce the problem:

https://forums.ghielectronics.com/t/unable-to-open-ssl-socket-to-azure-storage-account-with-wifi-fez-spwf04sx-which-worked-before/22230

[RoSchmi]

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.