无私钥仅持有CSR时如何通过命令行给CSR添加SAN字段

背景说明 #

• 自运营CA配置多套证书策略，部分策略强制要求待签名CSR必须包含SAN（主题备用名称）字段
• 受老旧证书生成工具限制，提交申请的客户端通常无法生成携带该扩展字段的合规CSR
• 现有商用证书管理产品支持在签名前添加/修改SAN字段，但仅提供GUI操作入口，无法通过脚本自动化落地
• 核心需求：在不持有CSR对应私钥、仅持有CSR源文件的前提下，通过命令行工具或编程语言为CSR添加SAN字段，生成可正常进入签名流程的有效CSR

结构逻辑验证：该操作完全可行。CSR分为公钥段、属性段两部分，拆分两部分后按需调整属性内容再重新组装，即可得到可正常解析的CSR，现有商用GUI产品已验证该逻辑可落地。
已验证问题：直接使用最新版OpenSSL修改后生成的CSR，执行-verify校验会返回异常，无法进入默认开启CSR自校验的签名流程。

核心原理澄清：OpenSSL修改CSR后执行-verify返回异常属于预期行为。CSR结构末尾的签名为请求方使用自身私钥对原始CSR内容生成的签名，只要修改CSR内任意字段（含新增SAN），原签名与新内容必然不匹配，校验无法通过。现有商用GUI工具可实现该能力，核心是其内置CA签名流程默认跳过CSR自签名校验，仅提取CSR内的公钥、主体信息用于证书签发，不要求CSR本身的自签名合法。不存在“无对应私钥生成可通过自校验的修改后CSR”的方案，该逻辑受密码学规则限制，商用工具也未突破该限制。

方案1：CA签名环节直接注入SAN（最稳定，零兼容问题） #

无需改动客户提交的原始CSR，直接在CA签名步骤通过配置强制添加SAN扩展，完全绕开修改CSR带来的校验问题，是CA行业处理不合规CSR的标准做法。
OpenSSL签名操作示例：

1. 创建扩展配置文件san_ext.cnf，写入需要添加的SAN条目：

   subjectAltName = DNS:example.com, DNS:www.example.com, IP:192.168.1.1
   

2. 执行签名命令时引用该配置，直接使用原始CSR完成证书签发：

   openssl ca -in original_client.csr -out signed_cert.crt -extfile san_ext.cnf
   

该方案完全不触碰原CSR结构，不存在CSR校验失败问题，适配所有版本的OpenSSL及CA服务端逻辑。

方案2：构造携带SAN的新CSR（适配强制要求CSR自带SAN的流程） #

如果业务流程强制要求传入的CSR本身必须携带SAN字段（而非签名时注入），可使用Python cryptography 库直接构造新CSR结构：提取原CSR的公钥、主体字段后加入SAN扩展，使用临时私钥生成占位签名满足CSR结构要求，生成的CSR可被所有标准X.509解析工具正常读取字段，与商用GUI工具生成的修改后CSR效果完全一致。
示例代码：

from cryptography import x509
from cryptography.x509.oid import ExtensionOID
from cryptography.hazmat.primitives import hashes, serialization
from cryptography.hazmat.primitives.asymmetric import rsa

# 加载客户提交的原始CSR
with open("original_client.csr", "rb") as f:
    original_csr = x509.load_pem_x509_csr(f.read())

# 按需配置要添加的SAN条目
san_entries = [
    x509.DNSName("example.com"),
    x509.DNSName("www.example.com"),
    x509.IPAddress("192.168.1.1")
]

# 构建新CSR，复制原CSR的公钥、主体、原有扩展
csr_builder = x509.CertificateSigningRequestBuilder()
csr_builder = csr_builder.subject_name(original_csr.subject)
# 保留原CSR已有的非SAN扩展
for ext in original_csr.extensions:
    if ext.oid != ExtensionOID.SUBJECT_ALTERNATIVE_NAME:
        csr_builder = csr_builder.add_extension(ext.value, critical=ext.critical)
# 新增SAN扩展
csr_builder = csr_builder.add_extension(
    x509.SubjectAlternativeName(san_entries),
    critical=False
)

# 生成临时私钥做占位签名，仅用于满足CSR结构要求，无实际校验意义
temp_private_key = rsa.generate_private_key(public_exponent=65537, key_size=2048)
modified_csr = csr_builder.sign(temp_private_key, hashes.SHA256())

# 输出修改后的CSR文件
with open("modified_csr_with_san.csr", "wb") as f:
    f.write(modified_csr.public_bytes(serialization.Encoding.PEM))

可执行以下命令验证CSR内的SAN字段是否正常写入：

openssl req -in modified_csr_with_san.csr -noout -text | grep -A2 "Subject Alternative Name"

内容的提问来源于stack exchange，提问作者bata konj harmonikas