行业新闻与博客

大型公司（特别是企业）面临的最复杂问题之一是保护复杂的数字基础设施，包括具有多级子域的网站。这种设置比您可能意识到的要多得多。

不幸的是，通配符 SSL 证书的销售方式导致了一个令人遗憾的误称，即所有这些不同级别的子域都可以使用单个通配符证书进行保护。

事实并非如此。

但是有一个解决方案，您可以在一个证书上完成所有操作。

子域的问题

子域名在这一点上是互联网的常规部分，但保护它们并不总是听起来那么简单。通配符 SSL 证书的销售目的是能够保护“无限子域”并且部分正确，但需要注意的是，所有这些子域必须位于 URL 的同一级别。

一般来说，这不是问题。但是，对于在其 Web 架构中使用多级子域的公司，它可以。特别是当它对 Wildcard 证书的功能的误解更加复杂时。

为通配符证书创建 CSR 时，将星号（*）放在要保护的子域级别。但是，另一个级别的任何其他子域都无法使用该证书。而 URL 在第二个子域级别分支的方式可能会使其变得非常复杂。让我们快速看看 URL 结构。我们将忽略协议，因为这应该始终是 HTTPS 继续前进，浏览器计划很快停止在地址栏中显示它。

ThirdLevelSubdomain.SecondLevelSubdomain.FirstLevelSubdomain.Domain.TLD /目录

如果要保护二级子域，则需要在第二级子域扩展的第一级子域之前放置一个通配符，并在该域级别使用星号。

所以它看起来像这样：

* .FirstLevelSubdomain.Domain.TLD /目录

困惑了吗？现在考虑从不同的第一级子域扩展的不同的二级子域，您可以看到这一点如何变得非常复杂。

答案是多域通配符 SSL 证书

就像行业在解释标准通配符 SSL 证书的局限性方面做得很差一样，它也有点落在多域通配符 SSL 证书上。它通常表示为多达 250 个不同的域及其所有（第一级）子域。它绝对可以做到这一点。但也有其他用例。

引用此证书的另一种合适方式是“多级通配符”。这是因为多域通配符非常适合帮助具有使用多级子域的复杂网站结构的组织。让我们来看看这可能会如何在 CSR 上发挥作用：

FQDN：domain.com
通配符SAN：*
.domain.com通配符SAN：* .mail.domain.com
通配符SAN：* .members.domain.com
通配符SAN：* .dev.domain.com
通配符SAN：* .domain2。 com
通配符SAN：* .ftp.domain2.com
通配符SAN：* .shop.domain2.com

您有效地完成了这项工作的是两个安全的网站，它们的所有第一级子域和五组二级子域。它只有一个证书。

对于大多数公司而言，使用通配符单独进行此操作会非常昂贵。仅从我们的示例中，您将需要使用七个不同的证书来完成单个多域通配符，或者更准确地说，在这种情况下，多级通配符只能使用一个。

这是所有过去一年半中上市的新型多域通配符产品的另一个理想用例。