更好地理解TLS / SSL替代名称？

TLDR：这是Cloudflare

首先，请注意，X.509证书可以包含两个不同的扩展名， 主题备用名称和颁发者备用名称。 实际上，没有人使用IssuerAltNames，并且您复制的SSLLabs报告仅显示（仅）SubjectAltNames，实际上每个人现在和浏览器都使用它（刚刚）才开始需要 。

使用此证书的服务器是CloudFlarenetworking的一部分。 CloudFlare （主要）是一个所谓的“内容交付networking”，这意味着他们运行networking服务器，最初处理来自浏览器的WWW请求等等，为他们的客户拥有的许多网站/域。 引用他们的常见问题：

Cloudflare如何工作？
Cloudflare保护和加速任何网站在线。 一旦您的网站成为Cloudflare社区的一部分，其网站stream量将通过我们的智能全球networking进行路由。 我们会自动优化您网页的投放，让您的访问者获得最快的网页加载时间和最佳性能。 我们还可以阻止威胁，限制滥用机器人和抓取工具浪费您的带宽和服务器资源。

根据他们的主页，他们目前使用全球115个数据中心处理600万个“属性”（可能是域名）。 要做到这一点，他们处理每个服务器上的多个域（否则他们需要更多的服务器比任何人都负担得起），默authentication书反映了这一点，虽然他们提供专用证书的额外收费 。

使用共享服务器可能有风险：如果CloudFlare存在错误或者出错，它会影响受影响的服务器所处理的所有网站，并且有一些情况（请参阅维基百科文章）。 然而，由于他们的主要业务和全职工作正在运行这些服务器，CloudFlare服务器可能更好地configuration和监控，并且在出现问题时比起大多数（我猜想至less有90％）的原始服务器运行得更快直接由域名所有者。

使用共享证书没有显着的额外风险，因为任何查看受影响域的DNS解决scheme的人都可以看到他们通过CloudFlare – 而且所有合理的新软件都支持SAN，所以很less有客户端连接到一个使用SAN证书的服务器无论如何都可能被运行。 （不要把这个与WindowsXP和早期的Android和Java6（！）等稍微古老的软件的失败相混淆，以支持服务器名称指示（又名SNI， 这是TLS的一个相关但不同的function ）。

请注意，在单个企业拥有并使用多个域名的情况下，甚至“内部”web服务器仍可能使用不lessSubjectAltName条目，例如：

• （非通配）子域名，如www.bigcorp.com sales.bigcorp.com support.bigcorp.com或
• 在www.bigcorp.co.uk http://www.bigcorp.co.jp或
• 明显不同的名字，如www.bigpreviousname.com http://www.bigbrandslogan.com等

在我们拥有主题备用名称 （SAN）扩展名之前，证书只能有一个“通用名称”。 客户使用这个通用名称来validation他们正在与之通话的服务是他们期望与之通话的服务，而不是恶意，虚假或错误configuration的服务。

特别是对于网站来说，许多网站喜欢有多个可能的名字，客户可以用来连接（www.example.com，example.com，example.net，www.example.co.uk，example.tv）。 但是为每个可能的名字获得证书是一种负担。 此外，早期版本的SSL和TLS协议要求每个证书都托pipe在一个独特的IP /端口组合上，这增加了额外的成本和configuration工作量。

SAN扩展允许将多个附加标识符（不仅仅是DNS名称）与单个证书相关联。 对于上述两个问题，这是一个巨大的时间和成本节省。 具有多个名称的单个站点现在可以使用包含Web服务器上单个IP /端口组合的所有名称的单个证书。

即使对于位于公共负载平衡器或终止TLS连接的反向代理之后的不同站点，SAN证书也可能有用。 这在CloudFlare或Akamai等内容分发networking （CDN）中很常见。 这也是为什么你可能会在很多看起来不相关的SAN条目中find证书。

回答你的其他问题：

所有这些域都共享证书吗？

是

使用替代名称是否存在安全风险（MitM攻击？）？

使用SAN证书没有特定的安全风险。 它们与非SAN证书一样值得信赖。 然而，可以认为，将“多个鸡蛋放在一个篮子里”会带来正常的风险。 该证书的问题会影响所有使用该证书的网站。