一、密钥算法选择：RSA 与 ECC 的技术路径
1. RSA：成熟但开销较大
RSA 算法自 1977 年问世以来，始终占据 TLS 证书市场的主流，至今仍是兼容性最广的选择。其安全性基于大整数分解的数学困难性——在经典计算模型下，2048 位 RSA 密钥在可预见的未来内仍被认为是安全的。
然而 RSA 的代价是密钥尺寸和运算开销。2048 位的 RSA 公钥约为 256 字节，私钥约为 1700 字节。在 TLS 握手过程中，RSA 签名验证的计算量明显高于同等安全等级的椭圆曲线算法。对于高并发的 TLS 终止节点（如反向代理），大量 RSA 握手可能成为 CPU 瓶颈。
从证书签发角度，RSA 密钥的 CSR 可以被所有 CA 接受，不存在兼容性风险。对于需要覆盖老旧客户端（如低版本操作系统、嵌入式设备）的场景，RSA 仍是稳妥之选。
2. ECC：高效但部分场景受限
椭圆曲线密码学（ECC）以更短的密钥长度提供同等的安全等级。256 位的 ECDSA 密钥与 3072 位的 RSA 密钥在安全性上大致相当，但公钥尺寸仅为后者的十分之一。
这一优势在移动端和小程序场景中尤为突出——更短的密钥意味着更小的握手数据量、更低的计算能耗和更快的连接建立速度。对于需要优化移动网络性能的站点，ECC 是具备现实收益的选择。
但 ECC 的兼容性面略窄于 RSA。部分老旧根证书（尤其是 2015 年之前签发的）仅包含 RSA 根，不支持 ECC 中间证书链。在决策前，需确认目标 CA 是否已建立完整的 ECC 证书层级，以及用户群体中老旧设备的占比。
3. Ed25519 与后量子准备
Ed25519 作为较新的椭圆曲线方案，在安全性、性能与实现简洁性上均优于传统 ECDSA。部分前沿 CA 已支持 Ed25519 密钥的 CSR 提交，但支持范围尚不普遍。对于追求技术前沿的场景，可关注此方向的演进动态。
值得留意的是，量子计算对 RSA 和 ECC 均构成远期威胁。后量子密码（PQC）算法的标准化工作正在进行中，但目前尚无 CA 支持 PQC 证书。对于安全生命周期较长的系统（如物联网设备证书，有效期 5-10 年），建议在架构层面预留密钥算法切换的灵活性。
二、SAN 扩展字段：证书域名的架构规划
1. CN 的衰落与 SAN 的兴盛
传统上，证书的域名信息填写在 Subject 的 Common Name（CN）字段中。但自 2017 年起，主流浏览器已不再信任仅存在于 CN 中的域名——域名必须出现在 SAN（Subject Alternative Name）扩展中。
这意味着 CN 字段在当前实践中已蜕变为"展示用"的标识文本，而 SAN 扩展成为证书域名验证的唯一依据。CSR 生成时，应确保所有需要该证书覆盖的域名（包括 CN 中出现的那个）都显式列在 SAN 扩展中。
2. SAN 条目的类型与数量
SAN 扩展支持 DNS 名称和 IP 地址两种类型。DNS 类型是最常用的形式。多数 CA 对 SAN 条目数量存在上限——DV 证书通常允许多达 100 个 SAN 条目，OV 和 EV 证书的上限更为有限。
规划 SAN 列表时需考虑"未来扩展成本"。如果在 CSR 中仅列出一个域名，后续每新增一个子域名都需要重新签发证书——不仅是费用问题，更是部署窗口的协调成本。建议在 CSR 生成时，将近期可能启用的子域名一并纳入 SAN 列表。
3. 通配符与 SAN 的配合
通配符证书覆盖主域名下所有一级子域名，是 SAN 条目的补充而非替代。在以下场景中，通配符与明确 SAN 条目的配合使用是较优方案：
- 核心 Web 服务使用通配符覆盖，降低新增子域名时的证书变更频率；
- 邮件服务器域名单独列在 SAN 中——部分老旧邮件客户端对通配符证书的兼容性存在瑕疵；
- 跨域名的 API 网关场景，使用 SAN 多域名证书一次性覆盖 。
三、配置模板设计：运维一致性的保障
1. 模板化的价值
在管理数十个域名和证书的组织中，手动逐条填写 CSR 参数是低效且容易出错的。将 CSR 生成参数标准化为配置文件模板，有以下收益：
- 一致性：所有证书的密钥算法、密钥长度、签名哈希算法、SAN 条目格式均统一；
- 可审计：配置文件入版本库，每次证书变更都有记录可追溯；
- 可自动化：配置文件可直接被证书管理工具读取，无缝集成到证书自动签发与部署管线中。
2. 模板的关键字段
一份完整的 CSR 配置模板应包含以下信息块：
- 密钥参数：算法类型（RSA / ECDSA）、密钥长度（RSA 2048/3072/4096，EC P-256/P-384）、私钥存储路径；
- 主体信息：国家代码（C）、地区（ST）、城市（L）、组织名称（O）、组织单位（OU）——注意 O 和 OU 仅在 OV/EV 证书中有实际意义，DV 证书不验证组织信息；
- SAN 扩展：所有 DNS 名称的完整列表；
- 签名配置：证书签名请求的哈希算法（推荐 SHA-256 起，弃用 SHA-1）。
3. 私钥的安全边界
CSR 生成过程中最敏感的操作是私钥的产生。私钥应在最终使用的服务器上生成，而非在跳板机或共享环境中生成后传输。每次传输都扩大私钥的暴露面——即便使用加密传输，目标服务器的安全状态也未必可控。
对于高安全等级的场景，可考虑使用硬件安全模块（HSM）在安全芯片内部生成密钥对，私钥永不离片。HSM 的集成复杂度较高，但对于金融、政务等领域的核心证书，这一投入是值得的。
CSR 看似只是证书签发的"第一步"，但这一步中做出的密码学选择与架构规划，将伴随证书的整个生命周期。密钥算法关乎安全与性能的取舍，SAN 字段关乎域名的覆盖灵活度，配置模板关乎运维效率与可追溯性。在生成下一份 CSR 之前，花一些时间审视这三个维度的技术决策，远比证书到期前的匆忙替换更有价值。
