一、星号只占一个标签位

1. 覆盖的恰好是一层子域

一张针对某主域的通配符证书，覆盖的是该主域下的一级子域。写作时星号在左侧，形如「星号.主域」，能匹配任意一个前缀：网站入口、接口入口、静态资源入口、测试入口，都在范围内。

「任意一个前缀」是关键。前缀只能是一段，不能是两段，也不能为空。这一条决定了它能覆盖什么、不能覆盖什么，后面所有判断都从这里推出来。

2. 主域本身不在覆盖范围内

星号匹配的是「某个前缀加主域」，而主域自身没有前缀可匹配。所以只申请通配符，主域的访问仍会提示证书不匹配。

解决办法是在提交时把主域作为一个单独的名称一并写进去。多数签发方允许一张证书同时含「星号形式」与「主域本身」，两者放在同一个名称列表里。这一条被遗漏的频率很高，因为控制台里通常只填一次域名，使用者以为填了主域就是全包了。

3. 不跨层级

再深一层的名称，通配符覆盖不到。例如三层结构里的第二层子域，需要在这个层级上另配一张通配符，或者把这些名称逐个列进名称列表。

这一条纯粹是层级问题。有些团队按「子域很多，所以用通配符」来判断，结果把多层结构也当成一层，上线后才发现失败。失败表现是浏览器告警，不会提示「层级不对」，排查时容易误判成部署遗漏。

4. 不同主域之间不通用

通配符绑定在主域上。另一个独立注册的域，哪怕名字相近、同属一家单位，也不在这张证书的覆盖范围内。多个独立域并存的架构，要么各配一张，要么用带多个名称的证书把它们列在一起。

二、把域名树画出来，逐级确认

1. 先列全部主机名

不要凭印象数子域。可行做法是从三个地方取数据：解析记录、入口配置、证书现状。三份合起来去重，得到的清单往往比预期多出几个——旧活动页、早已上线的内部工具、第三方托管的后台，都在里面。

2. 按层级分组，标注覆盖率

把清单按层级归类：主域一行，一级子域一组，二级及更深的一组。然后在每组后面标注「被通配符覆盖」「需单独列入」「需另配证书」三种状态。

这一步做完，覆盖率的缺口会直接呈现出来。常见情形是一级子域几十个都能被覆盖，主域没列、二级子域五六个没着落，缺口就集中在这两处。

3. 三层以上单独安排

层级超过两层的部分，单独拉一张小表，标明每个名称的用途与归属团队。处理方式有三种：在该层级上另配一张通配符、把这些名称逐个写入名称列表、或者把入口收敛到上一层，让它们不再直接对外。

4. 算出需要几张

把上面的结果合起来，就是证书数量：一张主域通配符（含主域本身）覆盖第一层；若干个层级通配符覆盖第二层；再加减那些无法归入任何层级的独立域。数量算清楚，后面的参数怎么填、额度够不够，才有依据。

三、为什么这类证书要走解析验证

1. 没有主机名可以放文件

普通证书常用的一种验证方式，是在网站指定路径放一个校验文件。通配符没法用这条路：星号不对应任何实际主机名，签发方不知道该去哪个地址取文件。

所以这类申请普遍要求通过解析记录验证：在域名下添加一条指定的记录，签发方查询到即认为申请方控制了该区域。

2. 证明的是区域控制权

这层区别值得说清。文件验证证明的是「你能改某个网站目录」，解析验证证明的是「你能改这个域的解析」。后者权限更大，也更接近域名所有权，所以被用作通配符的门槛。

理解这一点，就能理解为什么有些环境卡住：网站放在别人的托管环境里，文件放不进去，但解析在自己手上，这条路反而通。

3. 授权范围要收窄

自动续期要程序去改解析记录，等于把改解析的能力交出去一部分。稳妥做法是把这项授权收窄：只允许改指定的一条记录，只允许在指定区域生效，并定期更换凭证。

这项配置多花十分钟，换来的是一条明确的边界——即便凭证泄露，对方也只能改那一条记录，动不了别的东西。

4. 验证记录要留存

验证通过后，把当时添加的记录内容、验证时间、操作人记下来。后续出现「为什么这个子域能用、那个不能用」的问题时，这份记录是判断依据，也能帮助接手的人理解当初的范围。

四、申请时的四项参数

1. 主域要不要一起写进去

答案通常是写。主域作为单独名称写进列表，可以省掉「主站单独再配一张」的麻烦。要注意的是，加了主域之后，证书覆盖的名称数量上限是否还够用。

2. 一张还是多张

按前面的域名树结论定，不按习惯定。一张通配符加主域，覆盖一层；层级多的架构，按层级各配一张。分几张的关键判据是「这些名称会不会同时变更」——会同时变更的放一张，各自独立演进的可以分开。

3. 名称数量上限

多数方案对一张证书能带多少个名称有上限，对通配符的数量也有单独规则。填之前先确认上限，再看自己的域名树放不放得下。放不下的部分，提前规划成第二张，别等提交时被退回。

4. 有效期与续期窗口

用短有效期的方案，续期窗口要跟着调。惯常做法是剩余寿命的三分之二处续期，但固定天数在有效期缩短后会踩空，跟随签发方给出的推荐窗口更稳。若这张证书覆盖多个关键入口，续期失败的代价比单域名大得多，独立预警要单独配一条。

五、私钥集中要提前管

1. 谁拿得到私钥

通配符的便利来自一份私钥对应一层全部名称，风险也来自这里。私钥在谁手上，谁就能为这一层的任意名称提供服务。所以第一件事是盘清私钥发到了哪些地方：几台服务器、几个容器镜像、几个配置仓库、几台开发机。

盘完常会发现几处不该有的：调试时拷到本地的一份、镜像里打包进去的一份、老配置文件里留着的一份。

2. 部署面收敛

原则是「只放在真需要的地方」。同一个入口后面若只服务一个子域，就不必用通配符，单域名证书更合适；真正需要通配符的，是那些动态新增子域、或者子域数量多到逐张管理成本过高的场景。

收敛之后写一份清单：哪台设备、哪个名称集合、谁负责。清单在轮换私钥时尤其有用。

3. 泄露后的处置

一旦确认私钥外泄，处置动作不只是换私钥，而是这一层全部名称都要重新签发并重新部署。所以日常就要准备好两件事：一是能列出受影响名称的清单，二是能在一两个小时内完成全量替换的流程。没有这两样，处置会拖成事故。

4. 透明日志的可见性差异

还有一处差异容易被忽略：逐条列名的证书会把子域名称写进公开日志，通配符不会。有人把它当隐私上的好处，也有人因此失去了「有哪些子域被签发过」的线索。对内控要求高的场景，这一点要提前想清楚，靠自己的清单补上可见性。

六、申请前后的逐级核对

1. 申请前

核对三项：域名树是否覆盖全部在用的主机名；主域是否作为单独名称写入；层级超过两层的名称是否已经安排。三项都对，再提交。

2. 签发后

拿到凭证先看名称列表：有没有星号形式、有没有主域本身、层级对不对。再看有效期起止与签发者信息。名称列表不符的，当场重签，不要带着问题上部署。

3. 上线后

逐级抽查：主域访问一次、一级子域抽查两个、二级子域各抽一个。抽查时用全新连接，防止连接复用让人误判成没生效。抽查结果记进档案。

4. 新增子域时

新增一级子域，无需任何证书动作，直接可用；新增二级子域，先确认是否已有该层级的通配符，没有就要走申请。这条规则写进变更流程，比每次临时判断省心。

结语

通配符的讲究，集中在「范围」两个字上：一层子域、主域单列、不跨层级、不跨主域。把域名树摊开逐级标注，这四条就从抽象规则变成一张能对照的表；再加上解析验证的授权收窄、私钥集中后的部署收敛，这套方案才算用得稳。

落地顺序建议这样：先列主机名、画域名树、算出需要几张；再确认主域是否写进名称列表、层级缺口怎么补；签发后逐级抽查一遍，把结果和清单一起归档。做完这三步，再有人问「新加一个子域要不要重新申请」，答案是查清单，而不是靠猜。