摘要

  • RFC 9918 延续 NETCONF over TLS 的双向认证，并要求受信 CA 只向获准访问 NETCONF 的主体签发相关证书，否则其他用途证书可能被不当接纳。
  • RFC 7589 通过有序规则把叶证书或链中 CA 的指纹映射为 NETCONF 用户名；链验证、规则命中和用户名生成不是同一个判定。
  • 用户名还要接受服务器权限与 NACM 检查。TLS 成功不能证明 RPC 获准、配置已提交、设备已执行或业务结果成立。

有效的链，过大的门

证书链验证处理签名、有效期、信任锚、策略和撤销等输入。它能证明一条链在给定条件下可被接受，却不会自动证明链中每张终端证书都是为网络管理而签发。

RFC 9918 对此给出直接警告：如果部署使用受信 CA 列表，这些 CA 应只向获准访问 NETCONF 服务器的主体签发证书。若同一 CA 还为别的用途签发，后者也可能被 NETCONF 服务器不当接受。问题不是伪造证书，而是把“由谁签发”误当成“为何签发、可做什么”。

RFC 9918 同时更新 TLS 要求：TLS 1.2 双向认证仍为必须，TLS 1.3 为建议支持，支持时要优先协商，而且禁止 early data。可是新版握手并不会收窄旧的信任边界。RFC 明确保留 RFC 7589 的证书验证、服务器身份和客户端身份规则。

映射顺序决定应用身份

RFC 7589 要求服务器维护证书到 NETCONF 用户名的有序映射表。规则既可匹配叶证书指纹，也可匹配曾参与该证书链的受信 CA 指纹。命中后，再按映射类型读取显式用户名、subjectAltName 中的邮件名、DNS 名、IP 地址，或走已不推荐的 CommonName 路径。

因此，“证书被接受”之后仍有多个岔口。链可以有效但没有规则命中；CA 规则可以命中但所需字段不存在；字段存在却生成非法用户名。此时实现必须继续尝试后续规则，全部失败才终止会话。

顺序本身就是权限面。把一个宽泛 CA 规则移到精确叶证书规则之前，即使证书字节完全不变，也可能生成另一个用户名。把 san-any 换成显式映射，同样会改变应用身份而不改变 TLS。审计若只保存“mTLS 成功”，就丢掉了真正把证书接入控制面的那条规则。

服务器名称不是客户端权限

RFC 9525 要求客户端先独立构造可接受的服务器参考标识，再与服务器证书中的标识比对。这个过程回答“我连接的是不是预期服务”，还要配合有效期、撤销和服务授权等检查。

它不能反向推出客户端的管理权限。服务器名称匹配是一条服务身份记录；客户端证书链有效是一条 PKI 记录；映射得到用户名是一条应用身份记录；NACM 是否允许某项操作，则是本地授权记录。四者可以同时成功，也可以在不同位置失败。

从用户名到设备结果

RFC 6241 要求传输层给出权限已知的 NETCONF 用户名，并在会话余下时间执行这些权限。RFC 8341 的 NACM 再按用户、组、操作和内容限制访问。

一张证书因此还要经过：映射用户名、解析组、检查 RPC、检查目标数据、返回协议结果、写入目标 datastore，并在适用时把 candidate 提交到 running。随后才是设备实际采用状态、转发表变化、流量和服务观察。

成功的 <edit-config> 不一定等于成功的 commit；成功 commit 也不等于每个子系统已经实现；配置读回仍不是业务效果。RFC 9918 最有价值的管理提示，不只是升级 TLS，而是不要用握手的一盏绿灯覆盖后续所有判断。

留下可重放的准入凭据

最小凭据应保存：叶证书和链的哈希、验证时间、信任锚、策略与撤销结果；预期服务器标识；映射表版本、命中规则及顺序；命中叶证书还是 CA；映射类型、来源字段与最终用户名；NACM 组和规则；RPC 消息号与响应；目标 datastore、commit 记录、变更后读回，以及独立的网络或服务观测。

这样才能在 CA 轮换前做影子测试：新信任锚会接纳哪些证书？同一 CA 下有哪些证书属于别的用途？规则顺序会生成什么用户名？PKI 仍然可信，但它不再被迫替本地管理权限作答。

来源