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