403.7 IIS 7.5 SSL客户端证书认证问题 [英] 403.7 IIS 7.5 SSL client certificate authentication issue

查看:326
本文介绍了403.7 IIS 7.5 SSL客户端证书认证问题的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我在IIS 7.5下使用双向SSL测试与外部合作伙伴的Web服务。我需要SSL,需要客户端证书,并使用一对一映射来向域帐户进行身份验证。我已经配置了一切,它的工作正常在我们的网络(我能够提供客户端证书,获得身份验证和调用服务从浏览器和测试工具)。
从我们的网络外(在大多数情况下,见下文),我得到一个403.7错误。我已经通过机器级证书存储,并确保证书和CA是受信任的。
这是奇怪的事情。我获得了一个类型I证书从家里测试(和403.7像我们的合作伙伴是)。因此,我设置Fiddler调试SSL并发送我的证书,并且由于某种原因这工作。我设置一个测试工具来传递完全相同的证书,并得到403.7。我在我的浏览器(IE 9)测试,没有得到客户端证书的提示,并获得403.7。

任何帮助赞赏。
Bill

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

推荐答案

上次我检查,IIS使用重新协商:有第一次握手,其中服务器不请求客户端证书,随后是另一次握手(这次加密),其中服务器请求证书(通过TLS CertificateRequest 信息)。这将阻止您看到Wireshark中的任何内容,除非您将其配置为使用服务器的私钥并解密流量(请注意,

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 CertificateRequest message). 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).

查看客户端 - 证书协商的一种方法是配置IIS使用初始客户端证书协商,使用 netsh和clientcertnegotiation = true (这是关于初始协商的)。至少 CertificateRequest 和证书将在握手期间以明文发送,因此您应该能够看到这与Wireshark。
如果客户端没有向服务器发送证书作为对 CertificateRequest 的响应,您仍然会看到一个空的证书

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 CertificateRequest and 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 empty Certificate message from the client.

如果您没有导出带有Fiddler或任何其他客户端使用的证书的私钥,没有机会,它将能够使用证书。它最多可以尝试发送证书,但握手将失败(因为 CertificateVerify 消息需要由客户端的私钥签名)。

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 CertificateVerify message needs to be signed by the client's private key).

我想你可能会遇到一个问题:

I guess you may encounter a problem whereby:


  • 服务器接受不提供证书它实际上是可选的),

  • 提供无效的证书会导致失败并导致403.7状态代码(许多服务器和SSL / TLS堆栈将实现此为致命错误,但 TLS规范不会说 unsupported_certificate certificate_revoked certificate_expired certificate_unknown 应该是致命的,服务器自行决定)。

  • not presenting a certificate is accepted by the server (it's effectively optional),
  • presenting an invalid certificate makes it fail and causes this 403.7 status code (many servers and SSL/TLS stacks would implement this as a fatal error, but TLS specification doesn't say that unsupported_certificate, certificate_revoked, certificate_expired, certificate_unknown should be fatal, so this is at the server's discretion).

这篇关于403.7 IIS 7.5 SSL客户端证书认证问题的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆