我阅读了很多关于WCF安全性的文章，但仍然没有关于证书方案的清晰图片。我们的部署环境具有NLB群集（前端），只有少量ASP.NET站点与应用程序服务器（后端，也是NLB群集）通信。 我们需要通过相互证书认证和SSL来保护它。 我是正确，我们需要做到以下几点：与CN =应用程序服务器，NLB主机名和“服务器身份验证”目的集群环境中的相互WCF证书身份验证/ SSL
我的问题是：
你好。由于没有其他人回答，我会采取一些措施 - 但公平的警告 - 我是一名Java/UNIX开发人员，并且您提出的一些问题与Microsoft有关。但这里有一个几个答案：
1 - 发出与 CN =应用程序服务器，NLB主机名和 域CA. “服务器身份验证”目的的证书
目的是微软具体的事情。这听起来不错，而且 - 您可能需要定期的“密钥使用”才是特别的 - 对于我通常使用keyEncipherment或keyAgreement的SSL证书。有时候网站使用digitalSignature。所有这三个在RFC中都是有效的，但是有时候微软对于哪些工作有些w w。如果您使用Microsoft CA，我会看看它是否具有SSL证书的证书配置文件，并使用它。
2 - 使用“客户端身份验证” 目的发布前端 框的证书。
与＃1相同 - 每个证书都需要某种基本的密钥用法。您提到的字段是扩展用法，这可能也是必需的，但不是强制性的。
3 - 将后端证书的公开 密钥导入前端节点的存储器 （反之亦然）。
只有当这是微软特定的事情。在正确的PKI中，您应该导入签名SSL的可信CA的证书，但不必将每个端点（如后端证书）导入到前端。我会尝试一下，只配置可信的CA链，看看能否让它工作 - 从长远来看，这会让你的架构更具可扩展性。
4 - 配置WCF与 传输安全
5使用net.tpc - 配置服务行为 （serviceCredentials部）
6 - 配置客户端端点 行为（clientCredentials部）
听起来对我很好...
从那里，我不认为你已经错过了别的。关键通常是通过模糊的错误消息。每个系统都有自己难以辨认的SSL握手失败时出现问题的方式，所以它主要是了解哪里出了问题。
从你描述的问题，我不认为认为你的安全架构是说你需要做一个证书状态检查。这是一种附加措施，可让您的系统检查证书是否已被CA吊销。需要相当多的基础设施才能使其工作（CRL或OCSP），所以我不会说你应该在没有认真讨论你的团队的情况下转而去寻求你的努力缓解什么样的风险，以及他们有多可能发生。
应该为哪个主机名前端证书颁发？
它们代表的服务器的主机名。
关于主机名的问题 - 除非您使用完全限定的域名，否则某些系统将无法正常工作。其他人并不那么挑剔。无论如何 - 证书的主题DN应该唯一地描述它所代表的服务，应用程序或服务器。
前端节点位于DMZ中，因此无法访问域（CA）。这会导致任何问题吗？
你不会有问题。
除非 - 您需要执行上述证书状态检查。如果您必须验证证书状态，则需要从终点（即DMZ）到证书状态信息（CRL或OCSP服务器）。在复杂的基础设施中，这通常是通过打开OCSP服务器的路径完成的 - 这是一个到固定域名或IP的HTTP GET，因此在防火墙上打开路径通常不会太糟糕。
就像我说的那样，这将是高端的，严重的风险缓解型解决方案。对你的系统来说这可能是矫枉过正的 - 我对你的系统知之甚少，无法告诉你它是否有保证。