但是，提供的证书却并非如此。我的子域受到很好的保护，没有出现错误，但是根域在浏览器中抛出了错误，提示无法验证身份。
将该证书与其他证书进行比较时，在类似的情况下，我看到在没有错误的情况下，使用者备用名称（SAN）列出了* .example.com和example.com，而来自Comodo的最新证书仅将* .example.com列为公用名。
没有人可以确认/澄清如果要正确保护根域也应该在SAN详细信息中列出？
当我阅读此内容时：http://www.digicert.com/subject-alternative-name.htm看来，SAN必须同时列出两者，才能按我的需要进行工作。您的经验是什么？
非常感谢。
#1 楼
SSL实现之间在如何匹配通配符方面存在一些不一致之处，但是您需要使用根作为备用名称才能与大多数客户端一起使用。对于
*.example.com证书，a.example.com应该通过www.example.com应该通过example.com不应该通过a.b.example.com可能会通过，具体取决于实现方式（但可能不会通过）。 /> 基本上，标准说
*应该匹配1个或多个非点字符，但是某些实现允许点。规范的答案应该在RFC 2818（HTTP over TLS）中：
使用
[RFC2459]指定的匹配规则执行匹配。如果证书中存在一个以上给定类型的标识（例如，一个以上的dNSName名称，则该集合中任何一个
中的匹配项都被认为是可以接受的。）名称中可能包含通配符< br字符*，被认为与任何单个域名
组件或组件片段匹配。例如，
*.a.com与foo.a.com匹配，但与bar.foo.a.com不匹配。
f*.com匹配foo.com，但不匹配bar.com。RFC 2459说：
“ *”通配符可以用作最左边的名称证书中的
组件。例如，
*.example.com将匹配a.example.com，foo.example.com等，但不匹配
example.com。
如果需要证书才能使用example.com，www.example.com和foo.example.com，您需要使用带有subjectAltNames的证书，以便拥有“ example.com”和“ * .example.com”（或example.com以及您可能需要匹配的所有其他名称。）
#2 楼
没错，根域必须是备用名称才能验证。#3 楼
我曾经使用过的每个SSL提供程序都会自动将根域作为主题备用名称添加到通配符SSL证书，因此DOMAIN.COM将自动为* .DOMAIN.COM通配符证书工作。#4 楼
基本上，为了您的需要（从整个线程开始），您的通配符证书应同时指定为根和一级通配符：“ example.com，* .example.com”
这样，单个通配符证书将覆盖根域（example.com）和任何一级子域（sub1.example.com，sub2.example.com等）。
“ * .example.com”形式的证书必须具有子域名。因此，由于星号不接受NULL作为有效名称，因此显式排除了根域。提示：Free Let's Encrypt（LE）证书颁发机构允许这样做。并非所有的证书颁发机构都遵守多级通配符。您应该始终与CA提供商联系。
#5 楼
理想情况下，通配符证书是为* .example.com生成的。为了使用此证书保护您的子域和域，您要做的就是在指向这些域的服务器上安装相同的证书。
对于-例如-您具有* .example.com的通配符证书
one.example.com-服务器1
example.com-服务器2
您需要在服务器1和服务器2上安装此证书。
评论
自2017年9月20日起，AWS Certificate Manager并非如此。
– pho3nixf1re
17年9月20日在18:42
SAN证书没有“该”根域，它可以保护多个根域。
–杰兹
18年5月23日在11:58
显然，Let'sEncryp免费TLS通配符证书不会以自动方式携带该SAN。我浪费了一天的工作，将Nginx设置归咎于对SSL通配符证书的模糊监督
–alejandrob
20年2月9日，0：05