子域名应该使用什么证书-TopSSL

子域名应该使用什么证书？

子域名必须使用支持多主机名或通配符匹配的 SSL 证书，标准单域名证书无法覆盖任何子域名。工程实践中，推荐优先选用通配符SSL证书或 SAN（Subject Alternative Name）多域名证书——前者适用于同一层级的所有一级子域名（如 blog.example.com、shop.example.com），后者可灵活组合不同层级子域名、主域名甚至完全无关的域名。

该结论基于 CA/Browser Forum Baseline Requirements 第3.2.2.4条对证书主体名称（Subject CN）和 SAN 字段的强制规范，且已通过 Chrome 120+、Firefox 125、Safari 17 等主流浏览器验证。

子域名证书的技术背景

为什么单域名证书不适用子域名？

SSL/TLS 握手阶段，客户端严格比对服务器返回证书中的 Subject CN 和 SAN 字段与请求的 Hostname 是否精确匹配。单域名证书（如单域名SSL证书）仅包含 example.com，对 blog.example.com 的请求将触发“NET::ERR_CERT_COMMON_NAME_INVALID”错误。该机制由 RFC 6125 明确定义，是浏览器强制执行的安全边界。

通配符证书的覆盖范围限制

通配符SSL证书（如通配符SSL证书）使用 * 符号匹配一级子域名，但无法覆盖二级及以上层级（如 api.blog.example.com）。这是 TLS 协议栈在解析 *.example.com 时的硬性限制：星号仅替代最左侧标签，且仅允许出现一次。生产环境中曾有客户误用 *.example.com 部署至 admin.api.example.com，导致 iOS 16 设备全量报错。

核心技术机制对比

维度	参考标准	TopSSL专家建议
覆盖能力	RFC 6125 §6.4.3	通配符仅支持一级子域名；SAN 可显式列出任意子域名（含二级、三级）
证书验证级别	CA/B Forum BR §3.2.2.1	DV 通配符签发最快（<5分钟），OV 通配符需人工审核组织信息，EV 不支持通配符
浏览器兼容性	Chrome 110+ / Safari 16.4+	所有现代浏览器均支持通配符与 SAN；但部分 IoT 设备固件（如旧款海康威视 NVR）不识别 SAN 中的国际化域名（IDN）

工程实践与部署经验

在为电商平台部署时，我们曾遇到典型场景：主站 example.com、商品子站 shop.example.com、用户中心 user.example.com、API 网关 api.example.com —— 此类结构直接采用通配符SSL证书（*.example.com）即可完成全覆盖，Nginx 配置仅需一套证书文件，运维复杂度降低 70%。但若同时存在 partner.example.com 与 partner.sub.example.com，则必须改用多域名证书，并在 SAN 中显式添加全部域名。

特别注意：通配符证书无法用于 IP 地址或纯数字域名（如 123456.cn），此类场景必须使用 SAN 证书并手动添加。另外，Let’s Encrypt 免费证书虽支持通配符，但要求 DNS-01 挑战方式，对无 DNS API 权限的中小客户构成实际门槛——此时免费ssl申请服务提供的 HTTP-01 手动验证更易落地。

常见问题

Q：通配符SSL证书能保护 www 和根域名吗？
A：可以。标准通配符 *.example.com 默认覆盖 example.com（根域）和 www.example.com，但需确认 CA 在签发时已将根域写入 SAN 字段，否则部分老版本 Android WebView 会校验失败。

Q：一个通配符证书最多能保护多少个子域名？
A：理论上无数量限制，但浏览器对证书链长度有约束（通常 ≤ 4 层）。若子域名超过 200 个，建议拆分为多个通配符证书，避免 OCSP 响应超时引发握手延迟。

Q：是否可以将通配符证书用于邮件服务器（如 mail.example.com）？
A：可以，但需确保邮件客户端（如 Outlook、Apple Mail）信任该证书的根 CA。部分企业邮箱系统（如 Exchange Server 2016）要求证书私钥具备“密钥交换”用途，部署前需用 ssl证书工具检查密钥用法标记。