路径必须接到先行信任的锚
常见展示顺序是目标证书、中间CA证书、根证书；规范验证也可以从信任锚向目标逐步描述。关键是每一步发行关系与签名验证能衔接，而不是文件在列表里挨在一起，或签发者名称看起来相同。
服务器送来一个自签名证书，不会因此给客户端新增可信根。RFC 5280把信任锚当作独立输入；若用自签名证书承载锚信息，该锚证书本身不属于它所定义的待验证认证路径。
参考：[1]
取得路径与验证路径是两项工作
验证器要先有一条候选证书序列，随后检查它能否在给定条件下成立。RFC 5280把取得这条序列的过程置于路径验证算法之外；仓库检索、缓存或对端提供的中间证书，只是帮助获得候选材料。
选定信任锚后，验证还依赖日期和允许的政策等输入。因此“能找到一条链”和“本应用接受这条链”不同：改换信任配置或限制可以改变结果，也不能把对端送来的任意完整列表直接当作已经验证的路径。
参考：[1]
逐层权限和最终服务名称仍须检查
中间证书不能因为公钥会验签就任意再发证。basicConstraints标明CA资格及可选路径长度限制，keyUsage规定证书签名等用途；名称限制、有效期以及不支持的关键扩展，也会影响路径能否通过。
证书政策处理同样是验证的一部分，RFC 9618已更新其算法，避免旧步骤可能造成的指数复杂度；不能把旧树形步骤当作唯一实现。即使路径通过，TLS客户端仍须按RFC 9525核对原本要访问的服务名称，而不是只判断这条链来自某个可信CA。