2. PKI与证书体系基础

在mTLS设备安全接入工程中，PKI（公钥基础设施）是信任的起点。设备与平台之间能否建立双向认证，取决于双方能否各自出示一张被对方信任的证书，并沿着证书链回溯到一个共同信任的锚点。理解CA层级、证书链验证、吊销机制与身份映射，是后续配置mTLS、排查握手失败、设计设备准入策略的基础。

一、CA层级与证书链

CA（Certificate Authority，证书颁发机构）是签发和管理数字证书的实体。在设备接入场景中，通常不会让根CA直接签发每一台设备的证书，而是采用分层结构：根CA（Root CA）位于信任链顶端，其证书自签名，私钥离线保存，仅用于签发中间CA；中间CA（Intermediate CA）由根CA签发，承担日常的设备证书签发工作；终端实体证书（End-Entity Certificate）即设备证书，由中间CA签发，包含设备的公钥与身份信息。

证书链就是由终端证书、中间证书、根证书依次通过数字签名串联起来的验证路径。验证时，从设备证书开始，用签发者的公钥验证其签名，逐级向上，直到根证书。根证书必须预先安装在信任库中，作为信任锚。若链中任一环节签名验证失败、证书过期或缺少中间证书，验证即告失败。

二、证书吊销：CRL与OCSP

证书在有效期内也可能因为私钥泄露、设备退役或身份变更而需要提前失效，这就是吊销。PKI提供两种主要机制来查询吊销状态：

• CRL（Certificate Revocation List，证书吊销列表）：CA定期发布一个包含所有已吊销证书序列号的列表，客户端下载后本地比对。CRL的缺点是实时性差，列表可能很大，且需要定期更新。
• OCSP（Online Certificate Status Protocol，在线证书状态协议）：客户端向OCSP响应器发送证书序列号查询，响应器返回good、revoked或unknown。OCSP实时性更好，但增加了网络往返和隐私暴露风险。OCSP Stapling由服务端在TLS握手时附带OCSP响应，减少客户端查询延迟。

在设备接入场景中，如果设备数量大、网络不稳定，建议采用OCSP Stapling或短有效期证书配合CRL的混合策略。例如，设备证书有效期设为7天，CRL每天更新一次，OCSP作为实时补充。当设备被吊销后，平台侧应同时更新CRL并通知OCSP响应器，确保下一次握手时能够拒绝该设备。

三、证书策略与设备身份映射

证书策略（Certificate Policy）通过OID标识一组规则，说明证书的适用场景和签发要求。在mTLS设备接入中，常见的策略校验包括：

• 扩展密钥用法（Extended Key Usage）：设备证书必须包含clientAuth，服务端证书必须包含serverAuth。
• 主体备用名称（SAN）：设备身份通常放在SAN中，如device-001.iot.example.com或urn:device:SN123456，而不是依赖CN。
• 颁发者白名单：平台只信任特定中间CA签发的设备证书，防止其他CA的证书混入。
• 证书策略OID：如1.3.6.1.4.1.99999.1.1表示“IoT设备接入策略”，平台可据此判断证书是否符合准入要求。

设备身份映射是将证书中的身份信息转换为平台内部设备标识的过程。例如，平台收到设备证书后，提取SAN中的device-001.iot.example.com，查询设备注册表，确认该设备已注册且状态为“激活”，然后将其映射为内部设备IDdev-2024-0001。如果证书中的身份无法映射到已注册设备，即使证书链验证通过，也应拒绝接入。

四、典型验证流程与判断依据

一次完整的mTLS设备接入，服务端对设备证书的验证顺序如下：

1. 检查证书是否在有效期内，是否包含clientAuth扩展。
2. 用中间CA公钥验证设备证书签名，再用根CA公钥验证中间CA签名，直到信任锚。
3. 检查吊销状态：优先使用OCSP Stapling，若无则查询OCSP或下载CRL。
4. 校验证书策略OID和SAN格式，提取设备身份。
5. 将设备身份映射到平台注册表，确认设备已注册且允许接入。

如果任一步骤失败，TLS握手会中断，服务端日志中通常会出现certificate verify failed、certificate revoked或unknown ca等错误。排查时应先确认信任库是否包含正确的根证书和中间证书，再检查设备证书的SAN和EKU是否符合策略，最后确认吊销状态是否正常。