IIS 服务器 403.7 错误无法识别 ASP.NET 应用程序的客户端证书
IIS Server 403.7 error not recognizing Client Certificate for ASP.NET app
我正在尝试在 2 个系统之间执行相互身份验证，但即使客户端拥有正确的证书，服务器仍保持 returning 403.7。我已经做了一些诊断，似乎虽然应用程序正在处理证书，但它在某个地方是 "discarded" 的（当使用错误的证书时，它不是 return 403.16 而是 403.7）。
下面是一些背景
Server - ASP.NET IIS 上的 Web 服务，SOAP 调用可访问 WSDL。有 2 个根证书，一个用于服务器名称，另一个用于验证客户端证书。本地测试的证书都是self-signed。
Client - ASP.NET IIS 上的应用程序，对服务器进行 SOAP 调用。从 服务器 颁发客户端证书，并将两个根证书安装为受信任的 CA。访问一个 dll 以执行专门针对 服务器 的 SOAP 调用。客户端证书是 X509Certificate2，客户端 通过文件（不是证书存储）访问它。
客户端实际上是另一个网络应用程序的服务器，客户端和之间需要一个接口服务器。 Client 和 server 将在不同的网络上，并且需要通过 SSL 证书进行相互身份验证。两个系统之间的连接都是 TLS1.2
到目前为止进行的诊断
- Client 能够编译相同的 dll 和 运行 作为控制台应用程序，获取正确的客户端证书并成功通过服务器进行身份验证（证明代码正在运行） .故意选择错误的证书时，returned（正确行为）
403.16
- 客户端 浏览器能够访问 服务器 页面并使用正确的客户端证书进行身份验证（证明证书有效）
- Client 使用 dll 文件的网络应用能够访问和处理正确的证书（证明网络应用能够访问证书）。当故意选择错误的证书时，403.7 仍然是 returned 而不是 403.16。 （我的证书去哪儿了？）
- Wireshark 表示双方都在通话，但我无法让 wireshark 执行解密以提供更多 in-depth 详细信息（正在处理）
问题
根据标题，服务器保持 returning 403.7（通过 IIS Failed-Request-Tracing）即使 客户端 网络应用程序能够访问该文件.由于 客户端 是一个 Web 应用 运行 在 IIS 上连接并与 服务器 交互，我假设 客户端 IIS 服务正在处理这些网络请求。
我怀疑这与
- 客户端 IIS账户and/or其权限
- 一些我不知道的时髦 windows/TLS/SSL 协议
- IIS 设置？
了解如何进一步调试或解决此问题的一些见解？
好吧，在通过 wireshark 进行了一轮大测试和故障排除之后，应用程序似乎无法访问私钥，因为首先是 none。使用私钥从 .cer 快速更改为 .pfx 很快就解决了这个问题。
然而，它仍然没有解释为什么控制台应用程序可以使用 .cer 而不是 .pfx 访问服务器（没有私钥，可能与 IIS 有关，但我只是在做一个假设。）
另一个开发应用程序也发生了类似的情况，但是他们使用的是带有私钥的 .pfx 文件。进一步调试表明他们使用的是 X509Certificate 而不是 X509Certificate2。好吧，这个案例的问题是因为他们无法使用旧的 class.
访问私钥
总而言之，
- 确保存在私钥供应用程序访问，以便正确出示正确的证书，否则根本不会出示证书。
我正在尝试在 2 个系统之间执行相互身份验证，但即使客户端拥有正确的证书，服务器仍保持 returning 403.7。我已经做了一些诊断，似乎虽然应用程序正在处理证书，但它在某个地方是 "discarded" 的（当使用错误的证书时，它不是 return 403.16 而是 403.7）。
下面是一些背景
Server - ASP.NET IIS 上的 Web 服务，SOAP 调用可访问 WSDL。有 2 个根证书，一个用于服务器名称，另一个用于验证客户端证书。本地测试的证书都是self-signed。
Client - ASP.NET IIS 上的应用程序，对服务器进行 SOAP 调用。从 服务器 颁发客户端证书，并将两个根证书安装为受信任的 CA。访问一个 dll 以执行专门针对 服务器 的 SOAP 调用。客户端证书是 X509Certificate2，客户端 通过文件（不是证书存储）访问它。
客户端实际上是另一个网络应用程序的服务器，客户端和之间需要一个接口服务器。 Client 和 server 将在不同的网络上，并且需要通过 SSL 证书进行相互身份验证。两个系统之间的连接都是 TLS1.2
到目前为止进行的诊断
- Client 能够编译相同的 dll 和 运行 作为控制台应用程序，获取正确的客户端证书并成功通过服务器进行身份验证（证明代码正在运行） .故意选择错误的证书时，returned（正确行为） 403.16
- 客户端 浏览器能够访问 服务器 页面并使用正确的客户端证书进行身份验证（证明证书有效）
- Client 使用 dll 文件的网络应用能够访问和处理正确的证书（证明网络应用能够访问证书）。当故意选择错误的证书时，403.7 仍然是 returned 而不是 403.16。 （我的证书去哪儿了？）
- Wireshark 表示双方都在通话，但我无法让 wireshark 执行解密以提供更多 in-depth 详细信息（正在处理）
问题
根据标题，服务器保持 returning 403.7（通过 IIS Failed-Request-Tracing）即使 客户端 网络应用程序能够访问该文件.由于 客户端 是一个 Web 应用 运行 在 IIS 上连接并与 服务器 交互，我假设 客户端 IIS 服务正在处理这些网络请求。
我怀疑这与
- 客户端 IIS账户and/or其权限
- 一些我不知道的时髦 windows/TLS/SSL 协议
- IIS 设置？
了解如何进一步调试或解决此问题的一些见解？
好吧，在通过 wireshark 进行了一轮大测试和故障排除之后，应用程序似乎无法访问私钥，因为首先是 none。使用私钥从 .cer 快速更改为 .pfx 很快就解决了这个问题。
然而，它仍然没有解释为什么控制台应用程序可以使用 .cer 而不是 .pfx 访问服务器（没有私钥，可能与 IIS 有关，但我只是在做一个假设。）
另一个开发应用程序也发生了类似的情况，但是他们使用的是带有私钥的 .pfx 文件。进一步调试表明他们使用的是 X509Certificate 而不是 X509Certificate2。好吧，这个案例的问题是因为他们无法使用旧的 class.
访问私钥总而言之， - 确保存在私钥供应用程序访问，以便正确出示正确的证书，否则根本不会出示证书。