单域名、多域名和通配符SSL证书怎么选：先列主机名再定覆盖范围

准备给官网、API和测试后台申请SSL证书，控制台却让你在“单域名、多域名、通配符”之间选择。先别被套餐名称带着走：把用户真正访问的主机名列出来，再看证书里的SAN能否覆盖。这篇只解决覆盖范围与运维边界，不比较价格，也不把通配符当成“所有域名通吃”。

一、先列访问名称，不按网站数量计数

一个网站可能有根域入口、www入口、API和后台；反过来，同一个主机名下的多个路径通常不需要分别增加证书名称。证书看的是连接要验证的身份，不是菜单里有几个页面。下面用保留示例域名列一份需求：

example.com
www.example.com
api.example.com
admin.dev.example.com
shop.example.net

这五项是五个明确名称。根域与www不是同一项，深层子域也不能省略；退役入口先移出清单。

重定向也不能代替覆盖：用户先访问https://example.com，再跳往www入口，第一跳仍要先完成TLS。相同IP、CNAME指向同一处或相同网页内容，都不会自动让另一个名称得到证书覆盖。

二、三种名称说明什么，没说明什么

这些是常见产品叫法，不是三个严格互斥的集合。一张证书可以同时列出明确名称和通配符名称，前提是所选CA、产品和客户端支持该组合。不要凭订单标题推测覆盖范围，最终要看签出的证书。

图注：三卡是并列概括，可以组合。通配符须共享固定后缀，“同一层级”指该父域下的直接子域；根域指这里的example.com。图片由AI生成，经技术与可读性复核。

三、通配符只吃一层，不会自动带根域

按RFC 9525第6.3节的服务名称匹配规则，通配符只能作为最左侧完整标签，且只能匹配一个标签。对*.example.com而言，www.example.com、api.example.com属于覆盖范围；example.com、admin.dev.example.com、shop.example.net则不由这一条覆盖。

需要根域就明确加入example.com；需要更深层级，就加入admin.dev.example.com，或按实际边界评估*.dev.example.com。后者也只匹配dev.example.com下的一层，并不会反过来覆盖dev.example.com本身。

不要写成*.*.example.com来试图跨层，也不要把证书通配符与DNS通配符解析混为一谈。本文讨论普通ASCII域名的HTTPS选型；国际化域名、IP地址及特定应用协议的限制还需单独核对。

四、把需求转成待申请名称清单

对于前面的五项，一种候选组合是下面四个DNS名称条目。它只是待申请清单的示意，不是已经签发的证书、CSR配置文件或执行命令：

DNS:example.com
DNS:*.example.com
DNS:admin.dev.example.com
DNS:shop.example.net

根域由第一条覆盖，www和api由第二条覆盖，深层后台与另一个域名分别列出。也可以全部写成明确名称，或按团队拆成几张证书。没有唯一答案，关键是每个需求都有来源明确的覆盖条目。

五、选通配符时，把验证和续期一起选

以本次核对的Let's Encrypt官方流程为例，通配符签发必须使用DNS-01；HTTP-01不能用于通配符签发。这个结论限定该CA和当前文档，不外推所有厂商的控制台按钮或其他验证产品。

DNS-01需要在指定_acme-challenge名称下放入对应TXT值。若希望无人值守续期，还要确认DNS服务商API、客户端插件、凭据权限和清理流程。手动添加TXT后首次申请成功，不等于下一次续期也能自动完成。

六、名称清单还要带负责人和终止点

给每个入口加上负责人和TLS终止点，明确谁验证、装在哪里、检查哪个节点。下面是可直接运行的Python 3离线清单校验，只检查重复和漏填，不检查TLS或真实域名控制权：

import csv
import io

inventory = """host,owner,endpoint
example.com,web,edge-a
www.example.com,web,edge-a
api.example.com,api,edge-b
admin.dev.example.com,dev,edge-c
shop.example.net,shop,edge-d
"""
rows = list(csv.DictReader(io.StringIO(inventory)))
for row in rows:
print(row["host"], row["owner"], row["endpoint"], sep=" | ")
assert len(rows) == len({r["host"] for r in rows}), "duplicate host"
assert all(r["owner"] and r["endpoint"] for r in rows), "missing owner or endpoint"

此处edge-a等仅是虚构标签，不是IP、生产资产或连接地址。脚本在本地已执行；将重复行或空负责人加入清单会触发断言。断言只是清单防漏检查，不应拿来实现证书授权或安全匹配。

七、申请之后，按最终材料和真实入口验收

先读签出的证书SAN，逐项对照需求表。CSR写过的名称、控制台申请过的名称和最终证书实际包含的名称是不同证据，不能互相代替。新增名称通常涉及重新申请或重签并部署新证书，不能靠编辑旧证书文本生效。

再确认服务实际加载哪份证书。存在CDN或负载均衡时，边缘与源站是不同TLS连接，应该分别列入部署与检查范围。名称覆盖只是其中一层；信任链、有效期、密钥配对、服务加载和真实HTTP响应仍要分别验收。

本文完成的是官方规则核对和离线清单实验，没有执行生产部署、CA签发、浏览器兼容测试或自动续期。因此不能把这份候选清单描述为“已经上线成功”。

八、提交申请前的检查清单

• 列全用户实际访问的主机名，包括重定向的第一跳。
• 根域、普通子域、深层子域和不同注册域分别核对。
• 每项需求都有明确名称或合规通配符条目覆盖。
• 核实CA支持的组合、数量限制与验证方式，不套用别家规则。
• 把续期凭据、负责人、部署位置和失败通知一起规划。
• 拿到新证书后读SAN，再验真实终止点与业务响应。

参考资料与实现入口（规则以原文及当前平台说明为准；实现入口不是CA规范）：

• RFC 9525：服务身份与通配符名称匹配
• Let's Encrypt FAQ：SAN与通配符
• Let's Encrypt：验证类型与DNS-01边界
• CertbotX