一个域名一张证书，还是一张通配符证书打全场？

团队的子域名一旦超过十几个，证书管理就会冒出一个经典问题：到底是每个域名各签一张证书，还是签一张 *.example.com 通配符证书，所有服务共用？两种方案都能把 HTTPS 跑起来，但运维成本和安全边界差得不少，值得掰开看。

先看验证方式这个硬约束

通配符证书只能通过 DNS-01 验证签发，这是 ACME 协议的硬性规定，没有商量余地。也就是说你必须能在 DNS 里自动写 TXT 记录——要么 DNS 服务商有可用 API，要么用 CNAME 把 _acme-challenge 委托到一个支持自动化修改的区域。

单域名证书则自由得多：HTTP-01 往站点根目录放个文件就能过，DNS-01 也行。如果你的 DNS 服务商 API 不好用，或者域名解析托管在客户那边、你拿不到写权限，单域名 + HTTP-01 往往是唯一能走通的路。

反过来说，如果服务藏在防火墙后、80 端口根本不能对外，HTTP-01 走不通，这时候不管签不签通配符，都得想办法做 DNS-01。

泄露影响面：一把钥匙开几扇门

通配符证书最大的争议点在这里。一张证书配一份私钥，哪个服务要用就得拷一份过去。私钥分布得越广，泄露概率越高；而一旦泄露，影响的是所有挂在这张证书下的子域名，吊销重签等于全线换锁。

单域名证书天然做了隔离。某台机器上的私钥出了问题，吊销重签只影响那一个服务。这个特性在共享主机、多团队协作或者把证书分发给边缘节点的场景里很值钱。

所以一个粗略的判断标准是：证书要落地的地方越多、越杂，越应该考虑拆开来签。

运维成本和证书透明度日志

通配符证书的好处很实际：一张证书，一次续期，新增子域名不用动证书流程。如果子域名是动态生成的（比如给每个租户分配 tenant-a.example.com），通配符几乎是唯一选择——你总不能用户注册完再现场等证书签发。

但通配符有个容易被忽略的副作用：它在证书透明度日志里只显示为 *.example.com，外人（包括你自己的安全团队）看不出实际有哪些子域名在用。单域名证书则会把每个域名写进公开的 CT 日志，这既是信息泄露——内部系统名可能暴露，也是一种资产可观测性。有些团队恰恰靠监控 CT 日志来发现影子 IT 和钓鱼域名。

另外提一句续期：通配符证书把多个服务的命脉绑在同一次续期上，续期失败就是多个服务一起告警。单域名证书坏一张是一张。不过这种风险可以通过部署侧的手段压平。

在 CertbotX 中实践

两种方案在 CertbotX 里都走得通。如果 DNS 区域不支持直接 API 修改，可以把 _acme-challenge 用 CNAME 委托到专门的验证区域，CertbotX 会自动完成 DNS-01 验证并签发证书——通配符证书也是这条路径。签发后证书可以自动部署到 Agent、EdgeOne 或 CDN，并在到期前自动重新签发；每次部署都有记录可查，出了纰漏能顺着审计记录找到是哪台机器、哪次更新出了问题。也就是说，"通配符续期一坏全坏"的风险，可以用部署记录和自动重签来对冲掉一部分，但私钥分发范围这个根本问题，还是要靠方案选型本身解决。

怎么选

• 子域名固定、数量有限、分布在对安全性要求不同的机器上：单域名证书，隔离性好，私钥不乱跑。
• 子域名动态增长、数量大、或需要覆盖还没创建的域名：通配符证书，但要接受 DNS-01 的自动化门槛和私钥多分发的代价，并配合私钥权限控制和定期轮换。
• 两边都沾：混着用。核心支付、账号类服务用单域名证书收紧边界，面向租户的动态子域名用通配符兜底。证书本身不贵（Let's Encrypt 免费），没必要为了少签一张而把安全边界搅在一起。

想进一步核实，可以看这几处官方资料：

• Let's Encrypt 文档：通配符证书为何必须走 DNS-01
• RFC 8555：ACME 协议中挑战类型的定义
• Nginx 官方文档：HTTPS 服务器配置（含通配符证书行为说明）