我正在开发一个网站，该网站为大型组织的加盟商提供定制网站。每个加盟商都作为单独的子域进行管理，所有内容都由一组服务器处理，这些服务器解析子域名，然后在此基础上提供正确编写的页面，以便整个网站具有标准品牌，但页面的某些部分针对每个加盟商进行定制。因此，如果根域是“delivery.com”，则某个加盟商可能将“newyork.delivery.com”作为其唯一域，而另一个加盟商可能将“chicago.delivery.com”作为其唯一域。所有网站都由单个服务器（可能是负载平衡的多个服务器）提供服务，该服务器使用“newyork”或“chicago”子域来提供类似但不同的网站，具体取决于您请求的 URL。为了避免必须为所有内容提供单独的 DNS 条目，我们使用指向单个服务器（或负载平衡器）的“*.delivery.com”通配符 DNS 条目。太棒了！
为了为该系统提供 SSL，我们去申请了“*.delivery.com”的通配符 SSL 证书，这似乎很棒，除了一件事……如果有人不小心输入了“www.newyork.delivery.com”，他们会被告知没有 SSL 证书，而且令人震惊的是，有人可能出于恶意目的欺骗他们！这肯定不是我们想要的消息类型。因此，“www.newyork.delivery.com”的 DNS 查找正确解析到我们的服务器，但在我的代码在服务器上执行之前，浏览器就确定我们拥有的通配符 SSL 证书不涵盖第二级子域，并向用户显示错误。因此，事实证明，对于 DNS 条目，“*.delivery.com”表示“delivery.com 域下的任何内容，包括多层子域”。但在请求 SSL 证书时，“*.delivery.com”表示“仅一层子域”。我如何申请一个 SSL 证书来保护整个域名，包括该域名下的所有子域名（多层深度）？除此之外，似乎我唯一的解决方案就是为我想要支持的每个完全合格的子域名创建 CNAME 条目，这样浏览器至少不会出现令人担忧的“未找到站点”错误。如果有任何其他解决方案，我将不胜感激！
答案1
标准不允许使用多级通配符证书
这曾是更直接地描述在过时的 RFC 2818, 3.1：
名称可能包含通配符
*，该通配符被视为与任何单个域名组件或组件片段匹配。例如，*.a.com匹配foo.a.com但不匹配bar.foo.a.com。f*.com匹配foo.com但不匹配bar.com。
在当前的互联网标准中，这仍然存在，但它是从另一个继承而来的（建议的） 标准。
HTTP 语义RFC 9110定义 https 证书验证的规则第 4.3.4 节：
一般而言，客户端必须使用以下定义的验证流程来验证服务身份第 6 部分的 [RFC6125客户端必须从服务的主机构造一个引用标识：如果主机是一个文字 IP 地址（第 4.3.5 节)，则引用身份是 IP-ID，否则主机是名称而引用身份是 DNS-ID。
同样的限制现在来自于RFC 6125, 6.4.3（检查通配符证书）：
如果客户端将参考标识符与 DNS 域名部分包含通配符的现有标识符进行匹配
*，则适用以下规则：
客户端不应该尝试匹配所呈现的标识符，其中通配符包含除最左边标签之外的标签（例如，不匹配
bar.*.example.net）。如果通配符是所呈现标识符中最左边标签的唯一字符，则客户端不应该与参考标识符最左边标签以外的任何内容进行比较（例如，
*.example.com匹配foo.example.com但不匹配bar.foo.example.com或example.com）。
第二条规则阻止您使用多级通配符证书，第一条规则www.*.example.com也告诉您不能拥有证书。（为了完整起见，还有第三条规则，但我没有引用它，因为它与这个问题无关。）
DNS 中的通配符可匹配多个级别
正如您所注意到的，DNS中的通配符，定义在RFC 1034, 4.3.3，匹配多个层级。
-- 另一种看待这个问题的方式是，
*标签始终与至少一个完整标签匹配，有时会匹配更多，但始终与整个标签匹配。通配符 RR 不适用：
当查询位于另一个区域时。也就是说，委派会取消通配符默认值。
当查询名称或通配符域与查询名称之间的名称已知存在时。例如，如果通配符 RR 的所有者名称为
*.X，并且区域还包含附加到 的 RRB.X，则通配符将适用于名称的查询Z.X（假设没有 的明确信息Z.X），但不适用于B.X、A.B.X或X。
（由于该规范不太明确，因此以多种方式实现，RFC 4592用在此上下文中引用没有意义的澄清和例子来更新它。）
除了不使用通配符之外，没有其他办法可以解决这个问题。这确实意味着你必须
接受这样的事实：在 DNS 中使用通配符或
停止使用通配符并在 DNS 中单独注册每个子域名。