403.7 IIS 7.5 SSL 客户端证书身份验证问题
我正在 IIS 7.5 下使用 2 路 SSL 与外部合作伙伴一起测试 Web 服务。我需要 SSL，需要客户端证书，并使用一对一映射对域帐户进行身份验证。我已经配置了所有内容，并且它在我们的网络上运行良好（我能够提供客户端证书，获得身份验证并从浏览器和测试工具调用服务）。 从我们的网络外部（在大多数情况下，见下文），我收到 403.7 错误。我已经检查了机器级证书存储并确保证书和 CA 是可信的。 这是奇怪的事情。我获得了 I 类证书，可以在家进行测试（并且像我们的预期合作伙伴一样获得了 403.7）。因此，我设置 Fiddler 来调试 SSL 并发送我的证书，由于某种原因，这有效。我设置了一个测试工具来通过完全相同的证书，并得到 403.7。我在浏览器 (IE 9) 中进行测试，没有收到客户端证书的提示，并得到 403.7。
任何帮助表示赞赏。 账单
I am testing a web service with an external partner using 2 way SSL under IIS 7.5. I am requiring SSL, requiring a client cert, and using one to one mapping to authenticate to a domain account. I have configured everything and it works fine on our network (I am able to provide a client cert, get authenticated and invoke the service from browser and test harness).
From outside of our network (in most cases, see below), I am getting a 403.7 error. I have gone through the machine level certificate store and made sure the certificates and CAs are trusted.
Here's the weird thing. I obtained a Type I cert to test from home (and got 403.7 like our intended partner is). So I setup Fiddler to debug SSL and send my certificate, and this works for some reason. I setup a test harness to pass the exact same certificate, and got 403.7. I test in my browser (IE 9), don't get a prompt for a client cert, and get 403.7.
Any help appreciated.
Bill
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
上次我检查时，IIS 使用重新协商（默认情况下）来获取客户端证书：在服务器不请求客户端证书的情况下进行第一次握手，然后在服务器请求客户端证书的情况下进行另一次握手（这次加密）证书（通过 TLS
CertificateRequest消息）。这将阻止您看到来自 Wireshark 的任何内容，除非您将其配置使用服务器的私钥并解密流量 （请注意，这仅适用于某些密码套件）。查看客户端证书协商的一种方法是将 IIS 配置为使用初始客户端证书协商，使用 netsh 和 clientcertnegotiation=true （这是关于初始协商）。至少
CertificateRequest和证书将在握手期间以明文形式发送，因此您应该能够使用 Wireshark 看到这一点。如果客户端没有向服务器发送证书作为对
CertificateRequest的响应，您仍会看到来自客户端的空Certificate消息。如果您不导出带有证书的私钥以供 Fiddler 或任何其他客户端使用，则它不可能使用该证书。它最多可能尝试发送证书，但握手将失败（因为
CertificateVerify消息需要由客户端的私钥签名）。我想您可能会遇到一个问题：
certificate_revoked、certificate_expired、certificate_unknown应该是致命的，因此这由服务器自行决定）。Last time I checked, IIS was using re-negotiation (by default) to get the client certificate: there is a first handshake where the server doesn't request a client certificate, followed by another handshake (encrypted this time) where the server requests the certificate (via a TLS
CertificateRequestmessage). This will prevent you from seeing anything from Wireshark, unless you configure it to use the server's private key and decipher the traffic (note that this only works with some cipher suites).One way to see the client-certificate negotiation is to configure IIS to use initial client certificate negotiation, using netsh and clientcertnegotiation=true (which is about initial negotiation). At least the
CertificateRequestand the certificate will be sent in clear during the handshake, so you should be able to see this with Wireshark.If the client isn't sending a certificate to the server as a response to the
CertificateRequest, you'll still see an emptyCertificatemessage from the client.If you don't export the private key with the certificate to use with Fiddler or whichever other client, there is no chance that it will be able to use the certificate. It may at best try to send the certificate, but the handshake will fail (since the
CertificateVerifymessage needs to be signed by the client's private key).I guess you may encounter a problem whereby:
unsupported_certificate,certificate_revoked,certificate_expired,certificate_unknownshould be fatal, so this is at the server's discretion).您是否使用同一台物理机来测试内网和外网连接？如果没有，您确定外网客户端可以访问私钥吗？
我之前没有配置过Fiddler客户端认证。它是否从标准证书存储中读取客户端证书和密钥？它直接从 PKCS12 读取吗？
另一件可能有用的事情是检查 WireShark 中的 TLS 握手。具体来说，请检查服务器的“证书请求”消息，因为此处的数据会提示客户端 (IE9) 应在提示中显示哪些客户端证书。比较内部和外部连接。
Are you using the same physical machine to test both the in-network and external-network connections? If not, are you sure that the external-network client has the private key accessible?
I have not configured Fiddler client authentication before. Does it read the client certificate and key from the standard certificate stores? Does it read directly from a PKCS12?
One other thing that may be helpful is inspecting the TLS handshake in WireShark. Specifically, check out the Server's "Certificate Request" message, as the data here clues the client (IE9) which client certificates it should display in the prompt. Compare this for the internal and external connections.