我们是一家小型初创公司。我们的产品之一是 B2B Web 服务，可通过其https://service.example.com规范 URL 访问。
出于测试目的，该服务还可以在不同的测试/登台/集成环境中运行，例如https://test.service.example.com,https://integration.service.example.com等。
我们还有协作工具，例如错误跟踪器或 wiki。它们也在我们的托管服务提供商提供的机器上运行。它们的 URL 是例如https://wiki.example.com, https://bugs.example.com。
为简单起见，我们使用单个证书 (for example.com)，并将上述所有 URL 作为主题备用名称添加到同一证书中。因此，我们所有的服务器都使用相同的证书。
这样做有什么安全问题需要我们注意吗？如果是，那么“正确”的做事方式是什么？
使用相同的证书不会以任何方式影响使用它建立的连接的基本安全性。
使用相同证书引入的唯一可能的“弱点”是，如果该证书过期或泄露，您的所有站点都将受到影响。由于此证书位于多台服务器上，其中一些可能是安全性较低的测试服务器，因此该证书的私钥可能会无意中从这些未经检查的服务器之一泄露或暴露。这当然不是证书提供的安全性的失败，而是证书私钥保密的失败。
另一种方法是为您的所有站点使用单独的证书，这意味着您将承担必须更新、保护和监控多个证书的管理负担。
如果您正确保护了该证书的私人详细信息，则没有理由使用它会引入任何额外的安全问题。
这个模型有两个缺点。
1）信息泄露。在证书中包含 dev/qa/etc URL 可以让人们更轻松地找到这些环境。通常它们不如实际生产环境安全，因为它用于测试代码。如果您有其他控制来限制访问，例如路由器/防火墙 ACL（或其他），那么这并不重要。
2) 妥协收容。我强烈建议将证书专用于生产。如果由于某种原因您的 dev/qa/etc 环境受到损害并且可以访问私钥，那么人们必须质疑生产流量是否受到损害（即 MITM）。SSL 证书现在非常实惠，我再次建议将证书专用于生产。
正如@anon 所说，主要问题是信息泄漏。任何访问您的任何一个站点的人都可以看到证书中列出的所有其他人的名称（除非您选择获取通配符证书；但是，通配符证书不会让您添加额外的级别test.service...，因为通配符不能包含点）。如果您不在乎访问者service可以看到wiki,bugs等存在，那么这不是问题。
一般来说，我更喜欢将自签名证书用于测试站点。这只是额外表明该站点未投入生产。在网上商店的测试网站收到大量订单后，我开始这样做。（它在每一页的顶部用粗体字写着不要使用该网站的事实似乎并不重要。事实证明，其中大多数是欺诈订单，但这不是重点。）拥有“此站点不受信任”弹出警告有助于使人们停止尝试在该站点上购买。