如果主从使用相同的主机名，或者您有通配符证书并且它们都使用相同域的子域，那么没有技术原因不能为两者使用相同的 SSL 证书。但是一些 SSL 证书颁发者按服务器许可它们，您可能违反了您的许可条件。

如果服务器名称出现在证书中的某处（如dNSName在主题替代名称扩展中，可能带有通配符，如RFC 2818中所述），则证书可由 SSL 服务器使用。“服务器名称”出现在客户端使用的 URL 中。如果 URL 中的名称没有出现在证书中，客户端浏览器会抱怨（大声）。

海量证书共享是一回事。例如，Google 的 SSL 证书包含以下所有名称：

*.google.com
*.android.com
*.appengine.google.com
*.cloud.google.com
*.google-analytics.com
*.google.ca
*.google.cl
*.google.co.in
*.google.co.jp
*.google.co.uk
*.google.com.ar
*.google.com.au
*.google.com.br
*.google.com.co
*.google.com.mx
*.google.com.tr
*.google.com.vn
*.google.de
*.google.es
*.google.fr
*.google.hu
*.google.it
*.google.nl
*.google.pl
*.google.pt
*.googleapis.cn
*.googlecommerce.com
*.googlevideo.com
*.gstatic.com
*.gvt1.com
*.urchin.com
*.url.google.com
*.youtube-nocookie.com
*.youtube.com
*.youtubeeducation.com
*.ytimg.com
android.com
g.co
goo.gl
google-analytics.com
google.com
googlecommerce.com
urchin.com
youtu.be
youtube.com
youtubeeducation.com

这暗示了相同证书的一些广泛共享，这就是谷歌，互联网的霸主，同样如此。

关键部分不是证书本身，而是私钥。正确地说，证书包含公钥；服务器的权力在于对应的私钥。如果两台服务器“共享”一个证书，那么这意味着两台服务器都可以访问私钥。

推荐的私钥管理方法是将它们保存在本地：服务器本身应该生成密钥对（私钥和公钥），然后将公钥发送给 CA（作为“证书请求”的一部分），所以CA 可以创建（并签署）证书。因此，私钥永远不会离开服务器的内部，这很好，因为私钥必须保密。

当两台服务器包含私钥时，该密钥一定在某个时间点已经传播。一般来说，这样的钥匙旅行是敏感和危险的，必须非常小心。通过 SSH（即scp命令）复制密钥应该是安全的。或者，可以将私钥与证书一起打包到具有基于密码的加密的 PKCS#12 存档（又名“PFX 文件”）中：如果密码足够，这将为密钥在两台服务器之间传输时提供良好的保护熵（所以使用一个大而粗且非常随机的密码）。

但是，您将拥有两个私钥副本。在恶意服务器劫持的情况下，拥有特定于服务器的私钥可能会（稍微）更好地遏制损害。

这是相当普遍的做法。事实上，大多数大型网站都使用负载平衡，将网站的负载分布在多台服务器上。有两种方法可以做到这一点。第一个是与将要托管该站点的每台服务器共享私钥，第二个是使用 SSL 代理，该代理将私钥保存在运行该站点的服务器的专用网络边缘（或可能使用备用加密通信）。两者都有自己的长处和短处。

关键是证书只能用于它认为自己有效的站点。证书的目的是验证给定服务器实际上是您尝试连接的网站。这是由证书颁发机构 (CA) 验证有关私钥所有者的详细信息，然后颁发基本上说“这些详细信息对私钥持有者有效”的证书来完成的。这些详细信息是有关运营商的信息以及他们在该私钥下运营的一个或多个站点的名称。

正如其他人所提到的，认识到某些 CA 对他们提供的证书的使用施加了超出技术限制的限制也很重要，因此验证您的 CA 是否允许您的预期用途非常重要，否则您最终可能会得到您的证书被撤销。

据我所知，当我们要购买 SSL 证书时，我们需要验证我们是域名的合法所有者。这是通过使用来自该域的电子邮件地址向 SSL 供应商发送电子邮件来完成的。

您可以拥有 *.example SSL 证书并将其用作：

• abc.example.com
• def.example.com
• 依此类推，只要它还在 *.example.com

但这比直接在 abc.example.com 上购买要贵一些