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/authhttps://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpreview.auth.edgeai.azure.net%2Fapi%2Fv1%2Fdevice%2Fauth&data=04%7C01%7CAbhilash.Iyer%40microsoft.com%7Cff2b3de3fd9446896f2d08d8199e7415%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637287515629168022%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C-1&sdata=A36YgzdDiZFCKVUM856JojGXBF%2BqPuHnmNJBBBZ1vnQ%3D&reserved=0 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 From: Subramanian Gopi Krishnan gopikrishnan.subramanian@kone.com Sent: Sunday, June 28, 2020 8:58 PM To: Abhilash Iyer Abhilash.Iyer@microsoft.com Subject: [EXTERNAL] RE: [mbed-tls] Mutual Authentication in TLS handshake - No client certificate passed

Hi Abilash,

Few things to verify

1. On server side - make sure the authentication mode is set to required instead of optional. * Test with browser, does Handshake is succeeding if cancelling to select Certificate. * If the above were success, then proceed to modify auth_mode on server as below and test once again. * 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 * mbedtls_ssl_conf_own_cert( &conf, &clicert, &pkey );

Thanks, Gopi Krishnan

From: mbed-tls <mbed-tls-bounces@lists.trustedfirmware.orgmailto:mbed-tls-bounces@lists.trustedfirmware.org> On Behalf Of Abhilash Iyer via mbed-tls Sent: Monday, June 22, 2020 2:00 PM To: mbed-tls@lists.trustedfirmware.orgmailto:mbed-tls@lists.trustedfirmware.org Subject: [mbed-tls] Mutual Authentication in TLS handshake - No client certificate passed

This message is from an external sender. Be cautious, especially with links and attachments. Hello,

I am trying to incorporate Mutual Authentication TLS in my hardware. For testing the mutual authentication in TLS, I setup a demo service which would request a client certificate in the TLS handshake. I used MS Edge, Google Chrome to test whether the service requests a client certificate during the TLS 1.2 handshake. When I ping the website, I do receive a request for a client certificate as shown in the image below. On selecting a certificate, I am able to access the website.

Link to the demo service: https://serviceforsomsecurity.azurewebsites.net/https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fserviceforsomsecurity.azurewebsites.net%2F&data=02%7C01%7CAbhilash.Iyer%40microsoft.com%7C2139518c2e794fceca2608d81be0938c%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637289998651943936&sdata=9BTvRkit9yVDr2bRewov6QWMWUrJR4wt0bOz%2BFQAKBA%3D&reserved=0

[A screenshot of a cell phone Description automatically generated]

The above validates that the service requires the client to provide the client certificate during the TLS handshake.

Now, when I test this with the sample mbedTLS ssl_client2.c program: https://github.com/ARMmbed/mbedtls/blob/development/programs/ssl/ssl_client2...https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FARMmbed%2Fmbedtls%2Fblob%2Fdevelopment%2Fprograms%2Fssl%2Fssl_client2.c&data=02%7C01%7CAbhilash.Iyer%40microsoft.com%7C2139518c2e794fceca2608d81be0938c%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637289998651943936&sdata=WTYSFVscHK6x76n5cb7YEDtujxD49UuOj%2FXUSrz2TSQ%3D&reserved=0, the client does not send a certificate at all. The following are the steps that I carry out to test the TLS connection with my service with the sample mbedTLS ssl_client2.exe : 1. Open the mbedTLS.sln and build the ssl_client2 project. This creates a ssl_client2.exe under the Debug folder. 2. ssl_client2.exe server_name=serviceforsomsecurity.azurewebsites.net server_port=443 debug_level=3 auth_mode=required reconnect=1 crt_file=cert.pem key_file=key.pem ca_file=Digicert.cer force_version=tls1_2 The above command to test whether the client sends the client certificate during handshake. Here's the log: [A screenshot of a computer Description automatically generated]

As you can see, in 3025 client receives: got no certificate request and then followed by server hello done at 3157. And then at 2080 & 2094, client skips writing certificate; during this handshake.

3. Then I tried including renegotiation flag: ssl_client2.exe server_name=serviceforsomsecurity.azurewebsites.net server_port=443 debug_level=3 auth_mode=required reconnect=1 crt_file=cert.pem key_file=key.pem ca_file=Digicert.cer force_version=tls1_2 renegotiate=1

Even in this case, the client does not get the certificate and abruptly ends during renegotiation due to timeout.

I have included both the log files below for complete handshake review. [ssl_client_without_renegotiation.txt and ssl_client_with_renegotiation.txt]

Can you please let me know how to debug this client certificate problem? It will be really a great help!

Million thanks in advance. Regards, Abhilash