Chain of Trust

X.509 path building & validation · RFC 5280

Builds a real ECDSA P-256 certificate hierarchy in your browser and puts you in the validator's seat: assemble chains, run the RFC 5280 checklist, and watch valid signatures get rejected.

What is this?

When your browser connects to a website, the site presents a certificate — a signed statement that a public key belongs to a name — plus a few more certificates vouching for the first one, leading back to a root your device already trusts. Checking that chain is two different jobs: finding a sequence of certificates that link up (path building — a search problem), and judging that sequence against a checklist of rules about authority, names, dates, and revocation (path validation — RFC 5280 §6). Only one small part of that checklist is cryptography. This lab hands you a real certificate hierarchy and makes you do both jobs by hand.

Honest scope — what's real here, what isn't

Real: every certificate is real DER, generated fresh in your browser each session, signed with real ECDSA P-256 (WebCrypto) via @peculiar/x509. Every signature verdict shown is a real WebCrypto verification. The RFC 5280 §6 checks (basicConstraints, pathLen, keyUsage, nameConstraints, EKU, validity, trust anchoring) and RFC 6125/9525 hostname matching are implemented in inspectable TypeScript in this repo.
Fixture: revocation statuses are local, hard-coded inputs. This lab performs no CRL or OCSP network fetch — the teaching point is that revocation is an input to validation, not a property of the signature.
Not proven: this is a teaching subset of RFC 5280 §6, not a production validator — no policy mapping, no IP/email name constraints, no ASN.1 hardening. Keys live in memory for this session only. Not production crypto — a teaching demo.

Generating the lab PKI (19 certificates, real ECDSA P-256 signatures)…

What this lab isn't

Not a TLS handshake lab — certificates arrive here in a bag, not in a ServerHello. For the protocol around them, see crypto-lab-tls-handshake.
No Certificate Transparency — CT logs are the public, append-only record that makes mis-issuance detectable (and the natural bridge to key transparency). Named here, built elsewhere: see crypto-lab-pki-chain.
No CRL/OCSP fetching — revocation statuses are local fixtures, stated wherever they appear.
No ASN.1 parser-bug / fuzzing lab — parsing here is one trusted library, not the attack surface.
No certificate issuance / ACME flow — the lab starts after issuance has happened.

Chain of Trust

What is this?

1 · Building a path ≠ validating it

2 · You are the validator

3 · Same chain, different trust store

4 · Certificate inspector

5 · Bring your own chain

What this lab isn't