多域名CSR就是一份包含多个域名(SAN)的证书签名请求文件,用于向CA申请一张同时保护多个域名的SSL证书,生成的关键是在OpenSSL配置中正确声明subjectAltName扩展,并确保每个域名都写进alt_names列表。
多域名CSR是什么?和单域名CSR有什么区别
CSR全称Certificate Signing Request,中文叫证书签名请求,它由申请者生成,包含公钥、组织信息、域名信息,提交给证书颁发机构(CA)后,CA用它签发SSL证书。
单域名CSR只绑定一个域名,例如www.example.com,多域名CSR利用SAN(Subject Alternative Name)扩展,把多个域名写进同一份请求文件,这样一张证书可以同时覆盖example.com、api.example.com、m.example.com,甚至不同根域如example.net。
两者的核心区别可以用表格直观对比:
| 对比项 | 单域名CSR | 多域名CSR |
|---|---|---|
| 保护域名数量 | 1个 | 多个,具体数量看CA政策 |
| SAN扩展 | 通常不包含 | 必须包含alt_names列表 |
| 证书成本 | 较低 | 按域名数量或品牌档位收费 |
| 管理复杂度 | 多张证书需分开维护 | 一张证书统一部署 |
| 适用场景 | 单站、单服务 | 主站+子域名、多品牌域名、多环境 |
行业共识认为,多域名CSR的主要价值在于减少证书数量、简化部署流程、降低运维成本,尤其适合移动端、API网关、多地区站点这类域名数量较多的业务。
如何为多个域名生成CSR?用OpenSSL实操步骤
OpenSSL是生成多域名CSR最常用的工具,Linux、macOS自带,Windows可安装Git Bash或OpenSSL客户端,以下步骤以Linux环境为例。
准备OpenSSL环境
先确认OpenSSL版本:
openssl version
建议使用OpenSSL 1.1.1及以上版本,对SAN扩展支持更完整,旧版本需要额外配置,容易出错。
编写包含SAN的配置文件
多域名CSR的关键不是命令行直接参数,而是一个独立的.cnf配置文件,直接使用openssl req -new
默认不读取SAN信息。
创建一个名为san.cnf的文件,内容如下:
[req]
distinguished_name = req_distinguished_name
req_extensions = v3_req
prompt = no
[req_distinguished_name]
C = CN
ST = Beijing
L = Beijing
O = Example Co., Ltd.
OU = IT Department
CN = example.com
[v3_req]
keyUsage = keyEncipherment, dataEncipherment
extendedKeyUsage = serverAuth
subjectAltName = @alt_names
[alt_names]
DNS.1 = example.com
DNS.2 = www.example.com
DNS.3 = api.example.com
DNS.4 = m.example.com
DNS.5 = admin.example.com
有几个容易忽略的点:
CN字段建议写主域名,但现代浏览器优先读取SAN,所以CN不再是唯一识别依据。alt_names列表必须包含CN里的域名,否则部分CA会拒绝签发。- 域名不要带
https://、端口号或路径,只写纯主机名。 - 如果需要通配符,写成
DNS.2 = .example.com,但注意部分CA限制通配符与多域名SAN混用。
执行命令生成私钥和CSR
生成2048位RSA私钥:
openssl genrsa -out example.key 2048
建议使用2048位,兼容性最好,对私钥文件设置权限:
chmod 600 example.key
然后生成CSR:
openssl req -new -key example.key -out example.csr -config san.cnf
这一步会读取配置文件中的组织和域名信息,不再交互式提问,生成后检查文件是否非空:
ls -lh example.csr example.key
验证CSR中的域名列表
提交给CA之前,务必查看CSR内容,确认SAN列表正确:
openssl req -text -noout -verify -in example.csr
输出中会有类似段落:
X509v3 Subject Alternative Name:
DNS:example.com, DNS:www.example.com, DNS:api.example.com, DNS:m.example.com, DNS:admin.example.com
如果看不到SAN扩展,说明配置文件没有被正确引用,多数失败案例都是因为用了默认配置生成,导致CA只识别到CN里的一个域名。
多域名SSL证书申请注意事项:避开这些坑
生成CSR只是第一步,向CA提交申请时还有不少实操细节。
域名验证方式的选择
多域名证书需要对列表中的每个域名完成验证,DV证书通常用DNS验证或文件验证,如果域名数量较多,DNS验证的工作量会成倍增加,业内专家指出,提前在DNS服务商处批量添加TXT记录,能显著缩短验证周期。
主域名与附加域名的关系
部分CA按“主域名+附加域名”的方式收费,主域名通常默认取CSR中的CN字段,提交前确认主域名是否正确,因为证书签发后主域名身份不会改变,改主域名需要重新申请。
通配符多域名混用的限制
并非所有CA都允许一张证书里同时包含通配符域名和普通多域名,Let’s Encrypt支持混合,但某些商业CA会要求通配符证书单独购买,申请前查阅CA的产品说明,避免生成CSR后无法签发。
私钥保管和续期
CSR与私钥一一对应,如果私钥丢失,即使CSR还在,也无法完成证书部署,续期时如果域名列表没有变化,可以使用同一份CSR,但更安全的做法是重新生成新私钥和新CSR,避免旧私钥长期存在。
国内云厂商审核差异
国内云厂商的多域名SSL证书申请通常要求企业实名认证,个人身份可选择的DV多域名产品较少,部分厂商会对附加域名做额外审核,比如要求提供域名所有权证明或网站备案信息,地域上,北京、上海等主要节点的审核流程基本一致,但部分地方管局对备案主体一致性有更细要求。
国内申请多域名SSL证书的常见场景和价格参考
多域名CSR的实际应用场景很具体,比如一个电商平台需要同时保护shop.com、m.shop.com、api.shop.com、admin.shop.com,如果买四张单域名证书,部署和续期都要做四遍,一张多域名证书能把四个域名统一管理,证书到期时间一致,监控也简单。
另一个常见场景是集团旗下多个品牌域名,例如brand-a.com、brand-b.cn、brand-c.com.cn,只要域名归属同一主体,一张多域名证书就能覆盖,比分别采购更划算。
关于国内多域名SSL证书价格,不同等级和品牌差异较大,DV(域名验证)多域名证书相对便宜,部分云厂商活动价在数百元一年,按域名数量递增,OV(组织验证)和EV(扩展验证)多域名证书价格更高,通常从数千元起,主要面向企业官网、金融、政务类站点,据公开资料,国内主流云平台多域名证书的附加域名费用一般按每个域名每年几十元到上百元不等,具体以各家控制台报价为准。
如果预算有限且域名验证条件允许,Let’s Encrypt、ZeroSSL等免费CA也支持多域名SAN证书,但需要自己完成自动化续期,人工维护成本并不低。
多域名CSR生成的几个替代方案
除了OpenSSL命令行,还有一些更轻量的方式适合不熟悉Linux的用户。
- 在线CSR生成工具:部分SSL证书服务商提供网页版生成器,填写域名列表后自动生成CSR和私钥,优点是操作简单,缺点是私钥在浏览器端生成,存在一定泄露风险。
- 云厂商控制台:国内云平台购买多域名证书时,可以直接在控制台填写多个域名,系统自动生成CSR,用户无需接触OpenSSL。
- 面板工具:宝塔、1Panel等服务器面板内置证书申请功能,支持多域名SAN配置,适合已经使用面板管理服务器的用户。
这些方案本质上都是在底层调用OpenSSL逻辑,SAN配置原理相同。
多域名CSR的核心始终只有一点:把需要保护的域名完整、准确地写进SAN扩展,无论用命令行、面板还是在线工具,提交前花一分钟验证CSR内容,能避免绝大多数签发失败。
Q&A:多域名CSR常见问题
多域名CSR必须包含主域名吗?
不一定必须,但强烈建议把主域名放在CN和alt_names的第一个位置,现代浏览器优先读取SAN,但如果某个客户端只识别CN,主域名不在CN里会导致证书不匹配,多数CA也要求CSR中的CN必须是SAN列表的一部分。
生成多域名CSR后还能增加域名吗?
不能直接修改已签发的证书,需要重新生成一份包含新域名列表的CSR,提交给CA重新签发,部分CA支持在证书有效期内免费增加SAN域名,但需要重新验证新域名所有权,已部署的服务器需要更新为新证书。
免费SSL证书支持多域名CSR吗?
支持有限,Let’s Encrypt和ZeroSSL支持多域名SAN证书,但每个域名都需要单独完成验证,且证书有效期通常为90天,国内部分免费证书产品仅支持单域名,或限制多域名数量,免费多域名证书的自动化维护成本较高,生产环境需评估可用性。
首发原创文章,作者:王坚,如若转载,请注明出处:https://idctop.com/article/671412.html





