I am trying to get my server to securely talk to the module using self-signed https, however using https-client example I am seeing some weird behaviour. It connects to my self-signed https server seemingly without validating the certificate, when I dont' include (resources) or initialise the the server CA it still connects.
When adding self-signed certificates they seem to be successfully parsed (no errors there) and the SSL handshake is performed however there is no check on the validity of the CA.
Any advise?
Have you provided WICED with your root CA certificates using wiced_tls_init_root_ca_certificates()?
If this function is not called then the default behaviour is to turn off certificate verification as it would be impossible to connect to any server using TLS. This was done to ensure TLS examples always work however it is obviously not recommended behaviour for a released product.
In the upcoming WICED-SDK 2.4.1 release the https_client snippet app has been updated to demonstrate its use.
Yes tried that, still when I supply an incorrect self signed server CA it still connects. It does not seem to validate the servers certificate with its own initialised one ( I checked that ssl_set_authmode is set to TLS_VERIFICATION_REQUIRED )
So using the https_client example:
My goal is (obviously) to make sure the module only connects to my servers using tls.
In that case I think it needs further investigation. I'll look into it
For testing purpose I have the following setup
self signed https server: https://82.192.71.222/ displaying 'hello world'
Attached Below is the correct CA, pem format(I cannot attach a file?)
Using openssl to check the validity
openssl s_client -showcerts -connect 82.192.71.222:443 -CAfile server-certificate.pem
-----BEGIN CERTIFICATE-----
MIIB+TCCAWICCQCyeQhQpeHHyDANBgkqhkiG9w0BAQUFADBBMQswCQYDVQQGEwJO
TDELMAkGA1UECBMCTkIxDDAKBgNVBAcTA0VodjEXMBUGA1UEChMOQ29udHJvbFBv
cnRhbHMwHhcNMTQwMTI0MTA1ODE1WhcNMTQwMjIzMTA1ODE1WjBBMQswCQYDVQQG
EwJOTDELMAkGA1UECBMCTkIxDDAKBgNVBAcTA0VodjEXMBUGA1UEChMOQ29udHJv
bFBvcnRhbHMwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALRcYEd3TFGbdvbf
MMMMiHBX4PalWDbidatsRtNyvk2L/uhmzdT4WX39H9y/kOPiT2FLqRfb399o5DBS
NwMn6j3M6f8Ur2l06ybLE7n62xqMVsl9ztW1gUJ8e7mx8SGOa8LEDV9qZSJ1eOeo
HbPll6LFvEHqGtbRZhiQiYUnqkmJAgMBAAEwDQYJKoZIhvcNAQEFBQADgYEAPzPH
5oH1jJSv5uAzNshLY06hmIvazLPjWgwJ9MkHS8L/uC/4mfNLE18L3cTw0b0JkqXZ
eW1QuXsw6CJXoYg9THgsPQgThrs8NvAuEZVRpvM0gHNQ8GmSZ2OgBROEVs2TPqng
EEQNhjp4WJlChMvwq3F75apuHGWl/X/yAm2TIpY=
-----END CERTIFICATE-----
Thank you Jasper for providing a test setup.
I have successfully located the problem and have created a new set of BESL libraries for the 2.4.0 release that fixes the problem.
Once I get them uploaded to the site I will update this thread with the link.
What version of the SDK are you using?
Nice, that's good news, I am using 2.4.0
Per the dialog above, we have loaded the new BESL Libraries and patch for the tls_types.h file into the software downloads area of the site here: SDK 2.4.0: New BESL libraries with patch for the tls_types.h file