通配符证书还是 SAN 多域名证书：多子域场景下怎么选
手上有一堆子域名要签发证书时，通配符和 SAN 多域名证书都能解决问题，但在验证方式、变更成本和安全边界上差别明显。本文按实际运维场景拆开比较两者的取舍，并说明 CertbotX 中的落地方式。
本文目录
不少团队的证书策略是从一个尴尬时刻开始的：运维同学发现 api.example.com 的证书快到期了，顺手想续，结果一看清单，www、api、admin、grafana、status 一共七八个子域，每张证书到期时间都不一样，像一排随时会响的闹钟。这时候通常会冒出一个念头：要不直接上通配符证书，一张管所有？
这个念头方向没错，但"一张管所有"和"一张管很多"是两回事，通配符证书和 SAN 多域名证书的区别就在这里。
两种证书到底覆盖什么
通配符证书（如 *.example.com）覆盖该域名的所有一级子域，不管你以后加多少个子域都不用改证书。注意它只覆盖一级：*.example.com 管得住 api.example.com，管不住 v1.api.example.com，也不包含裸域 example.com 本身，裸域得单独加进 SAN 里。
SAN 多域名证书则是把若干个确定的名字写进一张证书的 Subject Alternative Name 扩展里，比如 www.example.com、api.example.com、example.com 三个名字共存于一张证书。写进去什么就覆盖什么，名单之外的一概不认。
验证方式的硬约束
这是最容易被忽略、但影响最大的一条：申请通配符证书必须走 DNS-01 验证。ACME 协议里 Let's Encrypt 明确规定通配符域名只能用 DNS 质询来验证控制权，HTTP-01 不行。这意味着你的自动化流程必须能调用 DNS 服务商的 API 去写 TXT 记录。如果 DNS 托管在一个没有 API、或者权限不在你手上的平台上，通配符证书在自动化层面基本就走不通了。
SAN 证书没有这条限制，HTTP-01 就能完成，适合 Web 服务器直接暴露在 80 端口、且域名都指向同一台机器的场景。
另外有个实用技巧：如果 DNS 主区不想开 API 权限，可以把 _acme-challenge 记录 CNAME 委托到一个专门用于验证的子域或独立 DNS 区，只给那个区开 API 写权限。这样既能自动化 DNS-01，又不把主域的 DNS 钥匙交出去。
变更成本和爆炸半径
通配符的优势在于"名单永远不用改"。新上一个子域，证书不用动，直接配好服务就能用。SAN 证书则相反：每加一个新名字就得重新签发一次证书。如果子域增减频繁，SAN 证书的签发频率会比较高，还可能撞上 ACME 的速率限制。
但硬币的另一面是爆炸半径。通配符证书的私钥一旦泄露，攻击者可以为任意子域搭建仿冒站点，而且因为大家习惯把同一张证书铺到很多台机器上，私钥的分布面往往也更广，泄露概率随之上升。SAN 证书泄露的影响范围被限制在名单里的那几个名字。所以对安全要求高的环境，一种常见折中是：对外、面向用户的一批子域用通配符，内部管理面（admin、grafana 之类）单独签发窄范围的证书，私钥不混用。
还有一个部署层面的细节：同一张证书部署到多台机器时，任意一台续期失败都会导致那台机器证书过期。通配符用得越广，需要盯住的部署点就越多。
怎么选
几个判断口径：
- 子域数量多、还会持续增加，且 DNS 有 API 或能做 CNAME 委托——通配符。
- 名字固定、就三五个，服务器能直接做 HTTP-01——SAN，流程最简单。
- 需要覆盖多级子域（如
*.api.example.com）——通配符按层级分别申请，SAN 解决不了这类模式问题。 - 私钥想控制分发范围——倾向 SAN 或多张窄证书，而不是一张通配符铺满全网。
在 CertbotX 中实践
CertbotX 对 DNS-01 提供了 CNAME 委托支持：可以把 ACME 质询委托到独立的验证区完成通配符签发，不必暴露主域 DNS 权限。签发后证书会由 ACME 流程自动管理，到期前自动重新签发，并支持向 Agent、EdgeOne 或其他 CDN 自动部署，每次部署留有记录可供审计。对"通配符铺到多个接入点"这种场景，自动部署加部署审计能直接回答"哪台机器上的证书换了没有"这个最常见的告警源头问题。