検証者は、アンカーから下へ順に各証明書について、署名が発行者の鍵で検証できること、現在時刻が notBefore と notAfter の範囲内にあること、発行者名が 1 つ前の証明書のサブジェクトと一致すること、失効していないこと、basicConstraints と鍵用途が証明書への署名を許可していること、名前制約が守られていること、そしてすべてのクリティカルな拡張を理解できることを確認します。ポリシー処理では、証明書ポリシーの確認が加わりますが、これを使うアプリケーションはほとんどありません。その後、アプリケーションは、エンドエンティティ証明書を接続しようとした名前（RFC 9525）と、必要な拡張鍵用途に照らして確認します。
最初に行うのはパス構築です。クロス署名や複数の中間証明書がある場合、クライアントは信頼されたルートで終わるパスを探索しなければならず、その探索能力はライブラリによって異なります。ライブラリ間で起きる TLS の失敗の多くは、検証の失敗ではなくパス構築の失敗です。
自作のチェックではなく、プラットフォームの検証機能か保守されているライブラリを使ってください。基本制約や EKU のチェックの欠落は、これまで多くの証明書偽造の根本原因になってきました。