Day 26: Certificate Chain Validation — RFC 5280 §6

Phase 1 · June 8, 2026

Agenda (2–3 hours)

• Read (90 min): RFC 5280 §6 (Certification Path Validation) — read the full section carefully. This is dense but essential.
• Study (30 min): Validation algorithm inputs, state variables, and checks
• Practice (30 min): Step through the algorithm for a real chain
• Challenge (30 min): Manual walkthrough

Path Validation Inputs (§6.1)

(a) prospective certification path of length n
(b) current date/time
(c) user-initial-policy-set (usually anyPolicy)
(d) trust anchor information (root CA cert or just its public key + DN)
(e) initial-policy-mapping-inhibit (usually FALSE)
(f) initial-explicit-policy (usually FALSE)
(g) initial-any-policy-inhibit (usually FALSE)
(h) initial-permitted-subtrees (usually no restriction)
(i) initial-excluded-subtrees (usually empty)

The trust anchor is the root CA. Its cert is not validated — it's explicitly trusted.

Basic Path Validation Loop (§6.1.3)

For each certificate i in the path (from 1 = root to n = end-entity):

Signature: Verify cert i's signature using the public key from cert i-1.

Validity period: NotBefore <= current date <= NotAfter.

Revocation: Check CRL or OCSP (implementation-specific, but required in practice).

Issuer/Subject: cert i's issuer must equal cert i-1's subject.

Name constraints: if a prior CA set nameConstraints, verify subject and SANs comply.

Basic constraints: if i < n (not end-entity), cert must have cA=TRUE.

Key usage: if i < n, cert must have keyCertSign.

Name Constraints

A CA can constrain which names its issued certs may contain:

NameConstraints ::= SEQUENCE {
    permittedSubtrees [0] GeneralSubtrees OPTIONAL,
    excludedSubtrees  [1] GeneralSubtrees OPTIONAL
}

Example: an intermediate CA with permittedSubtrees = dNSName:.amazon.com
can only issue certs with SANs ending in .amazon.com.

This is a critical security control in a multi-tenant PKI. Your provisioning system
should consider nameConstraints on any intermediate CAs it issues.

Policy Processing (§6.1.5)

Certificates can carry certificate policies (OIDs with optional qualifiers).
The validation algorithm tracks which policies are acceptable through the chain.

In practice: most private PKIs use anyPolicy and don't do granular policy processing.
But if you're integrating with a government or compliance PKI, policies matter.

For your team: understand what policies are, even if your current PKI doesn't use them.

Practice Exercise

# Run openssl path validation with explicit trust anchor
openssl verify -CAfile root.pem -untrusted intermediate.pem leaf.pem

# Introduce errors to see which check fails
# - Use an expired cert: check validity period failure
# - Use a cert from a different CA: check signature failure
# - Use a cert without cA=TRUE as intermediate: check BasicConstraints failure

openssl verify -verbose -CAfile root.pem -untrusted leaf.pem leaf.pem
# This uses the leaf as its own "intermediate" — should fail BasicConstraints

Challenge Assignment

Using the 3-cert chain from Day 15 (root → intermediate → leaf):

Manually walk through every check in RFC 5280 §6.1.3 for your chain.
For each of the 3 certs, document:

1. Signature verification: which key was used, did it pass?
2. Validity period: is the cert currently valid?
3. Issuer/subject linkage: does it match?
4. BasicConstraints check: cA flag correct for position in chain?
5. KeyUsage check: keyCertSign present where required?

Then: introduce one deliberate error (e.g., remove cA=TRUE from intermediate) and verify that openssl verify catches it with the expected error.

Resources

• RFC 5280 §6: Certification Path Validation — the authoritative reference
• RFC 5280 §6.1.3: Basic path processing loop
• RFC 5280 §4.2.1.10: Name Constraints extension
• openssl-verify(1) man page