据我所知，SSL 证书适用*.example.com于foo.example.comand bar.example.com，但不适用于foo.bar.example.com.
通配符证书不能*.*.example.com作为其主题。example.*我猜这是因为不允许使用类似证书的事实——允许通配符之前的字符会导致恶意用户将他们的证书与错误的域匹配。
*.example.com但是，我认为允许将各种证书应用于所有子域（包括无限深度的子子域）没有任何问题。我没有看到任何站点的子域是“受信任”但子子域不是的用例。
这可能会导致很多问题。据我所知，没有办法干净地获取所有子域的证书；您要么成为 CA，要么为每个子域购买证书。
*.example.com仅限于单深度子域的原因是什么（如果有的话） ？
额外问题：同样，在通配符之前全面禁止字符是否有原因？毕竟，如果您在通配符前只允许使用点和星号，那么来自不同域的站点就不可能被欺骗。
从技术上讲，通配符的使用是在RFC 2818中定义的，它确实允许像“ *.*.example.com”或“ foo.*.bar.*.example.com”甚至“ *.*.*”这样的名称。但是，在理论和实践之间，可以说，实际上存在差异（理论和实践仅在理论上完美匹配，而不是在实践中）。Web 浏览器实施了更严格的规则，因为：
*.*.com”证书。因此，Web 浏览器将应用限制，RFC 6125试图至少记录这些限制。大多数 RFC 都是实用主义者：如果现实与规范不符，则修改规范，而不是现实。请注意，浏览器还将强制执行额外的规则，例如禁止“ *.co.uk”（但并非所有浏览器都使用相同的规则，并且它们也没有记录）。
专业 CA 也有自己的限制，比如在颁发证书之前进行身份检查测试，或者只是不愿意颁发过于宽泛的通配符证书：专业 CA 的核心业务是出售许多证书，而通配符证书没有帮助为了那个原因。恰恰相反，事实上。人们想要购买通配符证书正是为了避免购买许多单独的证书。
另一个未能付诸实践的理论是Name Constraints。使用此 X.509 扩展，CA 可以向子 CA 颁发证书，限制该子 CA，使其只能在给定的域树中颁发服务器证书。Name Constraints具有值为“”的“显式子树”的扩展将.example.com允许www.example.comand foo.bar.example.com。在该模型中，example.com域的所有者将运行他自己的 CA，受其 über-CA 的限制，只能在example.com子树中使用名称。那会很好，花花公子。
不幸的是，如果部署的实现（即 Web 浏览器）不支持 X.509 证书，并且现有浏览器不支持名称约束，那么您对 X.509 证书所做的任何事情都是毫无价值的。他们不这样做，因为没有要处理的名称限制的证书（所以那将是无用的代码），并且没有这样的证书是因为 Web 浏览器无论如何都无法处理它们。为了引导事情，必须有人开始循环，但浏览器供应商在专业 CA 之后等待，专业 CA 不愿意支持名称限制，原因与以前相同（从长远来看，这一切都归结为金钱）。
正如评论中提到的，RFC6125 很好地解释了它（摘自第 7.2 节）
现有应用程序技术的规范对通配符的允许位置不明确或不一致。
...
这些歧义可能会在客户端实现之间的身份检查行为中引入可利用的差异，并且需要过于复杂和低效的身份检查算法。
因此，基本上强制执行此行为是为了简化检查，从而提高安全性。