I see that Jetty Server (being a Java-based server) also suffers from the same problem:
WICED/security/BESL/mbedtls_open/library/ssl_tls.c:3185: handshake message: msglen = 114, type = 12, hslen = 365
WICED/security/BESL/mbedtls_open/library/ssl_tls.c:3247: TLS handshake fragmentation not supported
WICED/security/BESL/mbedtls_open/library/ssl_tls.c:3838: mbedtls_ssl_read_record_layer() returned -28800 (-0x7080)
WICED/security/BESL/mbedtls_open/library/ssl_cli.c:2463: mbedtls_ssl_read_record() returned -28800 (-0x7080)
WICED/security/BESL/mbedtls_open/library/ssl_tls.c:7021: <= handshake
WICED/security/BESL/mbedtls_open/library/ssl_tls.c:7646: => write close notify
WICED/security/BESL/mbedtls_open/library/ssl_tls.c:7662: <= write close notify
WICED/security/BESL/mbedtls_open/library/ssl_tls.c:7794: => free
This appears to be an mbedtls deficiency. So... if anyone has tested this successfully with another brand of server, I'm all ears
I created a simple Java server with a KeyStore and TrustStore to decouple off-the-shelf servers from the problem. With a Firefox browser client, mutual authentication works, so the Java Server appears sound.
When the WICED http client connects to the server, however, I see that it fails to provide a certificate when it is time to do so (see the capture, below). mbedtls knows it got a request though:
WICED/security/BESL/mbedtls_open/library/ssl_tls.c:3185: handshake message: msglen = 147, type = 13, hslen = 147
WICED/security/BESL/mbedtls_open/library/ssl_tls.c:3853: <= read record
WICED/security/BESL/mbedtls_open/library/ssl_cli.c:2908: got a certificate request
The server reports:
javax.net.ssl.SSLHandshakeException: Empty server certificate chain
So, I am thinking that either mbedtls is not happy with the Cert Request sent by the server, or something else is broken in mbedtls.
After a lot of digging around, I found that mbedtls was not providing the client certificate when requested by the server. The debug logs from mbedtls brought me to the file ssl_tls.c, and this function:
int mbedtls_ssl_write_certificate( mbedtls_ssl_context *ssl )
Within this function, I found that crt = mbedtls_ssl_own_cert( ssl ) was returning NULL even though I had called wiced_tls_init_root_ca_certificates() with a valid certificate. So, I modified each call to force the assignment of the device's certificate to crt if it returned NULL:
crt = mbedtls_ssl_own_cert( ssl );
if ((crt == NULL) && (root_ca_certificates != NULL)) crt = root_ca_certificates;
(Note that I needed to add extern mbedtls_x509_crt* root_ca_certificates; near the start of the file ssl_tls.c.)
With this workaround, the httpbin_org.c client is able to engage in mutual authentication with my (basic) Java server. Also, the HTTPS server I have concurrently running on the device is not adversely affected (it simultaneously can mutually authenticate with a Java client and web browser).
Is this the result of a deficiency in WICED's incorporation of mbedtls?