CSR Builder & Auditor Lab
A certificate request fails on the things you cannot see in a hostname: which names it actually asserts, how strong its key is, and how it is signed. Switch between two modes — audit decoded Certificate Signing Requests and flag every mistake a modern CA would reject, or build a correct CSR for a given scenario and have it validated field by field. The lesson that ties them together: the SAN is authoritative and the CN is legacy, so modern clients ignore the Common Name entirely.
The real job. More noise, a tighter clock.
Task
Each card is a decoded Certificate Signing Request. Flag every mistake a modern public CA (or a current browser) would reject. Some CSRs are clean — flag nothing on those.
shop.northwind.example — storefront
CSRPublic TLS server certificate for the retail storefront.
Flag the mistakes
legacy-vpn.northwind.example — RSA-1024
CSRTLS server certificate for the VPN concentrator login page.
Flag the mistakes
"Northwind Corp" — no SAN
CSRTLS server certificate for the corporate intranet portal portal.northwind.example.
Flag the mistakes
api.northwind.example — SHA-1
CSRTLS server certificate for the public API gateway.
Flag the mistakes
mail.northwind.example — CN/SAN mismatch
CSRTLS server certificate for the mail transfer agent.
Flag the mistakes
*.northwind.example — clean wildcard
CSRWildcard TLS certificate for an internal platform with many short-lived subdomains.
Flag the mistakes
Live score
So far 37/42 field decisions correct, with 5 real flaw(s) missed and 0 false positive(s). Submit to grade.
What a modern CA checks
SAN is authoritative — CN is legacy and ignored by browsers, so names must live in the SAN.
RSA ≥ 2048 or EC ≥ P-256; SHA-256+ signatures; wildcards are one label only, never a bare TLD.
Live arena
4 activeadversary staging…
What this lab is
- A free, browser-based CSR lab with two modes: audit decoded Certificate Signing Requests for mistakes, or build a correct one from a scenario.
- In AUDIT mode you flag the defects a modern CA or browser rejects — a CN that is not a hostname, a missing or mismatched SAN, an undersized key, a SHA-1 signature, a wildcard misuse, or the wrong key type.
- In BUILD mode you fill a CSR form (CN, SANs, key algorithm and size) for a stated purpose and a validator checks every required hostname is covered and the key is sound.
- The one lesson underneath it all: SAN is authoritative and CN is legacy — modern clients ignore the Common Name, so the names a certificate asserts must live in the subjectAltName.
- Everything runs 100% in your browser. The optional in-browser keypair generation uses the Web Crypto API; grading is on the decoded fields, not on parsing DER.
Frequently asked questions
What is the CSR Builder & Auditor Lab?
A free, in-browser exercise in reading and writing Certificate Signing Requests. In Audit mode you are shown decoded CSRs (subject CN, O/OU, SAN list, key algorithm and size, signature algorithm) and flag the mistakes a modern CA would reject. In Build mode you are given a scenario — the hostnames to cover and the purpose — and fill a CSR form that a validator grades. It is graded with difficulty tiers; no account or install.
Why does the Common Name (CN) not matter anymore?
Because modern browsers and public CAs validate a certificate against its subjectAltName (SAN) extension and ignore the CN field entirely. A CSR with a perfect-looking CN but no SAN will not validate. The lab drills this directly: a missing SAN, or a CN that is not mirrored in the SAN, is a flaw to catch (Audit) and a check you must pass (Build).
Does it generate a real key?
Optionally, yes. In Build mode you can click to generate a genuine RSA or ECDSA keypair in your browser using the Web Crypto API — a realism touch so the exercise feels like a real openssl req workflow. The grade, however, is computed from the decoded CSR fields (coverage, CN/SAN, key size, key type, wildcard hygiene), not from parsing a real DER-encoded request.
Who is it for?
Engineers and security people who provision TLS certificates, anyone prepping for a PKI, TLS or cloud-security interview, and teams who want a fast way to build intuition for what makes a CSR get rejected — weak keys, SHA-1 signatures, CN/SAN mistakes and wildcard misuse — without touching a production CA.