这似乎是一个常见错误（还有其他类似问题的帖子）-但是，我已经浏览了所有这些帖子和 MSDN 文章（https://learn.microsoft.com/en-us/dotnet/framework/wcf/feature-details/working-with-certificates https://learn.microsoft.com/en-us/dotnet/framework/wcf/feature-details/working-with-certificates）。
场景：尝试使用 HTTPS 端点访问服务。
在代码中设置客户端证书（证书已正确加载）。
至于服务器证书，我尝试了以下两个选项：
client.ClientCredentials.ServiceCertificate.Authentication.CertificateValidationMode = X509CertificateValidationMode.None;
client.ClientCredentials.ServiceCertificate.Authentication.CertificateValidationMode = X509CertificateValidationMode.PeerOrChainTrust;
我已将服务器证书导入个人以及机器存储（受信任的根证书颁发机构/证书）。
奇怪的是，当我使用 Charles Proxy 作为 SSL 代理时，调用正在进行。
其他设置：
System.Net.ServicePointManager.SecurityProtocol = System.Net.SecurityProtocolType.Ssl3;
ServicePointManager.ServerCertificateValidationCallback +=
(se, cert, chain, sslerror) =>
{
//Console.WriteLine(cert.GetCertHashString());
if (cert.GetCertHashString() == "[actual hash here]")
return true;
else
return false;
};
当 Charles 代理运行时，上面的哈希检查工作正常。如果没有运行代理，回调甚至不会被调用。
如有任何反馈，我们将不胜感激。
（值得注意的是，使用 Apache CXF 库的 Java 客户端可以正常工作 - 针对相同的服务。）
Update：
为了完整起见，原始错误还包含以下文本：
这可能是由于在 HTTPS 情况下未使用 HTTP.SYS 正确配置服务器证书。这也可能是由于客户端和服务器之间的安全绑定不匹配造成的。
好吧，经过几天（和几夜）的头撞，以下是我的思考/发现（当然还有解决方案！）：
有“SSL”，然后有 SSLv2、SSLv3、TLSv1.0、TLSv1.1、TLS1.2 和 TLSv1.3（目前为草案）。
服务器和客户端能够协商并选择这些版本之一以成功通信至关重要。
HTTP.SYS 错误似乎是客户端无法与服务器协商适当版本的结果。通过 Charles 代理时，很明显 Charles 和我们尝试访问的服务都使用 TLSV1.1。
就我而言，我使用的是 wsHTTPBinding & 尽管我尝试设置 System.Net.ServicePointManager.SecurityProtocol = SecurityProtocolType.Tls;和其他组合，我永远无法让 HTTP.SYS 错误消失。服务器和客户端似乎永远无法选择他们可以同意的版本。
我确实尝试使用其他绑定，例如 basicHttpBinding （使用 TransportWithMessageCredential）以及 basicHttpsBinding，但无济于事。更重要的是，在每种情况下对绑定元素（通过配置和代码）进行一些细微的调整，我在所有 3 种情况下都得到了完全相同的绑定配置（basicHttp/basichHttps/wsHttp 绑定）！本质上，虽然有这些开箱即用的绑定，但它们可能适用于最简单的场景。更重要的是，可能不需要这么多的预打包绑定，特别是因为它们似乎使用了大部分相同的绑定元素。
-
我确实记得读过，在许多情况下使用自定义绑定更好 - 但我想象通过自定义 wsHttpBinding 我会实现同样的事情。看起来不是 - 因为此绑定中有一些硬编码属性（例如：默认 SSL 协议）似乎很难绕过。我确实查看了 wsHttpBinding 及其基类的源代码，但找不到确切的硬编码位置（但在 System.ServiceModel 代码中引用了“默认”协议）。
- 最后，“CustomBinding”对我有用，配置如下：
自定义绑定配置 https://i.stack.imgur.com/Co1XI.png- 很抱歉将其包含为图像 - 因为 SO 上的格式正在播放。
这个想法是使用httpsTransport with requireClientCertificate, 安全性与authenticationMode="CertificateOverTransport" & includeTimestamp="true"（我们的服务需要时间戳）和相关messageSecurityVersion- 在我们的例子中是：WSSecurity10WSTrustFebruary2005WSSecureConversationFebruary2005WSSecurityPolicy11BasicSecurityProfile10.
上述配置也会自动签署时间戳。
-
最重要的是，我们必须包含用户名/密码凭据。仅设置 client.ClientCredentials.UserName.UserName 和 client.ClientCredentials.UserName.Password 不会导致这些凭据包含在安全标头中。逻辑是还要添加用户名“token”，如下所示：
//Get the current binding
System.ServiceModel.Channels.Binding binding = client.Endpoint.Binding;
//Get the binding elements
BindingElementCollection elements = binding.CreateBindingElements();
//Locate the Security binding element
SecurityBindingElement security = elements.Find<SecurityBindingElement>();
//This should not be null - as we are using Certificate authentication anyway
if (security != null)
{
UserNameSecurityTokenParameters uTokenParams = new UserNameSecurityTokenParameters();
uTokenParams.InclusionMode = SecurityTokenInclusionMode.AlwaysToRecipient;
security.EndpointSupportingTokenParameters.SignedEncrypted.Add(uTokenParams);
}
client.Endpoint.Binding = new CustomBinding(elements.ToArray());
通过所有这些设置，我终于能够访问该服务并实际得到结果 - 好吧，几乎！ - 因为结果不包含时间戳，WCF 将其作为异常抛出。但这是另一个需要解决的问题。
希望读者觉得这很有用。
Update:
- 现在时间戳问题也被“排序”了。问题是响应缺少任何安全标头，而不仅仅是时间戳。值得庆幸的是，有一种简单的方法可以通知 WCF 忽略不安全的响应，只需在安全元素上标记一个属性：enableUnsecuredResponse="true"。显然这是不可取的，但由于我们对服务没有任何控制权，这是我们目前能做的最好的事情。
本文内容由网友自发贡献，版权归原作者所有，本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容，请联系:hwhale#tublm.com(使用前将#替换为@)
