Für jedes Zertifikat vom Vertrauensanker abwärts prüft ein Validator, ob sich die Signatur mit dem Schlüssel des Ausstellers verifizieren lässt, ob die aktuelle Zeit zwischen notBefore und notAfter liegt, ob der Name des Ausstellers dem Subject des vorherigen Zertifikats entspricht und ob das Zertifikat nicht widerrufen ist. Außerdem müssen basicConstraints und Key Usage das Signieren von Zertifikaten erlauben, Name Constraints müssen eingehalten sein, und jede kritische Erweiterung muss dem Validator bekannt sein. Die Richtlinienverarbeitung ergänzt Prüfungen von Zertifikatsrichtlinien, die nur wenige Anwendungen nutzen. Anschließend prüft die Anwendung das End-Entity-Zertifikat gegen den Namen, den sie erreichen wollte (RFC 9525), und gegen die geforderte Extended Key Usage.
Zuerst kommt der Pfadaufbau: Bei cross-signierten Zertifikaten und mehreren Zwischenzertifikaten muss der Client nach irgendeinem Pfad suchen, der bei einem vertrauenswürdigen Root-Zertifikat endet, und Bibliotheken suchen unterschiedlich gründlich. Viele TLS-Fehler, bei denen eine Bibliothek scheitert und eine andere nicht, sind Fehler beim Pfadaufbau, keine Validierungsfehler.
Nutze den Verifizierer der Plattform oder eine gepflegte Bibliothek statt selbst geschriebener Prüfungen; eine fehlende Prüfung der Basic Constraints oder der EKU war die eigentliche Ursache vieler Zertifikatsfälschungen.