I am trying to connect to a third party API which have a mutual TLS authentication setup enabled. So I am supposed to install my client certificates inside my key store and send it on TLS handshake process.

For this process I am right now using commodo positive SSL as client side certificate. When I make TLS calls, Evnthough server is requesting a certificate, Client is not sending one. And when I checked SChannel Log, I can see a warning like this

The remote server has requested TLS client authentication, but no suitable client certificate could be found. An anonymous connection will be attempted. This TLS connection request may succeed or fail, depending on the server's policy settings.

SO my doubt is like this, Am I using the correct type of X509 certificate for the purpose of client side authentication? Do I need to use any other specific type? As my current certificate is not getting send.

up vote 1 down vote accepted

It depends. X.509v3 certificates usually come with an "Extended Key Usage" extension field, which contains a list of permitted usages (EKUs).

  • Regular web server certificates contain the "TLS Server Authentication" usage (sometimes shown as "TLS Web Server", but it really is not Web-specific at all).

  • To act as a client, you need a certificate with "TLS Client Authentication" (again often shown as "TLS Web Client", despite having nothing Web-specific in it).

It is quite common for regular "web server" SSL certificates to contain both usages – for example, I'm looking at certificates issued by Let's Encrypt and DigiCert, and all of them contain both usages, therefore can be used for client/mutual authentication.

However, it's possible that in some other CAs, especially private organization CAs, most certificates have one usage or the other, but rarely both.

For example, OpenVPN used to strictly require "only TLS Client" (rather than "at least TLS Client" as other programs do), therefore its easy-rsa script issues server-only and client-only certificates but not the mixed kind.


So you should examine your certificates and make sure they contain the required EKU. Practically any certificate tool will do the job – for example, the Certificate properties dialog in Windows will show this under "V3 Extensions", as will web browsers, openssl x509, certtool, certutil, etc.

Also worth remembering if you run your own internal CA: If you use an intermediate CA certificate, pay attention to it as well. Intermediates aren't required to have an EKU extension, but if they do have it, then all certificates issued by that intermediate are constrained by it. (If you obtain the certs commercially, shouldn't need to worry about it.)


Additionally, the certificate will have a basic "Key Usage" field which contains some very general restrictions: e.g. "Digital Signature" means the certificate is allowed to sign data (and therefore allows EDH/EECDH handshake in TLS); "Key Agreement" appears to be for static-DH/ECDH; "Key Encipherment" allows static-RSA handshakes.

The official X.509v3 documentation is very confusing in what usages are needed when... Commercial CAs will usually get this field right. But for private CAs it's worth double-checking.

  • EKU is showing both options for me (Server Authentication (1.3.6.1.5.5.7.3.1) Client Authentication (1.3.6.1.5.5.7.3.2)) Thanks – Athul k Surendran Feb 21 at 8:42
  • Then the certificate should be good. (But check its intermediate chain just in case.) The problem might be with your software, e.g. maybe you installed the cert to the wrong place, or maybe you didn't install the private key (.pfx file)? – grawity Feb 21 at 8:43
  • I am using a certificate from COmodo CA. So hope, it won't matter to my case – Athul k Surendran Feb 21 at 8:46
  • The CA name doesn't matter. That's not what I'm asking you to check. – grawity Feb 21 at 8:51
  • Ok. My understanding was if its as I am using commercial CA (Comodo) I am not supposed to check chain. But will check it now anyway. Or if I am missing anything pls explain lil more – Athul k Surendran Feb 21 at 8:58

Your Answer

 

By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

Not the answer you're looking for? Browse other questions tagged or ask your own question.