What this tool simplifies, and what's real
A real X.509 certificate is a binary, ASN.1 DER-encoded structure with dozens of possible fields and extensions — producing one requires a dedicated encoding library, not just the Web Crypto API. This tool signs a simplified JSON structure ({subject, issuer, publicKey}) instead, so it can demonstrate the actual chain-of-trust mechanism using nothing but real, in-browser ECDSA. Every cryptographic operation here — key generation, signing, verification — is genuine; only the wire format is simplified.
Issuing a certificate: sign the child's identity with the parent's key
"Generate" builds the chain bottom-up in terms of trust, top-down in terms of signing: the root signs its own subject and public key (a self-signed root, exactly like a real root CA), then signs the intermediate's; the intermediate, in turn, signs the leaf's.
Verifying the chain, leaf to root
- 1
Verify the leaf
Check the leaf's signature using the intermediate's public key.
- 2
Verify the intermediate
Check the intermediate's signature using the root's public key.
- 3
Verify the root
Check the root's self-signature using its own public key.
- 4
Trust, if every link checks out
One broken link anywhere in the chain is enough to reject the whole thing.
Why tampering the subject breaks verification
The signature is computed over the exact bytes of {subject, issuer, publicKey} at issuance time. "Tamper with the leaf's subject" edits that field afterward without re-signing — so verification recomputes what the signature should cover, gets a different result than what was actually signed, and rejects it. This is the identical hash-then-sign tamper-evidence property covered in the hashing and signatures module, applied to a certificate instead of a message.