Para cada certificado, da âncora para baixo, o validador verifica se a assinatura é válida com a chave do emissor, se o horário atual está entre notBefore e notAfter, se o nome do emissor corresponde ao titular do certificado anterior, se o certificado não foi revogado, se basicConstraints e o Key Usage permitem assinar certificados, se as restrições de nomes são respeitadas e se toda extensão crítica é reconhecida. O processamento de políticas acrescenta verificações de políticas de certificado que poucas aplicações usam. Em seguida, a aplicação confere o certificado de entidade final com o nome que pretendia acessar (RFC 9525) e com o Extended Key Usage exigido.
A construção do caminho vem antes: com assinaturas cruzadas e vários intermediários, o cliente precisa procurar qualquer caminho que termine em uma raiz confiável, e as bibliotecas diferem na qualidade dessa busca. Muitas falhas de TLS que variam de uma biblioteca para outra são falhas de construção do caminho, e não de validação.
Use o verificador da plataforma ou uma biblioteca mantida em vez de verificações escritas à mão; a falta de verificação de Basic Constraints ou de EKU foi a causa raiz de muitas falsificações de certificados.