通配符SSL证书& SAAS

Question

据我所读，使用通配符SSL/TLS证书是不可取的，您如何在SAAS应用程序(Linux)中进行证书颁发和管理，其中每个客户端都有一个用户选择的子域？

Answer 1

“通配符证书”没有任何问题。通配符证书等同于包含许多可能的服务器名称的证书。如果这很好地映射到了您的问题(例如，您有一个具有大量前端的服务器，该服务器为不同的名称做广告，但所有这些名称都在同一个域中，并且您控制了该域)，那么通配符证书无疑是一种可能性。通配符证书的主要问题是：

• 通配符证书可用于多个服务器名，通常需要使用多个名称，因为您有几台计算机。由于通配符证书对应于一个私钥，因此必须在所有这些机器上安装该私钥。重复的私钥和四处走动的私钥不太私密，因为它们暴露得更多。
• 商业CA使用依赖于销售多个证书的业务模型。通配符证书允许客户购买一个证书而不是多个证书。因此，商业CA倾向于使通配符证书更加昂贵，以补偿相应的业务损失。

在您的情况下，据我了解，您有一个主机服务器，它为多个站点运行SSL服务器；这些站点的名称遵循name.example.com模式，其中name是特定于客户的名称，example.com是您控制的域。由于在HTTPS中，SSL对话首先发生(在任何HTTP发生之前)，服务器(通常)不知道预期的服务器名称(客户端使用的URL中的名称)，因此服务器必须以某种方式发送一个证书，该证书与来自客户端的所有可能名称“工作良好”。这导致了三种可能的解决办法：

1. 在*.example.com中使用通配符证书。这会很好的。
2. 在Subject Alt Name扩展中使用多个名称的证书。你可以在里面放几百个名字。这也有效，但是每次要添加新名称时都必须获得一个新证书(证书由CA签名，您不能在不使签名无效的情况下更改其中的任何内容)。
3. 使服务器“猜测”预期的服务器名称，以便它可以发送“正确”证书(然后服务器将拥有多个证书，每个站点名称一个)。这使用了服务器名称指示扩展:早期SSL握手消息中的一个插槽，以便客户端可以在服务器实际发送其证书(客户机期望的站点名称)之前告诉服务器。SNI运行良好，只是一些旧浏览器或操作系统不发送它，因此使用此扩展意味着您将不支持此类客户端。不受支持的主要客户端是Windows上的Internet (较新的Windows系统上的IE很好)。如果您认为您可以拒绝仍然使用Windows和IE的客户端，那么SNI是一个可行的解决方案。

通配符证书似乎仍然是最简单和最健壮的方法。

Answer 2

如果您了解通配符的含义，那么使用通配符证书并不是一个真正的问题。

但是，如果您不需要(或不能)使用通配符证书，那么在您的情况下，您别无选择，只能为每个子域颁发一个新的、单独的证书。

理论上，您也可以使用桑证书，但除非事先知道您需要保护的域的完整列表，否则它将是一个比为每个子域提供新证书更糟糕的解决方案。

现在，如果您不愿意使用通配符证书，那么为什么您不愿意为每个新客户颁发新的证书呢？

编辑:你担心失去整个系统，以防你的密钥被泄露。然而，使用多个密钥分割加密没有什么实际的理由可以提高安全性:唯一需要访问私钥的方是服务器SSL端点，因此，假设您对终端服务器上发生的事情几乎没有控制(而且您担心客户操作会导致他们自己的服务器被合并，也许因为您让他们运行自己的代码，那么解决方案就是在您的服务器前面部署一个反向代理，它将处理公共密码并保存您的密钥安全(如果您想要加密网络内的通信，甚至可以在代理和服务器之间建立内部SSL连接)。

这样的系统比让每个服务器使用他们自己的证书更容易管理和安全(另外，它将更便宜，可以用现成的解决方案实现)。