IE is not sending Client certificate in TLS mutual authentication

Question

I am trying to establish a TLS mutual authentication with third party API. Client certificate is configured fine and when I try to access the end point url through Chrome it works fine(Chrome asks to confirm the certificate in a message box and when I does it the page displays with its content).

Same thing when I try to do with IE it is not working and showing this message

Cannot securely connect to this page

This might be because the site uses outdated or unsafe TLS security settings. If this keeps happening, try contacting the website’s owner.

Your TLS security settings aren’t set to the defaults, which could also be causing this error.

So I logged the details to Wireshark, And this is how it looks When I digged more in to details I can see that the client certificate was never sent on step 9(TLSv1.2 379 Certificate, Client Key Exchange, Change Cipher Spec, Encrypted Handshake Message).

And in Step 10 this is the error I am getting

What can be the reason behind this behavior?

Update: When I try to access smae end point through code and checked SChannel logs, 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.

Answer 1

Seeing as how it works in chrome but not IE I think it's safe to say that problem is IE specific. Since you've already added the certificate, it sounds like the certificate is being automatically selected, but not sent. You're also getting an message that says "Your TLS security settings aren’t set to the defaults" in your error. I've found some information that might apply to your scenario here. Basically it says that IE can't use TLS 1.2 successfully if SSL 2.0 is enabled. Can you check this setting?

settings pic

Go to internet options -> advance. Look for "Use SSL 2.0" I don't see the option in my persumably since I'm using later versions of windows/IE where SSL 2.0 is not an option, but you might have it, depending on which version(s) you're using.

Answer 2

I suffered a similar issue with a certificate that had a broken certificate revokation list (crl).

I was able to track this down with Fiddler, which showed a request to the failing CRL. You should see the same with WireShark. Moreover, when using Fiddler to decrypt the SSL traffic, there was no issue, since Fiddler then uses its own self-signed certificate to communicate with the browser.

I'm not sure that's going to make any difference in your case, since it's the client certificate that might be the problem.

For a temporary (unsafe!) work-around, you could disable clr checks. If this solves the problem, then the crl is really the problem and you will need to somehow request a proper certificate without a faulty crl.