Для каждого сертификата, начиная с якоря и вниз по цепочке, валидатор убеждается, что подпись проверяется ключом издателя, что текущее время лежит между notBefore и notAfter, что имя издателя совпадает с субъектом предыдущего сертификата, что сертификат не отозван, что basicConstraints и использование ключа разрешают подписывать сертификаты, что ограничения имён соблюдены и что каждое критическое расширение известно валидатору. Обработка политик добавляет проверки политик сертификатов, которыми пользуются немногие приложения. Затем приложение проверяет, соответствует ли сертификат конечного субъекта имени, к которому оно собиралось подключиться (RFC 9525), и есть ли в нём требуемое расширенное использование ключа.
Сначала идёт построение цепочки: при перекрёстных подписях и нескольких промежуточных сертификатах клиент должен найти любой путь, который заканчивается на доверенном корневом сертификате, а библиотеки ищут такие пути с разным успехом. Многие сбои TLS при взаимодействии разных библиотек — это сбои построения цепочки, а не её проверки.
Используйте системное средство проверки или поддерживаемую библиотеку, а не самописные проверки: отсутствие проверки основных ограничений (basic constraints) или EKU не раз становилось первопричиной подделки сертификатов.