内部服务的泛域名证书：自建私有 CA 还是 Let's Encrypt DNS-01
内部 *.svc.example.internal 这类泛域名证书，常见两条路：自己维护一个私有 CA，或者用公共 CA 走 DNS-01 委托验证。两条路在信任链、续期自动化和边界条件上差别很大，按场景拆开比较。
本文目录
很多团队第一次给内部服务上 HTTPS 时，都会卡在同一个问题上：浏览器不认自签证书，公网 CA 又验不了你的内网域名。于是一拍脑袋搭了个私有 CA，三个月后才发现真正的麻烦不是签证书，而是让每一台客户端都信任它。
这两条路的取舍，值得摊开说清楚。
私有 CA：一切自主，也一切自理
自建 CA（用 openssl、step-ca 或 Vault PKI 都行）最大的诱惑是自由：想签什么名字签什么名字，包括纯内网域名、IP 证书、甚至十年有效期——虽然你不该这么做。
代价是信任分发。公网 CA 的根证书早就在操作系统和浏览器的信任库里躺着，而你的私有根证书需要亲手推进每一台客户端：员工笔记本、CI runner、容器镜像、移动端 App。漏掉任何一个，就是一条"证书不受信任"的告警。而且信任库会过期、会被镜像重建冲掉、会在新员工入职时缺席——这不是一次性工作，是一项长期运维责任。
撤销和轮换也是坑。私有根 CA 一旦泄露或需要轮换，你要重新分发所有客户端的信任配置。公网 CA 遇到同样的事，浏览器厂商帮你兜底。
公共 CA + DNS-01：借公网的信任，验内网的域名
很多人有个误会：内网域名就不能用公共 CA。其实只要这个域名在公网 DNS 里有记录（哪怕解析到内网 IP，或者干脆不解析到任何可达地址），Let's Encrypt 这类 CA 就能通过 DNS-01 验证签发——它只检查你能不能控制域名的 TXT 记录，从不需要访问你的服务器。
这条路的好处很直接：
- 信任链现成。所有客户端开箱即信，零分发成本。
- 泛域名可以签。
*.internal.example.com没问题。 - 续期可以全自动。90 天有效期听起来烦，但自动化之后反而是好事——强制你的签发管线保持健康，证书永远不会"忘了续"。
限制也要认账：
- 域名必须是公网注册的。
example.internal、.lan、.corp这类非公有后缀，公共 CA 一概不签，这是 CA/B 论坛的基线要求，没有商量余地。 - 签不了 IP 证书（Let's Encrypt 不提供）。必须给服务配域名。
- DNS API 凭据要进签发流程，这把钥匙的权限范围要想清楚。
另外一个小坑：证书域名会出现在证书透明日志（CT log）里。如果内部命名规则敏感（比如暴露了项目代号），要么接受，要么用泛域名把细节藏起来。
怎么选
一句话判断标准：客户端归不归你管。
- 客户端五花八门（浏览器、第三方工具、移动设备、外包人员的机器）：选公共 CA + DNS-01。私有 CA 的信任分发会拖垮你。
- 客户端是少量受控的工作负载（服务网格内的 mTLS、内部数据库互联）：私有 CA 反而更干净，不需要公网域名，不依赖外部服务，有效期策略自己定。
- 两者都有？那就两条都用，别硬拧。mTLS 用私有 CA，对人和浏览器暴露的入口用公共证书，这是很常见的组合。
DNS-01 方案里还有个值得用的技巧：CNAME 委托。把 _acme-challenge.internal.example.com CNAME 到一个专门的验证区域（比如 acme-dns-zone.example.net），签发自动化只需要这个区域的写权限，主区域的 DNS 凭据完全不用下发。这把"DNS API 钥匙权限过大"这个最大的顾虑消掉了。
在 CertbotX 中实践
上面说的 CNAME 委托正是 CertbotX 支持的 DNS-01 模式：把挑战记录委托到独立验证域后，CertbotX 完成 ACME 自动签发，并在到期前自动重新签发，不需要人工盯日历。签发完成后可以自动部署到 Agent、EdgeOne 或 CDN，每次部署留有记录，方便审计哪张证书在什么时候推到了哪个端点。对"证书签了但忘了部署"这类低级事故，这算是把流程缺口堵上了。
需要核实的细节，建议直接看这几处：