Have You had Success with Mutual Client Authentication via TLS with a Web Server?

Tip / Sign in to post questions, reply, level up, and achieve exciting badges. Know more

cross mob
ChMa_3922746
Level 5
Level 5
10 likes received 10 likes given 5 likes given

I am attempting to get the web client based upon the code httpbin_org.c to connect to a web server with mutual TLS authentication.  I can get the client to connect to Jetty Server (a Java server), for example, via TLS, but when I enable authentication on the server, it fails.  (Authentication on the Wiced client works which is good.)  The server logs are tad of a quagmire. 

In case you have had success in getting the Wiced HTTP client to do mutual authentication with an existing server, would you mind letting me know what that server is (was)?  That would be quite helpful.  I've tried Tomcat with even less success... it fails due to frangmented TLS packets, something that mbedtls apparently "doesn't support, yet."  Thanks!

0 Likes
1 Solution

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?

View solution in original post

0 Likes
3 Replies
ChMa_3922746
Level 5
Level 5
10 likes received 10 likes given 5 likes given

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

0 Likes

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.

wireshark.png

0 Likes

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?

0 Likes