从信任锚开始向下，验证器对每张证书检查：签名能用颁发者的密钥验证通过；当前时间位于 notBefore 与 notAfter 之间；颁发者名称与上一张证书的主体一致；证书未被吊销；basicConstraints 和密钥用法允许签发证书；名称约束得到遵守；所有关键扩展都能被识别。策略处理还会增加证书策略检查，但很少有应用使用。随后，应用程序还要根据它想要连接的名称（RFC 9525）以及所需的扩展密钥用法检查终端实体证书。
路径构建在先：存在交叉签名和多个中间证书时，客户端必须搜索任意一条终止于受信任根证书的路径，而各个库的搜索能力参差不齐。许多跨库的 TLS 故障其实是路径构建失败，而不是验证失败。
应使用平台的验证器或持续维护的库，而不是手写检查；缺少基本约束或 EKU 检查，已经是许多证书伪造事件的根本原因。