企业部署HTTPS时，通配符证书经常被当作简化管理的首选。一张证书似乎能解决所有子域名的加密问题，省去逐个申请的麻烦。实际情况并非如此。通配符证书的覆盖范围有明确的层级边界，理解这条边界，才能避免部署后出现证书不匹配的问题。
“*”只替换一个层级
通配符证书的标志是域名中带一个星号，常见格式为*.example.com。这个星号的位置和数量受严格限制：只能出现在域名最左侧，并且只能出现一次。它代表的是一个完整的域名层级，不能跨越层级匹配，也不能同时替代多个层级。
以*.example.com为例，它匹配的是www.example.com、api.example.com、blog.example.com这类直接挂在example.com下面的子域名。用日常的说法，这些通常被称为“二级子域名”或“一级子域”。无论称呼如何，它们的共同特征是星号所在位置只替换了一段字符，域名总层数没有增加。
这条规则来自RFC 6125和CA/B论坛的基线要求，主流CA机构在签发时都会遵循。通配符不能写成*.*.example.com，也不能写成api.*.example.com，这些格式在公共证书体系中不被接受。
三级子域名不在覆盖范围内
回到具体问题：*.example.com能否保护test.api.example.com？答案是不能。
test.api.example.com比api.example.com多了一层，星号无法从*.example.com的位置跨到api的下一级。这里容易产生混淆的地方在于DNS泛解析。DNS记录中的*.example.com可以匹配a.b.example.com，但SSL证书的匹配规则和DNS解析是两套不同的机制，不能互相套用。证书验证只看证书SAN字段中写了什么，浏览器不会参考DNS配置来决定是否信任一张证书。
三级子域名的实际处理方式
三级子域在业务中并不少见。SaaS平台为每个客户生成app.customer1.example.com，内部系统使用console.api.example.com，API网关下挂载v2.service.example.com，这些都属于三级或更深的层级。标准通配符证书无法直接覆盖它们，但可以通过以下方式解决。
一种做法是为三级子域所在的那一层单独申请通配符证书。如果test.api.example.com和dev.api.example.com都需要保护，可以申请*.api.example.com。这张证书可以覆盖api.example.com下的所有三级子域名。
另一种做法是使用多域名证书（SAN证书），把需要保护的三级子域名逐个列入证书的SAN列表。多域名证书没有固定的层级限制，主域名、二级子域、三级子域可以写在同一个证书里。域名数量较少时，这种方式比较直接；域名数量多、且集中在同一个父级下时，单独签发一层通配符证书通常更便于维护。
如果企业已经持有一张*.example.com的通配符证书，还可以在同一张证书的SAN列表中加入*.api.example.com，形成多通配符SAN证书。这种做法在技术上是合法的，但需要留意风险范围：同一张证书上的通配符越多，私钥一旦泄露，受影响的域名范围也越大。是否把不同层级的通配符放在同一张证书里，需要结合安全隔离要求和续期管理流程来判断。
部署前需要核对的两个细节
通配符证书默认不一定包含主域名本身。*.example.com匹配的是子域名，example.com这个裸域需要单独加入证书，或者在申请时选择包含主域名的配置。如果网站同时通过裸域和子域访问，漏掉裸域会导致其中一种访问方式报证书错误。
证书签发后，域名列表无法追加。*.example.com不能在使用过程中自动“长”出对*.api.example.com的覆盖能力。域名层级发生变化时，需要重新签发证书并完成部署切换。在规划子域结构时，把未来可能出现的层级提前纳入考虑，可以减少后续更换证书带来的操作成本。
结语
通配符证书的便利来自“一个星号只替换一层”的规则。*.example.com覆盖www.example.com，不覆盖test.api.example.com。三级子域需要单独签发对应层级的通配符证书，或者通过多域名证书逐个列入SAN。把这条层级边界弄清楚，证书选型和部署就不会踩空。
推荐阅读：
