群集环境中的相互WCF证书身份验证/ SSL

Question

我阅读了很多关于WCF安全性的文章,但仍然没有关于证书场景的清晰图片.我们的部署环境有一个NLB集群(前端),很少有ASP.NET站点与应用程序服务器(后端,也称为NLB集群)通信.我们需要使用相互证书身份验证和SSL来保护它.我是否正确,我们需要做以下事情:

1. 在域CA中颁发CN = app-server-NLB-hostname和"Server authentication"目的的证书.
2. 使用"客户端身份验证"目的为前端机箱颁发证书.
3. 将后端证书的公钥导入前端节点的存储(反之亦然).
4. 配置WCF以使用net.tpc和传输安全性
5. 配置服务行为(serviceCredentials部分)
6. 配置客户端端点行为(clientCredentials部分)

我的问题是:

1. 我错过了什么吗？
2. 我是否需要执行任何其他步骤才能启用SSL？
3. 应该为哪个主机名前端证书颁发？
4. 前端节点位于DMZ中,因此无法访问域(CA).这会导致任何问题吗？

Answer 1

你好呀。由于没有其他人回答，我将对此进行破解 - 但公平警告 - 我是一名 Java/UNIX 开发人员，并且您所问的一些问题是 Microsoft 特有的。但这里有几个答案：

1 - 在域 CA 中颁发 CN=app-server-NLB-hostname 和“服务器身份验证”用途的证书。

其目的在某种程度上是微软特有的。这听起来是对的，而且 - 您可能需要常规的“密钥用法”是特别的 - 对于 SSL 证书，我通常使用 keyEncipherment 或 keyAgreement。有时网站使用数字签名。这三种方法在 RFC 中都是有效的，但有时 Microsoft 对哪些方法有效很奇怪。如果您使用的是 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，因此在防火墙上打开路径通常不会太糟糕。

就像我说的——这将是高档的、严重的风险缓解型解决方案。这对你的系统来说可能有点过分了——我对你的系统了解不够，无法告诉你它是否合理。