3. 证书申请流程：CSR 生成、提交、验证与签发
证书申请，说白了就是让 CA 给你签个名，证明“这把钥匙是你的”。
我见过不少团队，密钥对都生成好了，结果 CSR 里填错一个字段，整个流程就得重来。所以这一章，咱们把每一步拆开看。
3.1 CSR 是什么？
CSR（Certificate Signing Request，证书签名请求）是一个包含公钥和身份信息的文件。你把它发给 CA，CA 验证通过后，返回给你一个数字证书。
一个标准的 CSR 包含以下内容：
| 字段 | 说明 | 常见坑点 |
|---|---|---|
| CN (Common Name) | 设备域名或标识 | IoT 设备常用序列号，别填成 IP |
| O (Organization) | 组织名称 | 必须与营业执照一致 |
| OU (Organizational Unit) | 部门名称 | 可选，但建议填写 |
| L (Locality) | 城市/地点 | 不要缩写 |
| ST (State) | 省份/州 | 全称，不要用“粤”这种简称 |
| C (Country) | 国家代码（两位） | CN / US / JP，大写 |
| 公钥 | RSA/ECC 公钥 | 密钥强度要达标 |
| 签名 | 用私钥对 CSR 签名 | 证明你持有私钥 |
我的习惯：生成 CSR 前，先列一个字段检查清单。尤其是 CN，设备证书的 CN 一旦写错，TLS 握手直接失败。我曾经排查过一个现场问题，折腾了两天，最后发现是 CN 里多了一个空格。
3.2 生成密钥对与 CSR
这一步通常在设备本地完成。私钥永远不出设备，这是底线。
以 OpenSSL 为例，生成 RSA 2048 位密钥对和 CSR：
# 1. 生成私钥
openssl genrsa -out device.key 2048
# 2. 生成 CSR（交互式）
openssl req -new -key device.key -out device.csr
# 3. 或者用配置文件批量生成（推荐）
openssl req -new -key device.key -out device.csr \
-subj "/C=CN/ST=Guangdong/L=Shenzhen/O=MyCompany/OU=IoT/CN=device-001"为什么我推荐用配置文件？
- 批量部署时，手动输入容易出错
- 可以统一字段规范
- 便于版本管理
注意：私钥生成后，一定要设置合适的文件权限。我曾经见过一个项目，私钥权限是 777，等于把家门钥匙挂在门外。建议 chmod 600 device.key。
3.3 提交 CSR 至 CA
CSR 生成后，需要提交给 CA。提交方式取决于你的 CA 类型：
| CA 类型 | 提交方式 | 适用场景 |
|---|---|---|
| 企业内部 CA | API / 管理平台上传 | 设备批量入网 |
| 公有 CA（如 Let's Encrypt） | ACME 协议自动提交 | Web 服务器证书 |
| 第三方商业 CA | Web 门户上传 / 邮件 | 高信任等级证书 |
对于设备证书，我强烈建议使用 API 自动提交。手动上传几千个 CSR？那画面太美我不敢看。
3.4 身份验证：CA 如何确认“你是谁”
CA 收到 CSR 后，不会直接签发。它得先确认：这个请求确实来自声称的那个实体。
验证方式分几种：
- DV（Domain Validation）：验证域名控制权。比如在域名下放一个特定文件，或者配置一个 TXT 记录。Let's Encrypt 用的就是这种。
- OV（Organization Validation）：验证组织真实性。CA 会查工商信息，打电话确认。我经历过一次，CA 要求提供营业执照盖章件，流程走了三天。
- EV（Extended Validation）：最严格的验证。律师函级别的审核，浏览器地址栏会变绿。设备证书很少用 EV，成本太高。
设备证书的特殊性：
很多 IoT 设备没有域名，只有序列号或 MAC 地址。这时候 DV 就不适用了。我建议的做法是：
- 设备出厂时预置一个设备密钥（DPKI 方案）
- 设备首次联网时，用这个密钥向 CA 证明身份
- CA 验证通过后，签发正式证书
3.5 证书签发与下载
验证通过后，CA 会用它的根证书私钥对你的 CSR 进行签名，生成 X.509 证书。
签发过程大致如下：
- CA 从 CSR 中提取公钥和身份信息
- CA 设置证书有效期、序列号、扩展项（如 Key Usage、Extended Key Usage）
- CA 用私钥对上述内容签名
- 生成 PEM 或 DER 格式的证书文件
你拿到的证书长这样：
-----BEGIN CERTIFICATE-----
MIIDazCCAlM...
（一串 Base64 编码的内容）
-----END CERTIFICATE-----
避坑指南：我曾经遇到一个案例，CA 签发的证书里没有包含 Key Usage 扩展。结果设备用这个证书做 TLS 客户端认证时，对方直接拒绝连接。所以签发前，一定要确认 CA 的证书模板包含了必要的扩展项。
3.6 整体流程回顾
下面这张图，把整个流程串起来了：
整个流程，从生成密钥对到拿到证书，看起来步骤不少。但如果你用自动化工具（比如 ACME 客户端或自研的 CA API），其实可以做到全自动，设备上电即完成。
最后提醒一句：证书签发后，记得验证一下。用 openssl x509 -in cert.pem -text -noout 看看字段对不对，有效期对不对，扩展项全不全。别等到设备部署到现场了才发现问题——那时候改起来，成本可就高了。