4. 证书生成与申请：密钥对生成与CSR创建
好，咱们进入第四章。这一章讲的是证书生命周期里最基础、也最容易出岔子的环节——密钥对生成和CSR申请。说白了，就是给设备办一张“数字身份证”的流程。
我见过不少项目，证书申请流程走得磕磕绊绊，最后查下来，问题往往出在最开始的密钥生成和CSR字段填写上。所以这一章，咱们把每个细节都掰开揉碎了讲清楚。
4.1 密钥对生成：RSA vs ECC
密钥对，就是一把公钥和一把私钥。私钥自己藏着，公钥放到证书里给别人用。生成密钥对，是证书申请的第一步。
目前工业场景里，主流就两种算法：RSA 和 ECC。我个人的习惯是，新项目优先考虑 ECC，但老系统改造时，得先看看设备支不支持。
| 对比项 | RSA | ECC |
|---|---|---|
| 密钥长度 | 2048 / 4096 位 | 256 / 384 位 |
| 安全强度 | 2048位 ≈ 112位对称 | 256位 ≈ 128位对称 |
| 计算开销 | 高（尤其签名） | 低（约快3-5倍） |
| 证书体积 | 大（约1-2KB） | 小（约0.5-1KB） |
| 工业设备兼容性 | 极好（几乎所有设备支持） | 较好（新设备基本支持） |
生成RSA密钥对（OpenSSL示例）：
# 生成2048位RSA私钥
openssl genpkey -algorithm RSA -pkeyopt rsa_keygen_bits:2048 -out device_private.pem
# 从私钥提取公钥
openssl pkey -in device_private.pem -pubout -out device_public.pem生成ECC密钥对（OpenSSL示例）：
# 生成prime256v1（即secp256r1）椭圆曲线私钥
openssl ecparam -genkey -name prime256v1 -out device_ec_private.pem
# 提取公钥
openssl ec -in device_ec_private.pem -pubout -out device_ec_public.pem我的经验： 工业PLC和RTU这类资源受限设备，我强烈建议用ECC。有一次给一个老旧SCADA系统升级证书，设备CPU跑RSA 4096签名，每次握手耗时超过3秒，现场直接报警。换成ECC 256后，降到200毫秒以内。
4.2 证书签名请求（CSR）的创建
密钥对生成后，下一步就是创建CSR。CSR里包含了你的公钥和身份信息，然后发给CA去签名。CA签完，证书就生效了。
创建CSR时，最关键的是把身份字段填对。我见过最离谱的一次，有人把CN字段填成了设备型号，结果证书验证时域名对不上，整个产线断连了两小时。
创建CSR的命令：
# 使用RSA私钥创建CSR
openssl req -new -key device_private.pem -out device.csr -subj "/CN=plc-01.factory-a.example.com/O=FactoryA/OU=ProductionLine1/C=CN"
# 使用ECC私钥创建CSR
openssl req -new -key device_ec_private.pem -out device_ec.csr -subj "/CN=rtu-03.site-b.example.com/O=FactoryB/OU=RemoteTerminal/C=CN"4.3 CSR字段解析
CSR里的字段，每一个都有讲究。咱们一个一个看。
| 字段 | 全称 | 含义 | 工业场景填写建议 |
|---|---|---|---|
| CN | Common Name | 设备唯一标识名 | 建议使用FQDN：plc-01.factory-a.example.com |
| O | Organization | 组织名称 | 填写企业法定全称，如"FactoryA Co., Ltd." |
| OU | Organizational Unit | 部门/单元 | 填写产线编号或区域，如"ProductionLine1" |
| C | Country | 国家代码 | 两位ISO代码，如"CN" |
| ST | State/Province | 省/州 | 可选，如"Beijing" |
| L | Locality | 城市 | 可选，如"Beijing" |
| SAN | Subject Alternative Name | 主题备用名称 | 强烈建议填写，用于多域名/IP支持 |
避坑指南： 我曾经遇到一个项目，所有PLC证书的CN都填成了"PLC-001"这种短名称。结果设备上线后，TLS握手时浏览器和中间件都报域名不匹配。后来全部重新签发，浪费了整整一周。记住：CN一定要用完整的FQDN。
4.4 SAN字段的重要性
SAN字段，说白了就是给证书多绑几个“名字”。比如你的PLC既有IPv4地址，又有IPv6地址，还有多个域名，SAN就能把这些全写进去。
现在的浏览器和TLS库，基本都优先看SAN，不再只看CN了。所以SAN字段，我建议必填。
带SAN的CSR创建（通过配置文件）：
# 创建csr.conf配置文件
cat > csr.conf <4.5 知识体系总览
下面这张图，把证书生成和申请的核心流程串起来了。你跟着走一遍，心里就有谱了。
4.6 实操建议
最后，给你几个我这些年总结出来的实操建议：
- 密钥生成一定要在设备本地做。 别在PC上生成再拷过去，私钥一旦泄露，整个信任链就崩了。
- CSR字段填写前，先跟网络团队对齐。 尤其是CN和SAN里的域名、IP，必须跟实际网络配置一致。
- 保存好CSR和私钥的备份。 我习惯把CSR文件归档到版本控制里，方便追溯。私钥则用HSM或加密U盘保存。
- 测试环境先跑一遍。 正式签发前，先在测试CA上走一遍流程，确认所有字段都能通过验证。
核心要点： 证书生成和申请，看似简单，但细节决定成败。密钥对选型、CSR字段填写、SAN扩展配置，这三步走扎实了，后面的证书部署和运维才能顺风顺水。