Hi all,

I have been using Mbed TLS with mutual certificate-based authentication all the time.

Here is the configuration:

Here is a link to a webinar where I talk about certificate-based authentication and show-case mutual authentication with a Keil development board:

https://www.youtube.com/watch?v=iH4v-aXQ2zQ

Slides are here: http://www2.keil.com/docs/default-source/default-document-library/keil_mbedtls_tutorial_part2.pdf

From what I can tell (trying to connect to your test server myself) you haven’t configured the auth_mode=required on the server side.

Without it the TLS server will not send a CertificateRequest message.

Ciao

Hannes

Hi Gopi,

Thank you very much for your feedback. I double checked all the recommended configuration that you mentioned but it did not help. I really suspect if I have hit a mbedTLS limitation here.

Following our conversation, I tried connecting to the server using openSSL.

Server: https://preview.auth.edgeai.azure.net/api/v1/device/auth

OpenSSL commands:
OpenSSL> s_client -connect preview.auth.edgeai.azure.net:443 -showcerts -debug -msg -state -tls1_2 -cert certificate1.pem -key privateKey1.pem

GET /api/v1/device/auth HTTP/1.1

HOST:preview.auth.edgeai.azure.net

With the above commands, I am able to send the client certificate to the server. I have attached the openSSL logs to show the flow of TLS activity.

As per the logs attached, this is the flow of activity:

1. In the first TLS handshake there is no certificate request and no client certificate sent. I see ClientHello, ServerHello, ServerCertificate, ServerKeyExchange, Server Done, ClientKeyExchange, Change cipher spec, Certificate chain information and Server Cert. Till here, I do see: No client certificate CA names sent.
2. Now when I do a Get call & pass the HOST, client writes that call to the server and in turn the server returns me a “HelloRequest” which is encrypted. Now, this chain of handshake has a CertificateRequest, ClientCertificate, CertificateVerify etc.  I see that 1009 bytes of data been written on the server under the name of client certificate. There is no way to see this certificate because the channel is encrypted now.
3. Lastly, we get HTTP/1.1 200 OK.

Now when I do the same thing using the mbedTLS client on windows 10 PC, I see that the client gets reset during the renegotiation process. Note that the client cert was supposed to be exchanged in the renegotiation period, not the initial handshake. I have attached the logs for mbedTLS client as well and here are the commands that I use to communicate using mbedTLS client.

ssl_client2.exe server_name=preview.auth.edgeai.azure.net server_port=443 debug_level=5 auth_mode=required renegotiate=1 reconnect=1 request_page=/api/v1/device/auth crt_file=certificate1.pem key_file=privateKey1.pem ca_file=server_prev1.pem

I am wondering if this type of exchange of certs is not supported by mbedTLS at all. But it doesn’t work with the remote server since this server looks for the client cert in the renegotiation phase to retain client certificate privacy. Can you confirm that this is a MBEDTLS limitation and have to move to a different library?

Thanks,
Abhilash

Hi Abilash,

Few things to verify

1. On server side – make sure the authentication mode is set to required instead of optional.
1. Test with browser, does Handshake is succeeding if cancelling to select Certificate.
2. If the above were success, then proceed to modify auth_mode on server as below and test once again.
3. mbedtls_ssl_conf_authmode( &conf, MBEDTLS_SSL_VERIFY_REQUIRED ); - insisting Server to Request Certificate.
2. On client side – check does it has a valid Certificate & Key set to TLS Configuration
1. mbedtls_ssl_conf_own_cert( &conf, &clicert, &pkey );

Thanks,

Gopi Krishnan