2017-11-15 10:45 AM
We're using the SPWF04SA and trying to connect to various SSL sites. Some work while others don't. We used the steps outlined in AN4963 for retrieving the certificates, all done in DER encoded binary X.509 format. We get the same results whether we use SOCKON or HTTPGET in every case. All sites work fine using regular http over port 80, though the returned data is sometimes empty because the site does a redirect to the SSL version. ssllabs.com was also used to get some information on the certificates.
Using the following commands, and the given subject key ID for the certificate, connecting to meta.stackexchange.com works fine:
SubjectKeyId: B1:3E:C3:69:03:F8:BF:47:01:D4:98:26:1A:08:02:EF:63:64:2B:C3
AT+S.TLSCERT=content,2<cr>AT+S.TLSCERT=ca,969<cr><data>AT+S.HTTPGET=meta.stackexchange.com,/,443,2,,,,<cr>However, attempting to do the same to ghi-test-iot.azure-devices.net fails with the errors below:
SubjectKeyId: E5:9D:59:30:82:47:58:CC:AC:FA:08:54:36:86:7B:3A:B5:04:4D:F0
AT+S.TLSCERT=content,2<cr>AT+S.TLSCERT=ca,891<cr><data>AT+S.HTTPGET=ghi-test-iot.azure-devices.net,/,443,2,,,,<cr>AT-S.Certificate Error:22
AT-S.Http Client Error:2AT-S.ERROR:111:Request failedIs it because the second certificate in the chain uses RSA 4096 bits, see
? If so, is there future support planned for 4096 bits or is there a different way to connect to Azure IoT Hub on the SPWF04SA? We were able to connect to Azure using anonymous authentication on the SPWF01SA.11, though that isn't really a workable solution. We haven't found a way to do anonymous authentication in the SPWF04SA regardless.
We have a similar failure for www.ebay.com.
SubjectKeyId: 7F:D3:65:A7:C2:DD:EC:BB:F0:30:09:F3:43:39:FA:02:AF:33:31:33
AT+S.TLSCERT=content,2<cr>AT+S.TLSCERT=ca,1239<cr><data>AT+S.HTTPGET=www.ebay.com,/,443,2,,,,<cr>AT-S.Http Client Error:2
AT-S.ERROR:111:Request failedWe don't get the certificate error we got above for Azure, though it still fails. One interesting thing is that the same certificate, VeriSign Class 3 Public Primary Certification Authority - G5, works fine for www.amazon.com. Both sites use it as their root CA.
Lastly, www.ssllabs.com also fails. The site itself shows that it has two potential root certificate paths, both fail. The first below is 'Entrust Root Certification Authority' while the second is 'Entrust Root Certification Authority - G2'.
SubjectKeyId: 68:90:E4:67:A4:A6:53:80:C7:86:66:A4:F1:F7:4B:43:FB:84:BD:6D
AT+S.TLSCERT=content,2<cr>AT+S.TLSCERT=ca,1173<cr><data>AT+S.HTTPGET=www.ssllabs.com,/,443,2,,,,<cr>SubjectKeyId: 72:26:7A:D0:1E:EF:7D:E7:3B:69:51:D4:6C:8D:9F:90:12:66:AB
AT+S.TLSCERT=content,2<cr>AT+S.TLSCERT=ca,1090<cr><data>AT+S.HTTPGET=www.ssllabs.com,/,443,2,,,,<cr>AT-S.Http Client Error:2
AT-S.ERROR:111:Request failedInterestingly both www.ebay.com and www.ssllabs.com work in the SPWF01SA.11. Neither work here in the SPWF04SA.
In this thread,
https://community.st.com/0D50X00009XkXDeSAN
, and others, there has been mention of a 1.1.0 firmware and documentation update coming out soon for several weeks now. Has there been any more news on when we should expect that release? Another thread I can't find at the moment mentioned support for elliptic curves is coming in a future release, is it expected in 1.1.0?
null2017-11-15 11:13 PM
Yes, ECC are part of FW1.1.0. Ready to be published. This means you don't need huge certificates (RSA 4096 bits), but you can achieve higher security by smaller certificates.
Example: a certificate signed with RSA-2048 is usually 1.5 KBs big (but can reach also 2 KBs), while a certificate signed with ECDSA-P256 (an ECC algorithm which has a security strength higher than RSA-2048) can be ~600 bytes.