Self-Signed Certificate Generator

Features

• Generates a local RSA key pair and a self-signed X.509 v3 certificate
• Includes a SAN (subjectAltName) extension — the only thing modern browsers check
• 1024 / 2048 / 3072 / 4096-bit keys, validity from 1 day to 10 years
• Signature hash selectable: SHA-256 (most compatible), SHA-384 or SHA-512
• Private key and certificate emitted as standard PEM for nginx, Node or Python
• The certificate is assembled as ASN.1 DER by hand (browsers cannot issue one) and verified parseable with OpenSSL
• The private key never leaves the browser — no upload, no logging

How to use

1. Fill in the common name (`localhost` for local development)
2. Optionally set organisation, validity, key size and signature hash
3. Click Run — 1024 / 2048-bit keys take a couple of hundred milliseconds, 3072 / 4096-bit keys a few seconds (not a freeze)
4. Copy the two PEM blocks into separate files

FAQ

Why does the browser still warn me?

Because a self-signed certificate is not in any trust store. The root of the trust chain is the CA list built into your operating system and browser; a self-signed certificate acts as its own CA, the chain does not connect, and a warning is inevitable. To silence it locally you must import this certificate into your system's trusted root store (Keychain on macOS, Certificate Manager on Windows, distribution-specific on Linux) — and only on your own development machine, never on someone else's.

Why does the certificate need a SAN? I thought CN was enough?

That was true before 2017. Since Chrome 58, Common Name is ignored entirely and the hostname is matched against subjectAltName — a practice RFC 6125 had required all along. A certificate with only `CN=localhost` and no SAN is judged "name mismatch" in every mainstream browser today, and the error only says the certificate is bad, which easily reads as a signing mistake. This tool writes the CN into the SAN as well.

Is the generated private key secure?

The key comes from the browser's `crypto.subtle.generateKey`, which uses the system's cryptographically secure random source, so the key itself is sound. The risk is not generation but where you put it: do not commit it to Git (one commit keeps it in history forever, deleting it later does not help), do not bake it into container images, do not paste it into chat. On a dev machine you can delete it and regenerate whenever you like — it takes seconds.

Which key size and signature hash should I choose?

For local development 2048-bit + SHA-256 is enough: the most compatible and quick to generate. 1024-bit is no longer considered secure and belongs only in legacy clients you must interoperate with; 3072 / 4096-bit keys resist future factoring better but take seconds to generate and slow the handshake. On the hash, SHA-256 is accepted by virtually every client, while SHA-384 / SHA-512 give a longer, theoretically stronger digest that a few old clients may not support — when in doubt, keep SHA-256.