“通配符证书”是包含作为可能的服务器名称的证书，该名称包含“ *”字符的名称。详细信息在RFC 2818，第 3.1 节。底线：当服务器证书包含 时，客户端*.example.com将接受它作为外观名称与该名称匹配的任何服务器的有效证书。

在网站认证业务中，有四个主要参与者：

• SSL 服务器本身。
• 客户端将使用的 Web 浏览器的供应商。
• 人类用户，在某种程度上控制客户端浏览器将执行的操作。
• 向服务器颁发证书的 CA。

通配符证书并不意味着 SSL 服务器存在额外的漏洞；实际上，SSL 服务器对查看自己的证书没有兴趣。该证书是为了客户的利益，让他们相信证书中包含的公钥确实是真正的 SSL 服务器的公钥。SSL 服务器知道它自己的公钥/私钥对，不需要说服它。

人类用户不知道什么是公钥。他看到的是一个挂锁图标，更重要的是，预期的服务器名称：这是“”右侧https://和下一个“”之前的名称/。网络浏览器应该处理验证名称正确的技术细节，即验证服务器证书，以及验证名称是否与所述证书中写入的名称匹配。如果浏览器不做这项工作，那么它就会被视为草率而没有发挥作用，这可能会产生严重的商业后果，甚至可能是合法的。类似地，CA 在合同上必须遵循确定的程序来识别 SSL 服务器所有者，这样攻击者就很难获得假证书（合同是 CA 和它的 über-CA 之间的合同，递归地，直到根 CA，它本身是绑定的通过与操作系统或浏览器供应商的协议，他们同意在定义的条件下将根 CA 密钥包含在操作系统或浏览器中）。

这意味着，浏览器和CA在实践中必须通过验证过程来纵容用户。他们或多或少有义务（根据法律或更严格的商业考虑）防止用户被看似合法的虚假网站所欺骗。用户作业和浏览器/CA 作业之间的界限没有明确定义，并且在历史上已经移动。在过去的日子里，我的意思是大约十年前，浏览器只是打印出原始 URL，由人类用户在其中找到服务器名称。这导致伪造站点运营商（即“网络钓鱼站点”）使用技术上有效但具有误导性的 URL，例如：

https://www.paypal.com:payment-interface-login-session@xcvhjvb.com/confirm.html

由于人类用户是，嗯，人类，并且他们中的大多数人从左到右阅读（大多数富有和容易上当的骗局目标仍然在西方国家），他们将从左边开始，看www.paypal.com，停在冒号符号（“太技术”），并被骗。

作为回应，浏览器供应商承认人类用户的 URL 解析能力不如最初假设的那么好，因此最近的浏览器突出了域部分。在上述情况下，这将是xcvhjvb.com，当然也不是其中paypal.com的任何内容。现在是通配符证书进入游戏的部分。如果所有者xcvhjvb.com购买了一个包含“ *.xcvhjvb.com”的通配符证书，那么他可以设置一个钓鱼网站，名为：

https://PayPal-payment-interface-login-session.xcvhjvb.com/confirm.html

这将被浏览器接受（它与通配符名称匹配），并且仍然可能会抓住粗心的用户（并且有很多......）。这个名字可能已经购买了被攻击者而不诉诸通配符，但随后的CA员工会看到有明显的欺诈企图的名称（好CA做证书的每个请求的人确认，或者至少发出警报，为它们的名字很长和/或其中包含已知的银行名称）。

因此，通配符证书会降低 CA 端欺诈遏制措施的有效性。这就像来自 CA 的空白签名。如果基于通配符的网络钓鱼尝试变得更加普遍，则可以预期以下一项或多项措施将出现：

• 浏览器仅突出显示与证书中的非通配符元素匹配的域名部分。
• CA 需要更繁重的文书工作和通配符证书合同（这些会更昂贵）。
• 浏览器完全停用对通配符证书的支持。

我实际上预计所有这三项措施都将在未来几年内实施。我可能完全错了（这是预测未来的问题），但这仍然是我的直觉。

挑剔的是，我们还可以指出，通配符证书对于在不同的服务器名称之间共享相同的密钥对很有用，这使得私钥更有可能在不同的服务器机器之间共享。随身携带的私钥本身就是一种安全风险；私钥四处游荡的次数越多，它保留的“私密性”就越少。

在提供不同服务的多个服务器上传播相同的私钥是不好的做法：任何服务中任何被利用的安全问题都会泄露用于所有内容的私钥。

但通常使用通配符证书将用户贡献的 Web 内容隔离在用户特定的子域中，以利用同源策略。相同的方法通常用于呈现不受信任的 portlet。它是开放社交“标准”的一部分。

在我的工作场所，我们开发了一个包含开放社交实现并使用通配符设置的软件。客户安装已经过渗透测试。通配符设置没有受到批评。

最终，这些答案中提到的许多漏洞都来自混合信任级别。但是，如果您了解通配符证书的工作原理，则可以针对特定用例缓解这些漏洞。我认为更详细地解释这一点将提高这个问题及其答案的实用性。

除非您域中的所有系统都具有相同的信任级别，否则使用通配符证书来覆盖您控制下的所有系统是一个坏主意。但是您可以使用 DNS 子域作为分段工具。正如 Hendrik 所说，由于通配符不遍历子域，因此您可以将通配符证书限制为特定的命名空间。例如，如果您有一个 CDN 场，您可以只使用通配符*.cdn.example.com. 这使主机example.com本身（如www.example.com）保持独立，您可以为www.example.com.

正如 AviD 从 OWASP 中提到的：内部工作站、开发系统等属于较低的信任级别。然而，像这样的主机无论如何都应该在它们自己的内部域空间中（如prv.example.com）。由于通配符不遍历子域，*.example.com因此无法将证书应用于prv.example.com主机。（这将使公共和私有属性分开，但显然不会将私有属性彼此隔离。可以使用其他子域通配符，映射到适当的信任级别）。

虽然这篇 eWeek 文章指出私钥可以在多个主机之间共享，但这个 SSLShopper 反驳说，一些发行者（如 DigiCert）允许您为每个通配符主机生成单独的私钥。这确实降低了通配符证书的一些有用性，但肯定会缓解共享私钥问题，并且在某些情况下可能会有所帮助。否则，这篇 Entrust 文章和它引用的白皮书 PDF讨论了与通配符证书一起使用时管理私钥的最佳实践。

最后，诉诸权威的争论......如果谷歌在他们的某些属性上使用通配符证书，它们一定不会是普遍的坏事：

:-)

理想情况下，证书/密钥可用于模拟的服务列表应该与证书/密钥打算用于的服务列表相同。

假设您有一个域 example.com。您在该域 www.example.com catpictures.example.com users.example.com 下设置了各种主机名。所有这些都托管在同一台服务器上，因此您可以获得一个证书来涵盖所有这些。

现在假设您在更安全的服务器上设置了secure.example.com。假设您获得了该服务器的单独证书。

现在考虑如果与第一台服务器上的证书对应的私钥被盗，会发生什么情况。

如果它是 *.example.com 的证书（通配符证书），那么攻击者可以使用它来模拟 secure.example.com

如果它是 www.example.com catpictures.example.com 和 users.example.com 的证书，则攻击者无法使用它来冒充secure.example.com