X509 规范允许 CA 使用“主题备用名称”扩展名为多个主机名颁发单个证书。
从规范：
主题替代名称扩展允许身份绑定到证书的主题。这些身份可以包括在证书主题字段中的身份之外或代替身份。
这有很多用途；特别是，考虑托管/反向代理情况，多个站点位于同一位置。这些网站彼此之间并不特别信任，也没有任何形式的从属关系；它们只是由同一台服务器托管，因此共享相同的证书。
这是否像听起来那样危险？
乍一看，我会说由于站点之间不相互信任，因此站点A 可能会欺骗站点B，即使是通过SSL，因为站点A 使用与站点B 相同的私钥。DNS 仍然需要被欺骗，但是有几种方法可以做到这一点（即使它们不是微不足道的）。
我错了吗，是否还有其他一些我在这里没有看到的加密（或其他）缓解措施？
如果每个租户都有一个私钥的副本，那么他们都拥有它，这意味着他们可以互相欺骗。他们还可以解密其他租户与其客户之间的流量，除非他们使用 SSL 的“DHE”密码套件，这消除了这个特定问题；这被称为完美前向保密。DHE 对欺骗问题没有任何作用，只有在客户端软件同意的情况下才能使用。
因此，诀窍是不要将私钥提供给每个租户。不要让他们共享同一个证书，而是让他们共享同一个 SSL 服务器。运行一个使用证书的受信任的 HTTPS 服务器，然后将解密的 HTTP 流量转发给相关租户（其名称在 HTTP 标头中指定——此处不需要SNI支持）。确实是反向代理的情况。这样的设置是安全的（租户一无所获）；但是，它要求租户信任共享 SSL 服务器（这仍然比要求租户相互信任更好），并且会干扰（即在所有实际情况下，阻止）客户端的使用证书。
是的，这和听起来一样危险。你没有错，而且，AFAIK，我不认为你错过了什么。
多个实体共享同一个签署公钥的证书，意味着它们共享同一个私钥。不是一件好事TM。如果site1.com不信任，site2.com则不应将它们配置为使用主题备用名称 ( SAN ) 证书。
一个好的 CA 将验证请求证书的实体是否拥有 SAN 中定义的主题（域名、IP 地址、电子邮件地址等）的所有权。
因此，总而言之， SAN 证书仅应在涵盖的主体相互信任时使用。SE 站点就是使用相同证书（您在 DMZ 中提到的证书）的不同站点的一个很好的例子。即使stackoverflow.com与 不同的站点superuser.com，它们仍然相互信任并且属于同一实体。
@Adnan 和 @Thomas Pornin 都触及了三脚架的第一站：如果密钥仅由共享提供商（例如 CDN）访问，则安全性不一定较低，如果它由未连接方共享，则安全性低得离谱。
三脚架还有第二条腿，就是维修。假设密钥仅由共享提供者 (HostCo) 持有，因此安全性不是问题。HostCo 有 20 个租户，他使用主题备用名称 (SAN) 将它们填充到密钥上。伟大的！六月过去，七月到来，3个租户离开，4个新租户出现。哎呀！是时候获得反映添加/更改的新证书了。伟大的。哎呀！八月来了……看看这是怎么回事？随着时间的推移，使用多个 SAN 重做证书的维护是愚蠢的，除非进入 SAN 的名称池是相当静态的。
三脚架的第三条腿是钱。HostCo 使用 SAN 证书可能比出去购买 20 个证书便宜。这条腿没有任何意义，真的，因为租户是真正没有连接的单元，彼此不信任，HostCo 只会将单个证书的成本转嫁给他们。没有相同的经济激励，例如，Massive Dynamic 必须为它的所有 273 个子公司提供服务的网站的证书省钱。
那是三条非常摇晃的腿。如果可以选择，我不会坐在那个凳子上。