通配符证书和多域名 SAN 证书都能减少 SSL 证书数量，但覆盖逻辑不同。通配符证书适合同一主域名下、大量同级子域名；SAN 证书则可以在一张证书中列出多个不同主域名、子域名或服务名称。选择时不能只比较证书价格，还应考虑域名结构、验证方式、私钥暴露范围、续期频率和故障影响面。

本文核查日期为 2026 年 8 月 4 日。不同证书机构、验证等级和平台的域名数量限制及价格可能不同，购买或部署前应以当前产品页、控制台和服务协议为准。

通配符证书与 SAN 证书的核心区别

通配符证书能覆盖哪些域名？

证书名称 *.example.com 通常可以匹配：

• www.example.com

• api.example.com

• shop.example.com

但它通常不能匹配：

• example.com：主域名本身不是通配符匹配结果，需要单独加入 SAN。

• v2.api.example.com：这是更深一级的子域名。

• example.net：属于不同主域名。

因此，如果既要保护主域名又要保护一级子域名，常见做法是在同一证书中同时加入 example.com 和 *.example.com。不要看到一个星号就认为它能覆盖任意层级和任意域名。

简单判断：* 通常只替代一个完整的域名标签。*.example.com 可以替代 www，但不能同时替代 v2.api。

多域名 SAN 证书如何工作？

SAN 是 Subject Alternative Name 的缩写。现代客户端主要检查 SAN 字段，而不是只依赖证书的 Common Name。一个 SAN 证书可以明确列出：

• example.com

• www.example.com

• api.example.net

• shop.example.org

这些名称可以属于不同主域名，也可以是同一主域名下的不同子域名。证书只对已列出的名称有效；如果以后增加 cdn.example.net，而它不在 SAN 列表中，就需要重新签发或使用另一张证书。

一张 SAN 证书也可以包含通配符名称，例如同时加入 example.com、*.example.com 和 example.net。是否允许、包含多少个名称以及如何计费，取决于证书机构和平台。

验证方式有什么不同？

通配符证书需要证明你控制对应域名。对于 ACME 自动签发场景，通配符证书通常需要使用 DNS-01 验证，也就是在 DNS 中创建指定的 TXT 记录。HTTP-01 无法证明对任意子域名的控制，因此不能用于签发 ACME 通配符证书。

SAN 证书的每个名称都必须完成相应的域名控制验证。域名较多、分属不同 DNS 账号或不同团队时，验证和续期协调会更复杂。如果使用 DNS API 自动化，应采用最小权限凭据，并限制它只能修改验证所需的记录或区域。

安全性：哪一种证书风险更低？

证书类型本身并不会自动决定 TLS 是否安全。真正的差异在于私钥如何部署以及一次泄露会影响多少域名。

通配符证书的风险集中

如果把同一个通配符证书和私钥复制到十几台服务器，一台低安全等级的测试服务器泄露私钥，攻击者就可能利用该私钥冒充通配符范围内的其他子域名。服务器越多、团队越多，私钥复制和追踪越困难。

SAN 证书也可能扩大影响面

把多个重要域名放在同一张 SAN 证书中，同样会形成共享故障域。私钥泄露、证书误吊销或续期失败时，所有列出的域名都可能受到影响。

更稳妥的部署原则

• 不要为了减少证书数量而让互不相关的业务共享私钥。

• 生产、测试和开发环境应使用不同证书及私钥。

• 优先让证书和私钥留在托管证书平台、负载均衡器或 CDN 中，减少导出和复制。

• 设置自动续期、到期监控和吊销处理流程。

• 按业务边界拆分证书，控制单次泄露或配置错误的影响范围。

通配符证书和 SAN 证书的成本怎么比较？

不能仅凭“通配符更贵”或“SAN 更省钱”作出判断。免费自动化证书、商业 DV/OV/EV 证书、可导出证书和云平台托管证书的计费方式不同。实际成本通常包括：

• 证书费用：基础价格、包含的 SAN 数量、额外域名费用和验证等级。

• 运维成本：申请、DNS 验证、部署、续期、替换和故障排查所需时间。

• 基础设施成本：证书管理服务、密钥保管、自动化系统及监控成本。

• 风险成本：私钥泄露、续期失败或误吊销造成的业务中断范围。

如果同一主域名下不断创建临时或动态子域名，通配符证书可以减少反复签发和部署操作。如果域名数量稳定但跨越多个主域名，SAN 证书通常更直接。如果业务彼此独立，使用多张范围较小的证书，可能比一张“大而全”的证书更容易控制安全风险。

不同业务场景应该怎么选？

在 CDN 上部署时要注意什么？

首先确认 CDN 的证书管理方式：平台自动签发、导入自有证书，或使用云证书管理服务。然后检查域名是否全部包含在证书的 SAN 列表中。添加新的加速域名时，CDN 配置成功不代表证书一定覆盖该域名。

其次，用户到 CDN 的边缘证书与 CDN 到源站的证书是两套独立配置。边缘可以使用通配符证书，源站则可以使用范围更小的证书；只要 CDN 能正确验证源站域名和证书链即可。

最后，不要把证书文件和私钥通过聊天工具、邮件或公共代码仓库传递。导入自有证书后，应记录使用它的域名、节点、到期时间和负责人，并在替换前确认所有边缘节点都已完成部署。

常见误区

通配符证书能覆盖所有层级的子域名

不能。*.example.com 通常只覆盖一级子域名，不覆盖 v2.api.example.com。

通配符证书一定包含主域名

不一定。需要检查 SAN 列表中是否另外包含 example.com。

SAN 证书的域名不会被别人看到

证书中的 SAN 名称通常可以通过 TLS 握手和证书透明度日志被查看，因此不要把内部服务器名称当作秘密写入公开信任证书。

一张证书覆盖越多域名越划算

域名越多，续期协调、变更频率和故障影响范围也可能越大。证书数量减少不等于总成本一定降低。

选择前检查清单

1. 列出需要保护的所有主域名和子域名。

2. 画出域名层级，确认通配符是否真的能匹配。

3. 检查主域名是否需要作为独立 SAN 加入。

4. 确认未来是否会频繁增加子域名或新主域名。

5. 确定证书将部署到多少台服务器、CDN 或负载均衡器。

6. 评估私钥共享范围和单点泄露的影响。

7. 确认域名验证、自动续期和到期告警方式。

8. 比较证书费、额外 SAN 费、运维成本和风险成本。

常见问题

*.example.com 包含 example.com 吗？

通常不包含。若两者都要使用，应确认 SAN 中同时列出了 example.com 和 *.example.com。

一个 SAN 证书可以包含通配符域名吗？

可以，前提是证书机构和产品允许，并完成相应的域名控制验证。

通配符证书可以用于多个服务器吗？

技术上可以，但通常需要复制同一个私钥，会扩大私钥泄露的影响面。应优先评估集中 TLS 终止或按系统拆分证书。

哪一种更适合 CloudFront 或其他 CDN？

取决于加速域名结构。同一主域名下大量动态子域名可评估通配符证书；多个不同主域名可使用 SAN 或多张证书。还需遵守对应 CDN 的证书区域、验证和域名数量规则。

结论

通配符证书的优势是灵活覆盖同一主域名下的同级子域名，SAN 证书的优势是明确覆盖多个不同域名。两者都能减少证书数量，也都可能因为共享私钥和扩大覆盖范围而增加风险。

如果子域名会频繁变化，可以优先评估通配符证书；如果域名固定但跨越多个主域名，可以优先评估 SAN 证书；如果系统属于不同团队或安全边界，拆分为多张证书通常更容易管理。最终选择应以域名结构、自动化能力、私钥管理和故障影响面为依据，而不是只比较购买页面上的单一价格。

CloudFlew 提供 CDN 与 SSL 相关服务。部署前应确认加速域名的覆盖范围、证书链、私钥匹配和源站 HTTPS 配置，并以当前产品页面及服务条款为准。

参考资料

1. Let's Encrypt：Challenge Types，核查日期：2026-08-04

2. AWS Certificate Manager：Certificate Characteristics，核查日期：2026-08-04

3. AWS Certificate Manager：Supported Certificate Types，核查日期：2026-08-04

4. CA/Browser Forum：TLS Baseline Requirements，核查日期：2026-08-04