Two separate checks, easy to conflate
This tool builds the identical real ECDSA root → intermediate → leaf chain as the certificate chain builder — nothing about the key generation or signing changes. What's added is a second, entirely non-cryptographic check that real verification always runs alongside the mathematical one: is every certificate in this chain still supposed to be trusted, independent of whether its signature checks out?
What "Revoke" actually does here — and doesn't
Clicking "Revoke intermediate" doesn't touch a single key or signature. It adds the intermediate's identifier to a revocation list held only in this tool's local state — the same role a real CRL or OCSP responder plays. The intermediate's signature over the leaf is exactly as mathematically valid after revocation as before; revocation is a statement about trust, layered on top of, not baked into, the signature math.
Signature check
- •Purely mathematical — did the claimed issuer's private key produce this exact signature?
- •Unaffected by revocation — a revoked cert's old signatures remain mathematically valid forever
Revocation check
- •An operational lookup — is this certificate (or one above it in the chain) on a revocation list?
- •The only thing that changes when you click Revoke — no keys or signatures are touched
Why revoking the intermediate — not the leaf — still blocks everything under it
"Verify chain" runs the signature checks first (they still pass — nothing was tampered), then separately walks every certificate in the chain against the revocation list. Revoking the intermediate fails that second check for the leaf too, even though the leaf itself was never directly revoked: trust doesn't survive a revoked link anywhere above it in the chain. This is exactly the blast-radius containment the PKI-in-production use case describes — revoking one compromised intermediate immediately untrusts everything it ever issued, without needing to touch the root or re-issue anything at the root level.