PKI Hierarchy Design Lab
A certificate authority fails on structure, not math. Design a CA hierarchy for the scenario — an offline Root, online Issuing CAs — and set the properties an auditor reads straight off the certificate: online vs offline, pathLen, allowed EKUs, name constraints, validity and key. The validator scores your design against the rules that actually contain a breach: keep the Root offline, bound the path length, give every use-case its own scoped issuer, and never let a TLS issuer also sign code.
The real job. More noise, a tighter clock.
Goal
Design a CA hierarchy for the enterprise. The Root must be offline and long-lived; online Issuing CAs do the day-to-day work. Give each certificate use-case its own scoped Issuing CA — never let a TLS issuer also sign code — and keep validity and path length sane.
Required use-cases this tier: TLS server (serverAuth)Device / client (clientAuth)Code signing (codeSigning)
CA hierarchy (configure each CA)
Design score
Live best-practice score so far 19%, with 5 critical rule(s) still failing. Configure the CAs, then validate to grade and lock in a streak.
What the validator checks
Root offline, long-lived, bounded pathLen.
Issuing short-lived, pathLen 0, one use-case each, name-constrained.
Never mix code-signing with TLS on one CA.
Live arena
4 activeadversary staging…
What this lab is
- A free, browser-based PKI design lab: lay out a certificate-authority hierarchy and configure each CA, then a client-side validator scores it against real PKI best practice.
- You set the properties auditors read: online/offline, basicConstraints pathLen, allowed EKUs (serverAuth / clientAuth / codeSigning), name constraints, validity and key algorithm.
- The validator enforces the rules that actually contain a breach: offline Root, bounded path length, short-lived issuers, a dedicated name-constrained Issuing CA per use-case, and code-signing walled off from TLS.
- Each scenario names the certificate use-cases that must be issuable; harder tiers add more use-cases and stricter name-constraint and key policy — the regulated, multi-use, cross-signed estate.
- You get a 0–100 design score with per-rule findings and a use-case coverage trace, so you can see exactly which property fails and why.
Frequently asked questions
What is the PKI Hierarchy Design Lab?
A free, in-browser exercise where you design a certificate-authority hierarchy for a scenario — an offline Root, optional Intermediate/Policy CAs, and online Issuing CAs — and configure each CA: online vs offline, basicConstraints pathLenConstraint, the Extended Key Usages it may issue, name constraints, validity period and key algorithm. A client-side validator then scores your design against PKI best practice and tells you which rules pass and which fail.
What best practices does it grade?
The Root should be offline and long-lived; path length should be bounded so a CA cannot mint deep sub-CA chains; online Issuing CAs should be short-lived and set pathLen 0; each certificate use-case should ride its own name-constrained Issuing CA; a TLS-issuing CA must never also sign code; every required use-case must be issuable by a CA that chains to the offline Root; and keys should meet policy strength. Each rule is a scored finding.
Who is it for?
Security architects and engineers designing or reviewing an internal CA, people prepping for a cryptography or infrastructure-security interview, and anyone who wants to feel why Root posture, EKU scoping and name constraints matter before touching a production CA. No account or install.
Is this a real certificate authority?
No. It is a teaching model of CA-hierarchy design. It grades the structural properties — basicConstraints, EKU, nameConstraints, validity, key strength, online/offline posture — that determine a hierarchy’s blast radius, but it does not issue real certificates or validate X.509 encoding. The scenarios are invented.