4. 证书类型与标准
在设备身份体系中，证书不是一张“电子身份证”那么简单，它是一份由CA签名、遵循严格语法和语义的标准数据结构。理解X.509证书的字段构成、扩展机制以及不同设备证书的用途差异，是设计证书生命周期管理策略的基础。本章从证书结构出发，逐步展开扩展字段、策略与CPS，并对比TLS客户端证书、代码签名证书等典型设备证书的差异。
一、X.509证书的核心结构
X.509 v3证书由三大部分组成：待签名证书主体（TBSCertificate）、签名算法标识和签名值。CA对TBSCertificate的DER编码做哈希后签名，验签方用相同算法重新计算并比对，从而确认证书未被篡改。
TBSCertificate内部包含以下关键字段：
- version：版本号，v3值为2，是使用扩展字段的前提。
- serialNumber：CA分配的唯一序列号，吊销列表（CRL）和OCSP均依赖它定位证书。
- signature：CA使用的签名算法，必须与外层签名算法一致。
- issuer：签发者DN，包含C、O、OU、CN等属性。
- validity：notBefore与notAfter，定义证书有效期。
- subject：持有者DN，设备证书通常将唯一设备标识写入CN或serialNumber。
- subjectPublicKeyInfo：公钥算法及公钥值，是设备身份的核心凭据。
- extensions：v3扩展字段集合，决定证书的能力边界。
关键点：证书的“身份”由subject和subjectPublicKeyInfo共同定义，而“能做什么”几乎全部由extensions决定。设备证书设计中最容易出错的地方，往往不是DN写错，而是扩展字段缺失或误配。
二、常见扩展字段及其工程含义
扩展字段分为标准扩展和私有扩展。设备证书场景中，以下字段出现频率最高：
| 扩展字段 | OID | 作用 | 设备场景注意点 |
|---|---|---|---|
| Basic Constraints | 2.5.29.19 | 标识是否为CA证书 | 终端设备证书必须CA:FALSE，否则可被滥用签发子证书 |
| Key Usage | 2.5.29.15 | 限定密钥用途 | TLS客户端证书需digitalSignature；代码签名需digitalSignature+contentCommitment |
| Extended Key Usage | 2.5.29.37 | 细化用途场景 | clientAuth、codeSigning、serverAuth不可混用 |
| Subject Alternative Name | 2.5.29.17 | 替代身份标识 | 可放设备序列号、MAC、URI、IP，避免DN重名冲突 |
| CRL Distribution Points | 2.5.29.31 | 指定CRL下载地址 | 离线设备需评估CRL可达性，或改用OCSP/短有效期 |
| Authority Key Identifier | 2.5.29.35 | 标识签发CA公钥 | CA轮换时用于快速构建信任链 |
| Certificate Policies | 2.5.29.32 | 声明遵循的证书策略 | 用于合规审计和跨域信任映射 |
扩展字段分为critical和非critical。标记为critical的扩展，验签方必须理解并处理，否则应拒绝证书。工程实践中，Basic Constraints和Key Usage通常设为critical，而SAN、EKU等可根据兼容性设为非critical。
三、证书策略与CPS
证书策略（Certificate Policy, CP）是一份文档化声明，描述某类证书的适用场景、身份验证强度、密钥保护要求和吊销规则。它通过Certificate Policies扩展中的OID嵌入证书，供依赖方判断该证书是否满足自身安全要求。
认证业务声明（CPS, Certification Practice Statement）则描述CA在运营层面如何落实策略：包括注册流程、身份核验方式、密钥生成与存储、审计频率、CA私钥保护措施等。CP回答“证书能用于什么”，CPS回答“CA怎么做到”。
设备证书体系中，常见做法是定义多级策略OID：如1.3.6.1.4.1.99999.1.1表示高安全等级设备证书，...1.2表示普通IoT设备证书。依赖方通过策略OID决定是否接受该设备接入。
四、不同设备证书的差异对比
同样是X.509证书，TLS客户端证书、TLS服务端证书、代码签名证书在扩展配置上有本质区别：
- TLS客户端证书：EKU为clientAuth，Key Usage为digitalSignature，SAN可放设备唯一标识。用于mTLS双向认证，证明设备身份。
- TLS服务端证书：EKU为serverAuth，Key Usage为digitalSignature+keyEncipherment，SAN必须包含DNS名或IP。用于设备对外提供HTTPS服务。
- 代码签名证书：EKU为codeSigning，Key Usage为digitalSignature+contentCommitment，通常有效期较短，私钥保护要求极高，常配合时间戳服务使用。
- 设备身份证书：EKU可自定义或省略，重点在SAN中携带硬件唯一标识，有效期可能长达数年，需配合吊销机制。
# 查看证书扩展字段的常用命令
openssl x509 -in device.crt -noout -text
# 关注输出中的以下段落：
# X509v3 extensions:
# X509v3 Basic Constraints: critical
# CA:FALSE
# X509v3 Key Usage: critical
# Digital Signature
# X509v3 Extended Key Usage:
# TLS Web Client Authentication
# X509v3 Subject Alternative Name:
# DNS:device-001.example.com, othername:1.3.6.1.4.1.99999.1.1;UTF8:SN123456
五、案例与常见误区
案例：某厂商为10万台设备签发TLS客户端证书，初期未设置EKU，导致这些证书被误用于服务端身份，攻击者可利用设备证书仿冒服务端。复盘后，在证书模板中强制加入EKU=clientAuth，并将Basic Constraints设为critical CA:FALSE。
常见误区：
- 认为DN中的CN足以唯一标识设备，忽视SAN和序列号的作用，导致重名或检索困难。
- 将所有扩展设为非critical，验签方可能忽略关键限制，造成用途越权。
- 混淆CP与CPS，认为写了CP就满足合规，实际审计时CPS缺失会导致策略无法落地。
- 设备证书有效期过长且无吊销通道，私钥泄露后无法及时止损。
设备证书设计必须遵循“最小权限”原则：Key Usage和EKU只授予业务必需的用途，Basic Constraints必须为CA:FALSE，SAN必须包含可唯一追溯的标识。任何“先签发再补扩展”的做法都会在规模化运维中付出高昂代价。
掌握X.509证书结构与扩展字段的工程含义，是设备证书模板设计、合规审计和故障排查的共同基础。不同设备证书的差异，本质上体现在扩展字段的组合方式上。只有把“身份标识”和“用途约束”同时设计到位，证书才能在设备全生命周期中既可用又可控。