IIS服务器403.7错误无法识别ASP.NET应用程序的客户端证书

IIS服务器403.7错误无法识别ASP.NET应用程序的客户端证书,iis,soap,tls1.2,client-certificates,mutual-authentication,Iis,Soap,Tls1.2,Client Certificates,Mutual Authentication,我试图在两个系统之间执行相互身份验证,但服务器始终返回403.7,即使客户端拥有正确的证书。我做了一些诊断,看起来虽然应用程序正在处理证书,但它是如何在某个地方被“丢弃”的(当使用错误的证书时,它不会返回403.16,而是返回403.7) 下面是一些背景 服务器-IIS上的ASP.NET Web服务,可用于SOAP调用的WSDL。具有2个根证书,一个用于服务器名称,另一个用于验证客户端证书。证书都是自签名的,用于本地测试 客户端-IIS上的ASP.NET应用程序,对服务器进行SOAP调用。已从服

我试图在两个系统之间执行相互身份验证,但服务器始终返回403.7,即使客户端拥有正确的证书。我做了一些诊断,看起来虽然应用程序正在处理证书,但它是如何在某个地方被“丢弃”的(当使用错误的证书时,它不会返回403.16,而是返回403.7)

下面是一些背景 服务器-IIS上的ASP.NET Web服务,可用于SOAP调用的WSDL。具有2个根证书,一个用于服务器名称,另一个用于验证客户端证书。证书都是自签名的,用于本地测试

客户端-IIS上的ASP.NET应用程序,对服务器进行SOAP调用。已从服务器发出客户端证书,并且已将两个根证书安装为受信任的CA。访问dll以专门为服务器执行SOAP调用。客户端证书是X509Certificate2,客户端通过文件(而不是证书存储)访问它

客户端实际上是另一个web应用程序的服务器,在客户端服务器之间需要有一个接口客户端和服务器
将位于不同的网络上,需要通过SSL证书进行相互身份验证。两个系统之间的连接为TLS1.2

迄今为止进行的诊断
  • 客户端能够编译相同的dll并作为控制台应用程序运行,获取正确的客户端证书并成功通过服务器验证(证明代码正常工作)。当故意选择错误的证书时,返回403.16(正确行为)
  • 客户端浏览器能够访问服务器页面并使用正确的客户端证书进行身份验证(证明证书有效)
  • 客户端使用dll文件的web应用程序能够访问和处理正确的证书(证明web应用程序能够访问证书)。当故意选择错误的证书时,仍然返回403.7,而不是403.16。(我的证书要去哪里?)
  • Wireshark表示双方都在讨论,但我无法让Wireshark执行解密以提供更深入的细节(正在处理此问题)
问题 根据标题,服务器不断返回403.7(通过IIS失败的请求跟踪),即使客户端web应用程序能够访问该文件。由于客户端是一个运行在IIS上并与服务器交互的web应用程序,因此我假设客户端IIS服务正在处理这些web请求

我怀疑这两者都有关系

  • 客户端IIS帐户和/或其权限
  • 一些我不知道的时髦的windows/TLS/SSL协议
  • IIS设置

感谢您对如何进一步调试或解决此问题有所了解?

在通过wireshark进行了一轮测试和故障排除之后,应用程序似乎无法访问私钥,因为一开始没有私钥。使用私钥从.cer快速更改为.pfx很快就解决了这个问题

但是,它仍然没有解释为什么控制台应用程序可以使用.cer而不是.pfx访问服务器(没有私钥,可能与IIS有关,但我只是做一个假设)

另一个开发应用程序也出现了类似的情况,但他们使用的是带有私钥的.pfx文件。进一步调试表明他们使用的是X509Certificate,而不是X509Certificate2。这个案例的问题是因为他们不能使用旧类访问私钥

总之,
-确保应用程序访问的私钥存在,以便正确显示正确的证书,否则根本不会显示任何证书

在通过wireshark进行了一轮测试和故障排除之后,应用程序似乎无法访问私钥,因为一开始没有私钥。使用私钥从.cer快速更改为.pfx很快就解决了这个问题

但是,它仍然没有解释为什么控制台应用程序可以使用.cer而不是.pfx访问服务器(没有私钥,可能与IIS有关,但我只是做一个假设)

另一个开发应用程序也出现了类似的情况,但他们使用的是带有私钥的.pfx文件。进一步调试表明他们使用的是X509Certificate,而不是X509Certificate2。这个案例的问题是因为他们不能使用旧类访问私钥

总之, -确保应用程序访问的私钥存在,以便正确显示正确的证书,否则根本不会显示任何证书