定义
mTLS（Mutual TLS）即双向 TLS，在建立连接时客户端与服务器互相验证对方 X.509 Certificate，实现强身份认证。设备管理平台可要求设备使用 mTLS 接入，适用于工业、金融等高安全场景。
握手流程与校验
mTLS 在标准 TLS 握手基础上，要求客户端提交证书供服务器验证。服务器校验客户端证书的签名链、有效期、吊销状态（CRL/OCSP）及 Subject 与设备的绑定关系。设备端需预置根 CA 证书以验证服务器身份，防止中间人攻击。相比单向 TLS，mTLS 实现设备与平台的双向可信，适用于零信任架构下的设备接入。
与 DMP 的集成
设备管理平台在 MQTT Broker、HTTP API、CoAP 等接入点支持 mTLS。设备使用 X.509 证书 建立连接，平台可基于证书 Subject 或 SAN 解析设备身份，实现 Device Authentication 设备认证。证书可由平台 CA 签发或对接企业 PKI；需建立证书签发、部署、续期、吊销的完整流程，与 Device Credentials 设备凭证管理协同。
应用场景
适用于工业控制、车联网、金融终端、医疗设备等高安全物联网场景。mTLS 是设备认证的强安全方案，可满足等保、ISO 27001 等合规要求。
双向校验相对共享口令
双向 TLS 在普通传输加密之外，要求设备也出示证书。平台核验证书是否由信任的签发者签出、是否在有效期内、是否已被吊销，再看主体或备用名能否对应到唯一设备。设备同样要核验平台证书，避免连到同名的假服务。共享口令或产品密钥可以被复制到另一台设备上使用；私钥若只存在于这台设备的安全存储里，复制走证书文件而没有私钥，仍然无法完成握手。因此它证明的是“持有这把私钥的一方”，前提是私钥从未离开设备。握手失败应当停在认证之前，不能先接入再在应用层补查身份。吊销列表或在线状态查询要有缓存和失败策略：查询不了时是拒绝还是暂时放行，必须事先定，不能各接入点各做各的。和MQTT一起用时，连接层已经识别出设备，应用层不应再信任客户端随意填写的设备名。
证书链能通过握手的条件
设备出厂时要写入自己的私钥和证书，以及用来核验平台的信任锚。证书上的名称必须能在平台上找到对应设备，签发范围应限制在该产品或该租户，避免一张通用客户端证书被所有设备共用。有效期要短到可轮换，同时设备要有在过期前换证的路径；过期后连不上，也就无法再在线换证，这个循环要在设计时打破，例如允许临近过期的证书先做一次更新。时间严重不准的设备会把没过期的证书判成过期，需要规定对时和宽限。私钥不可导出，产线写入过程本身要可审计。平台侧的信任锚变更属于全体设备的兼容问题，应先双锚并存再退役旧锚。只做双向认证、不做授权也不够：证书证明你是谁，一机一密或访问策略还要决定你能对哪些主题和接口操作。没有吊销手段的长效证书，泄露后无法单台作废。
主体和设备档案对不上
证书签发给序列号，平台档案用的是另一套资产编号，握手通过了却无法绑定设备，后续权限只能放得很宽。备用名写成整个产品的通配，任何拿到该产品证书的设备都能互相冒充。只检查签发者、不检查有效期和吊销，过期或已报失的证书仍能接入。设备时间被拨到很早，用来接受测试阶段的过期证书，上线后仍不改。平台证书换了而设备里的信任锚没更新，表现为全部无法连接，容易被误判成网络故障。中间人在设备不校验平台名称时，用同链的另一张证书把流量接走。把客户端证书当成加密用途而没有数字签名用途，握手直接失败，日志却只写“网络错误”。多个接入点的吊销缓存不一致，同一张证书在这里被拒、在那里被接受。