X.509 Certificate Generator
Free X.509 certificate generator — self-signed certificates, root and intermediate CAs, and leaf certificates signed by your own CA, each linted against RFC 5280 and the CA/Browser Forum baseline requirements. Generated locally in WebAssembly.
Organisation fields — optional
Linter
Runs entirely in your browser — nothing you enter is uploaded or stored.
Generating X.509 certificates
A certificate binds a public key to a name and is signed by an issuer. Everything else — the extensions, the validity window, the constraints — exists to say what that binding may be used for. This tool produces real, correctly-formed certificates; what it cannot produce is trust.
Building a local CA
The pattern that works for development: generate a root CA, install it once in your operating system's trust store, then issue leaf certificates signed by it for whatever hostnames you need. Your browser trusts the root, so it trusts everything the root signs, and you stop clicking through warnings. Delete the root's private key when you are done with it — anyone holding it can issue certificates your machine will believe.
Read the linter
Every generated certificate is checked against RFC 5280 and the CA/Browser Forum baseline requirements. Findings are advisory here — a development certificate with a two-year lifetime is fine even though a public CA could not issue it — but they are the same checks a real issuer or a strict client applies, so they tell you in advance what would be rejected.
Frequently asked questions
Will browsers trust a certificate made here?
No, and nothing can change that except a public CA. Trust comes from the issuer already being in the browser or operating system trust store. A self-signed certificate is cryptographically identical to a trusted one — the difference is entirely whose signature is on it. These are for local development, internal services, test fixtures and private CAs.
What is the difference between the roles?
Self-signed is an end-entity certificate that signs itself: basicConstraints CA:FALSE, and it cannot issue anything. Root is a self-signed CA — CA:TRUE, meant to be installed in a trust store and to sign others. Intermediate is a CA signed by another CA. Leaf is an end-entity certificate signed by a CA you supply. Choosing root when you wanted self-signed is the usual mistake, and it produces a certificate that browsers will reject for a different reason.
Why does the linter complain about my certificate?
It checks against RFC 5280 and the CA/Browser Forum baseline requirements, which are stricter than what will technically work. A 20-year validity or a missing SAN will be flagged even though your own tooling may accept it. For a local development certificate some findings are safe to ignore; the point is that you see them rather than discover them when something rejects the certificate later.
How do I make my browser trust this?
Generate a root CA, install that root in your operating system trust store, then issue leaf certificates signed by it. Never install a leaf certificate as a trusted root — and be careful with what you add to a trust store, since a root you install can vouch for any hostname on the internet.