Certificate Chain Builder Lab
TLS fails on the chain, not the leaf. You are handed a jumbled pile of X.509 certificates — decoded to their fields — and have to assemble them into a valid ordered chain, leaf to root, where each certificate is genuinely signed by the one below it (issuer → subject and AKI → SKI, not just a matching name). Then you call it: a clean trusted chain, a missing intermediate you cannot build past, an expired link, or a complete but untrusted self-signed root. Reject the decoy, find the gap, and pass.
The real job. More noise, a tighter clock.
Goal
validity as of 2026-02-01
Assemble the chain for shop.playciso.com, leaf first down to the root, then declare its verdict. One cert in the pile does not belong.
Trust store: 9A:F0:11:C2(a root is trusted only when its SKI is listed here)
Certificate pile (5 unused — click to add to the chain)
Chain (leaf at top → root at bottom)
Your verdict
What is the true state of this certificate set?
Pick a verdict to validate.
Chain so far
0 cert(s) placed, 0/0 links valid, verdict not set. Assemble the path, pick a verdict, then validate.
How certificates link
A cert is signed by the one below it only when its issuer equals that cert’s subject AND its AKI equals that cert’s SKI.
Green link — valid. Red link — broken. Amber cert — outside its validity window.
A root is self-signed (subject == issuer, SKI == AKI); it is trusted only if its SKI is in the trust store.
Live arena
4 activeadversary staging…
What this lab is
- A free, browser-based certificate lab: assemble a jumbled pile of X.509 certs into a valid ordered chain — leaf → intermediate(s) → root — then declare its verdict.
- Certs link by identity, not by name: a cert is signed by the one below it only when its issuer equals that cert’s subject AND its authority key id (AKI) equals that cert’s subject key id (SKI).
- Scenarios cover the real failure modes: a clean chain, a missing intermediate, a wrong ordering, an expired link, a rogue self-signed root, and a decoy cert that belongs to no chain.
- A root is trusted only when it is self-signed (subject == issuer, SKI == AKI) and its SKI is in the scenario’s trust store — building a complete chain is not the same as trusting it.
- Graded S–D with difficulty tiers that add plausible decoys, including a name-twin CA with the wrong SKI, so you learn to verify key ids rather than certificate names.
Frequently asked questions
What is the Certificate Chain Builder Lab?
A free, in-browser exercise where you are handed a jumbled set of X.509 certificates as decoded field summaries (subject, issuer, validity dates, CA flag, key usage, and subject/authority key identifiers) and must assemble them into a valid ordered chain from the leaf up to a trusted root, then declare whether the chain is trusted or flag the defect. It runs entirely in your browser — no account, no install, no data leaves the page.
How does a certificate chain actually link together?
Each certificate names its issuer and carries an Authority Key Identifier (AKI); the CA that signed it has a matching subject and a Subject Key Identifier (SKI). A link is valid only when the child’s issuer equals the parent’s subject AND the child’s AKI equals the parent’s SKI, and the parent is a CA that can sign certificates (CA:TRUE with keyCertSign). The chain ends at a self-signed root — one whose subject equals its issuer and whose SKI equals its AKI — and that root is trusted only if its SKI is in the relying party’s trust store.
What mistakes does it teach you to catch?
The common path-building failures: a missing intermediate that makes the chain unbuildable, certificates placed in the wrong order, an expired certificate in an otherwise valid path, a complete but untrusted self-signed root, and decoy certificates — including a name-twin CA with the right name but the wrong SKI, which teaches you to verify key identifiers instead of trusting the common name.
Is this a real certificate validator?
No. It is a teaching model of chain building and path validation using invented certificates and fixed dates, so each lesson is deterministic. It deliberately ignores revocation (CRL/OCSP), name constraints, policy OIDs and signature cryptography so the core ideas — identity-based linking, ordering, validity windows and trust anchors — stand out. Do not use it to validate production certificates.