这是我需要保护的内容： .com
www.foo.com
city.state.foo.com的任何组合。 （这是美国的州。）
我的理解是，通配符证书只能覆盖一个“级别”的子域。根据RFC 2818：
名称可以包含通配符*，该通配符被认为与任何单个域名组件或组件片段匹配。例如，
* .a.com与foo.a.com匹配，但与bar.foo.a.com不匹配。
f * .com匹配foo.com但不匹配bar.com。
我认为我需要的是以下证书：
*.foo.com，它将与例如foo.com，www.foo.com匹配。 （尽管我不清楚*.a.com是否与a.com本身匹配。）*.ny.foo.com与new-york.ny.foo.com，buffalo.ny.foo.com等匹配。一旦我们的站点扩展，最终我将需要50个这样的证书来匹配所有状态为所有人服务。我的问题是：
这个方案正确吗？在上述情况下，如果用户访问
ca.foo.com，他们将获得*.foo.com或*.ca.foo.com的证书吗？如何确保用户将所有这些子域视为我们的合法拥有者？例如，如果用户访问
foo.com，则访问mountain-view.ca.foo.com，而这些是不同的证书，他们会得到警告吗？有什么方法可以确保其浏览器这些证书共享同一所有者？#1 楼
理论上：一个
*恰好匹配一个级别（因此*.foo.com不匹配foo.com），但是名称中可以有多个
* ，如果所有SSL实现均忠实地遵循RFC 2818，则只需三个证书，其名称为：
并且，如果实现确实非常善于遵循RFC 2818和X.509的复杂性，那么您甚至可以使用一个证书，在其“主题替代名称”扩展中列出上面的三个字符串。
现在，理论和实践在理论上完全匹配。您可能会对浏览器的实际操作感到惊讶。我建议您尝试一下；可以使用OpenSSL命令行工具创建一些示例证书（例如，请参阅此页面以获取一些指南）。
评论
这似乎不适用于“主题替代名称”扩展名。 foo.bar.baz.example.com未包含baz.example.com的证书，该证书也具有* .baz.example.com和*。*。baz.example.com作为备用名称。似乎只考虑了第一个通配符。 Firefox和Chrome都抱怨。我正在使用nginx作为服务器。
–蓝色
2015年3月15日在3:54
如我所写，RFC 2818声明的内容和浏览器的功能是不同的。浏览器的限制要多得多。 RFC 6125更接近实际发生的情况。 （服务器种类在这里并不重要，仅证书内容和Web浏览器都可以。）
–汤姆韭菜
2015年3月16日0:00，
我看到的与@blueyed相同，浏览器抱怨证书是否具有多个子域通配符ala *。*。baz.example.com。在没有浏览器抱怨的情况下，似乎不可能有多个子域通配符。
–马恩
15年8月10日在20:59
据我所知，RFC 2818几乎没有谈论通配符，除了“使用[RFC2459]指定的匹配规则执行匹配”。 RFC 2459已过时。更新之后，您将获得的所有信息是“该规范未解决包含通配符的主题替代名称的语义。具有特定要求的应用程序可以使用此类名称，但必须定义语义。”该规范似乎是RFC 6125，以一种相当绕开的方式指出，双通配符是非法的。似乎在规范上和实践中双通配符都是非法的。
–Thanatos
2015年8月31日23:22
有关RFC 2459的部分与通配符无关； RFC 2459（及其后续版本RFC 3280和5280）没有讨论通配符。 RFC 2818中的句子描述了通配符：“名称可以包含通配符*，该通配符*被认为与任何单个域名组件或组件片段匹配”；该语句不是对RFC 2459规则的解释，而是附加的匹配规则。
–汤姆韭菜
15年8月31日在23:51
#2 楼
RFC 6125是最近才出现的，并不是所有人都实现的，但是它试图澄清其中的一些问题。它收集RFC 2818和其他协议的RFC中的身份规范。如果可以的话，我建议您遵循RFC 6125。通配符证书的相关部分为6.4.3和7.2（实际上不鼓励使用通配符证书）。从您的问题尚不清楚您是否要运行单个Web服务器（或至少能够在单个IP地址后全部运行它），或者如果每个站点都具有证书（因此每个站点都有一个IP地址，因为通常对SNI的支持不是很好）。 >
您可以拥有带有多个主题备用名称（SAN）的单个证书。问题来自具有两个通配符标签的情况，可能没有明确指定（
*.*.foo.com）。如果双通配符有效，则具有以下3个SAN DNS条目的证书应起作用：
foo.com *.foo.com *.*.foo.com 但是，由于它可能不起作用（取决于客户端的实现，可能不受您的控制），并且因为您可以列出50个州，所以您可能有52个SAN DNS条目：
每个州）
如何确保用户将所有这些子域视为我们合法拥有的
？例如，如果用户访问foo.com，则
mountain-view.ca.foo.com，并且这些证书是不同的证书，
他们会收到警告吗？有什么方法可以确保其浏览器
这些证书共享同一所有者？
这是一个棘手的问题，因为它取决于用户对证书验证过程的熟悉程度。您可以获得扩展验证证书（尽管我认为可能不允许使用通配符EV证书），该证书会显示绿色的条。这将在大多数浏览器中提供一些“所有权”标签。之后，浏览器的界面本身可能会令人困惑（例如，蓝色栏中的Firefox的“由（未知）运行”，这实际上并没有帮助）。最终，用户可以去检查您的证书以查看证书颁发给了哪些SAN。但是，我怀疑许多人会这样做并理解其含义。
评论
这是4年前。客户端支持多个通配符深度的状态是什么？是否有人对任何主流浏览器都知道这一点：Chrome，Safari，Firefox，IE，Edge，Opera？
–voutasaurus
16年2月28日在21:17
据我所知，@voutasaurus仍然有效（RFC 6125尚未在所有客户端中完全实现）。我认为没有人尝试将多个通配符级别视为可添加到任何规范的功能。
–布鲁诺
16年2月28日在21:30
#3 楼
http://www.digicert.com/welcome/wildcard-plus.htm表示此外，DigiCert WildCard ssl证书在允许您保护任何子域方面是独一无二的。您的域，包括带有一个证书的多个级别的子域。例如，您用于
* .digicert.com com的WildCard可以包含server1.sub.mail.digicert.com作为使用者的备用名称。
评论
CA在其营销材料中所说的内容应谨慎解释。验证名称的方式并不取决于名称，而是取决于客户端的实现以及它们如何遵循规范。如果仔细阅读，这句话可能意味着他们将为* .digicert.com和SAN为server.sub.mail.digicert.com颁发证书，而不一定是证书允许任何级别的任何子域一旦发出。
–布鲁诺
13年4月3日，0：31
我只是和他们聊天。 Bruno是正确的-使用通配符证书，它们最多可以添加10个单个名称，但是您还可以购买额外的通配符并将其添加为SAN名称。他们还将发行原始证书的副本，您可以在其中添加另一组名称，而无需支付额外费用，尽管这将需要额外的IP。他们提供了用于添加名称的Web UI，并且重新发行是免费的。根据要求，每个证书最多可以允许30个名称。听起来像是一项不错的服务，类似于AJ Henderson所说的StartSSL。
–同步
13年6月21日在13:45
评论
除了这个问题的确切主题外，值得注意的是，您还可以执行foo.com/state/city，这对用户非常友好。要回答您的最后一个问题-浏览器将验证证书与您所在的站点匹配，并且由受信任的CA颁发，并且在该时间点有效。从foo.com到bar.baz.foo.com不会触发任何警告，就像跟随从foo.com到bar.com的链接一样。浏览器不在乎是否涉及子域。
这听起来很像Stack Exchange在其网站上设置TLS时遇到的问题之一。
找到了博客文章：nickcraver.com/blog/2013/04/23/…
您可以作弊并使用city-state.foo.com（破折号）代替点。那么您将只有一个级别，并且只需要一个通配符* .foo.com以及foo.com作为subject-alternative-names。