Skip to content
ecdsa.com

Certification path validation

The algorithm of RFC 5280 §6 that decides whether a chain from a trust anchor to an end-entity certificate is valid, checking signatures, validity periods, names, constraints, policies and revocation.
Also written aspath validationchain validationcertificate verificationpath building

For each certificate from the anchor down, a validator checks that the signature verifies with the issuer's key, that the current time is within notBefore and notAfter, that the issuer name matches the previous subject, that it is not revoked, that basicConstraints and key usage permit signing certificates, that name constraints are respected and that every critical extension is understood. Policy processing adds certificate-policy checks that few applications use. The application then checks the end-entity certificate against the name it intended to reach (RFC 9525) and the required extended key usage.

Path building comes first: with cross-signs and several intermediates, the client must search for any path that ends at a trusted root, and libraries differ in how well they search. Many cross-library TLS failures are path-building failures, not validation failures.

Use the platform verifier or a maintained library rather than hand-written checks; a missing basic-constraints or EKU check has been the root cause of many certificate forgeries.

Standards and references

All terms