IIS Server 403.7 error not recognizing Client Certificate for ASP.NET app

Question

I am attempting to perform mutual authentication between 2 systems but server keeps returning 403.7 even though the client is possessing the correct certificate. I have done some diagnosis and it seems that although the app is processing the certificate, it is some how being "discarded" somewhere (when using a wrong cert, it doesnt return 403.16 but 403.7).

Some background below

Server - ASP.NET Webservice on IIS, WSDL accessible for SOAP calls. Has 2 root certs, one for server name, other for authenticating client certificates. Certs are all self-signed for local area testing.

Client - ASP.NET application on IIS with SOAP calls to server. Issued client certificate from server and has both root certs installed as Trusted CAs. Accesses a dll to perform SOAP calls specifically for the server. Client cert is a X509Certificate2 and client access it via file (Not cert store).

The client is actually a server for another web application and there needs to be an interface between client and server. Client and server will be on different networks and mutual authentication via SSL certificates are required. Connection between both systems are TLS1.2

Diagnosis performed thus far

• Client able to compile the same dll and run as a console app, picks up the correct client cert and authenticate successfully with server (Proves code is working). When deliberately selecting the wrong cert, 403.16 is returned (Correct behavior)
• Client browser able to access server page and authenticate with correct client cert (Proves cert is working)
• Client web app using the dll file is able to access and process the correct cert (proves that web app is able to access cert). When deliberately selecting the wrong cert, 403.7 is still returned and not 403.16. (Where is my cert going?)
• Wireshark indicates that both sides are talking but i am unable to get wireshark to perform decryption to provide more in-depth details (Working on this)

The Problem

As per the title, server keeps returning 403.7 (via IIS Failed-Request-Tracing) even though the client web application is able to access the file. Since the client is a web app running on IIS and interfacing with server, i would assume that the client IIS service is handling these web requests.

I am suspecting that it has something to do with either

• client IIS accounts and/or its rights
• Some funky windows/TLS/SSL protocol i am not aware off
• IIS settings?

Appreciate some insight on how to debug further or address this issue?

Answer 1

Well after going 1 big round to test and troubleshoot via wireshark, it seems that the application couldnt access the private key because there was none to begin with. Quick change from .cer to .pfx with the private key quickly fixed that.

However it still doesnt explain why the console application could access the server with a .cer instead of a .pfx (no private key, could be something to do with IIS but i am just making an assumption. )

A similiar case occured with another development application however they were using a .pfx file with the private key. Further debugging indicates that they were using X509Certificate instead of X509Certificate2. Well the issue for this case is due to the fact that they couldnt not access the private key with the older class.

In summary, - Ensure private key is present for the application to access in order to properly present the correct certificate or else no certificate will be presented at all.