证书体系：DV/OV/EV 证书区别、通配符证书、多 SAN 证书

这一章我们来聊聊证书类型。说实话，很多人在配置 TLS 时只关心「能不能用」，却不清楚不同类型的证书到底差在哪。我过去几年处理过的生产事故里，至少有三成跟证书选型不当有关。嗯，咱们今天就把这事掰开揉碎讲清楚。

1. DV / OV / EV 验证级别——信任的三个台阶

为什么同样是 HTTPS，有的网站地址栏出现公司名称，有的只显示一个小锁？答案就在验证级别上。

我个人习惯：生产环境对外服务至少用 OV 证书。DV 证书虽然快，但我曾经遇到过客户因为 DV 证书被钓鱼网站模仿域名，导致用户投诉。DV 只验证「你是域名主人」，但不验证「你是合法的公司」。EV 证书现在其实用得少了，因为 Chrome 和 Safari 已经逐步淡化绿色地址栏的展示，但银行类客户仍然坚持用 EV——说白了，这是合规需求，不是技术需求。

2. 通配符证书——一张证书管所有子域名

通配符证书的字段像 *.example.com。它能保护同一个主域名下的任意子域名，比如 www.example.com、api.example.com、blog.example.com。但注意，它不保护二级子域名（比如 sub.www.example.com 不在覆盖范围内）。

通配符证书的优势很明显：

• 管理简单：一张证书管所有子域名，不用每新增一个子服务就去申请证书。
• 降低成本：对于有几十个子域名的站点，比逐个购买单域名证书便宜很多。

但也有坑：

• 安全风险：如果私钥泄露，所有子域名的 HTTPS 都受影响。我曾在一个客户环境里发现他们把通配符证书的私钥放在了 NFS 共享目录里——嗯，那场安全审计的结果不太好。
• 灵活性差：某些 CA 要求通配符证书必须在签发时指定所有 SAN，续期时不能随意增加覆盖范围。

3. 多 SAN 证书——一张证书放多个域名

多 SAN 证书（也叫 UCC 证书）的 Subject Alternative Name 字段里可以列出多个域名。比如一张证书同时包含 example.com、www.example.com、cdn.example.net。SAN 是 X.509 标准里早就支持的特性，现代浏览器只认 SAN，不认 CN 了（事实上从 2017 年起 Chrome 就已经废弃了 CN 匹配）。

多 SAN 和通配符的区别？

我有一次维护一个跨国项目，需要同时保护 asia.example.com、eu.example.com、usa.example.com 三个不同 TLD（虽然主域名一样），通配符证书就不行，因为它只认同一个主域。最后用了一张多 SAN 证书，每个地域的域名都作为 SAN 列进去。注意：多 SAN 证书每次增加域名都需要重新签发，不像通配符那样自动覆盖新增子域名。

4. 证书体系核心结构图

下面这张图把 DV/OV/EV 的验证深度、通配符和多 SAN 的覆盖逻辑串在一起。你可以把它当作决策参考：

5. 综合选型建议

你想想看，如果只是给个人博客配 HTTPS，DV 完全可以。但要是面对企业客户产品，我建议至少 OV。至于通配符和多 SAN 怎么选，我列几个判断标准：

• 所有子域名都在同一个主域下面 → 选通配符，方便省心。
• 需要跨不同主域（比如公司收购了多个品牌） → 选多 SAN。
• 内部服务使用长域名（如 *.k8s.internal.company.com） → 注意通配符只能覆盖一层，必要时考虑多 SAN 或者分域管理。
• 安全性要求极高 → 尽量少用通配符，每个子服务独立证书，或者至少将通配符证书的私钥用 HSM 保护。