为什么通过net.tcp启用SSL（传输安全性）比使用HTTP要困难得多？

Question

使用WCF over HTTP实现使用传输级安全性的Web服务非常简单：Enable SSL for my WCF service

使用WCF over net.tcp实现使用传输级安全性的Web服务非常困难：WCF with netTcpBinding and Certificate transport security

... net.tcp解决方案通常在服务器端和客户端都涉及到类似的内容：

 <serviceCertificate
       findValue="MyServiceCertificate"
       storeLocation="LocalMachine"
       storeName="My"
       x509FindType="FindBySubjectName" />

在HTTP情况下，您甚至不需要在客户端或服务器上提及证书。在NET.TCP案例中，您必须在我阅读的大多数来源中在客户端和服务器上存储，查找和指定证书。

做神奇的事情是什么让你不必担心HTTP模式下的证书？而且，为什么使用net.tcp时无法使用这种魔法？

Answer 1

因为在HTTPS上使用WCF时; IIS管理与证书的协商（就像普通SSL一样）。由于没有内置用于TCP的IIS服务器，因此您必须自己完成。您仍在使用证书+ WCF进行HTTPS，但配置是在IIS完成的。

修改：

对于客户端，您还有另一个软件。通过SSL浏览网站时，浏览器会为您处理所有这些内容。 SSL over HTTP具有标准协商模式，因为它是HTTPS协议的一部分。对于TCP，这不是协议的一部分，因此客户端必须自己处理。

Answer 2

我也一直在与地狱挣扎，现在终于觉得自己像个白痴。这很好，因为这意味着我实际上理解了之前我只是在瞎逛的东西。

实施服务时，您的目标是确保与SSL的通信安全。您还需要能够在visual studio中生成reference.cs文件。您遇到的问题是您将元数据交换置于SSL绑定之下。代码生成工具不允许您为用于生成reference.cs文件时获取元数据的调用配置必要的netTcpBinding配置节。

您应该在netTcpBinding下创建两个单独的绑定配置，一个用于您的服务：

<security mode="TransportWithMessageCredential">
    <message clientCredentialType="Certificate"/>
</security>

配置内部和另一个：

<security mode="None" />

代替。确保所有其他设置都匹配，并且服务的端点指向ssl bindingConfig，而元数据端点指向无SSL绑定。然后，您将能够读取元数据并再次更新服务引用。

需要注意的一点是，您应该为任何prod版本提取元数据绑定。这可以确保您不会暴露任何不通过SSL的内容。