“现实身份绑定可继续读证书路径与期望服务身份：信任锚来自外部政策，路径有效还需独立匹配期望服务名。握手transcript则检查这把身份公钥是否认可当前临时值、角色与版本，二者不替代本页不可伪…”
形式陈述
证书是由某个签发者用数字签名认证的结构化声明，通常含主体、公钥、有效期、签发者及扩展约束。信任锚则是验证方通过已认可渠道预先接受的公钥和约束；它不是因为“这张根证书能验自己的签名”才可信。
验证输入包括：目标证书、候选中间证书、外部信任锚集合、验证时间、允许算法、用途与策略，以及应用独立给出的期望服务名。构造一条候选路径只是找出可连接的签发关系；路径验证还要检查每一步签名、有效期、CA资格、路径长度、名称约束、用途和策略等适用条件。RFC5280 §6给出完整路径验证算法，本页不把几项检查列表冒充其全实现。
路径验证通过后，还要按应用协议进行服务身份匹配：例如连接目标是 api.example.test，客户端应比较自己事先期望的reference identifier与叶证书适当的subjectAltName条目。不能把对方证书里的名字抄过来作为自己的期望名字。最后，握手认证还要证明当前对端持有该公钥对应私钥，并把它用于当前握手。
直觉
证书把“哪个公钥被哪个机构认可用于哪个名字”组织成可审查的声明链。信任从客户端已有锚点向下传播；线上发来的一条链只是候选证据，不会自己创造新的信任起点。
路径和名字是两道不同检查。一本真实且有效的护照也不能证明持有人就是你约定要见的人；同理，某个网站有受信CA签发的证书，不表示它有权冒充另一个域名。
例子与边界
设本地信任根R，R签发中间CA I，I签发叶证书L，L含 DNS:shop.example.test。若所有签名、时间和用途检查都通过，L可得到一条到R的有效路径。然而用户要连接的是 api.example.test，名字不匹配，连接仍须拒绝。
再把I改为 CA=false。I仍能从数学上生成L的签名，但其证书没有被授予继续签发证书的资格，路径应失败。若把叶证书直接放进信任锚集合，就改变了验证输入与信任政策，不能当作“修好了原路径”。
叶证书中有一个正确服务名，也不意味着握手时任何人都能使用它。攻击者可以复制证书；必须让对端以相应私钥签这一次transcript，或者按所用握手协议给出持钥证据。反过来，正确签名也不能弥补证书过期或名字错误。
撤销状态涉及数据新鲜度、网络失败策略与缓存；“证书目前在有效期内”不会自动表示未被撤销。具体应用应声明CRL、OCSP或其他机制及失败处理，而不是在本地验签之后笼统声称身份永远可信。
推论与应用
身份检查输出通常是“某公钥被认可用于本次期望服务”，不是对这个服务内容诚实、交易可靠或操作者善意的保证。应用权限、用户登录和业务授权仍需独立规则。
本单元检查器采用预置公钥映射，所有名字都是合成 .test 标识，不访问真实站点，也不实施X.509路径验证。读者可在纸上对R→I→L例子列出每道门，但不能把这个有限例子当作证书库兼容性或完整PKIX验证测试。