泛域名证书仅支持一级子域名匹配，如.example.com可覆盖blog.example.com但不支持dev.api.example.com等多级子域，这是由SSL/TLS协议和CA策略限定的固有设计限制，通配符只能替代最左侧单个标签且不可跨层。
泛域名证书本身不支持多级子域名自动兼容，这是它的固有设计限制。比如 *.example.com 只能匹配 blog.example.com、api.example.com 这类二级子域名，但无法覆盖 dev.api.example.com（三级）或 www.dev.api.example.com（四级）。这不是配置错误，而是通配符规则决定的——通配符 * 仅作用于最左侧一级，且不能跨层级生效。
为什么泛域名证书不支持多级子域
SSL/TLS 协议和 CA 颁发策略明确规定：通配符只能出现在域名最左侧的单个标签位置，且只替代该层级的一个完整标签。这意味着：
-
*.example.com→ 匹配a.example.com、b.example.com，不匹配a.b.example.com -
*.api.example.com→ 匹配v1.api.example.com、v2.api.example.com，但这是另一个独立的泛域名证书 - 不存在
*.*.example.com或**.example.com这类语法，所有主流 CA 均拒绝签发
多级子域场景下的可行方案
当业务需要保护如 user1.app.example.com、staging.api.example.com 等三级或更深层级子域时，不能依赖单张泛域名证书，需组合使用以下方式：
-
分层申请多个泛域名证书：例如同时持有
*.example.com（覆盖二级）、*.app.example.com（覆盖三级 user1.app、user2.app）、*.api.example.com（覆盖三级 staging.api、prod.api） -
选用多域名通配符证书（SAN + Wildcard）：部分 CA 提供“多域名通配符”类型，允许在一张证书中混合添加多个通配符条目，如
*.example.com、*.app.example.com、*.admin.example.com，统一管理、一次续期 -
用 SAN 证书显式列出关键多级子域：对访问频率高或对外暴露的核心三级域名（如
login.corp.example.com、docs.support.example.com），直接加入 SAN 字段；适合数量可控（通常 ≤50 个）的场景
部署与验证注意事项
无论采用哪种方案，都要注意实际落地中的约束：
- 文件验证（HTTP-01）不支持泛域名证书申请，必须使用 DNS-01 验证，即在 DNS 添加
_acme-challenge.*.example.comTXT 记录 - 若用 Let’s Encrypt，单张证书最多支持 100 个 SAN 条目，且每个通配符条目单独占用一个名额
- Kubernetes Ingress 或 Nginx 中配置时，需确保 SNI 路由正确指向对应证书；多个泛域名证书共存时，优先级由服务器配置顺序或匹配精度决定
- 私钥安全仍为关键：一张证书含多个通配符，一旦泄露，影响范围扩大，建议配合 Vault 等工具集中轮换与分发
