Create a certificate signing request without installing OpenSSL and without handing your key
to anyone. Your browser generates the key pair with the built-in WebCrypto API, builds the
PKCS#10 request around it, and hands you two files to download — csr.pem to send
to your certificate authority and private-key.pem to keep. Nothing is uploaded,
nothing is stored, and there is no account, no email capture, and no certificate to buy at
the end of it. Most CSR generators are run by certificate resellers; this one is not selling
you anything.
Choose RSA 2048 or 4096, or ECDSA P-256 or P-384, add every host name the certificate must
cover as a Subject Alternative Name, and generate. Already have a request and want to check
what is inside it? The Decode tab parses any CSR and shows its subject, SANs, and algorithms.
For issued certificates, use the X.509 Certificate Decoder;
for server access keys, the SSH Key Generator; and to
fingerprint a file or a certificate, the Hash Generator.
If the fields below are unfamiliar, our guide to
reading an X.509 certificate explains what
each one means once the CA has signed it.
Generated in your browser, not on our server
A certificate signing request bundles a public key with the identity you want certified, and
signs the whole thing with the matching private key to prove you hold it. That signature is
the reason the private key has to exist wherever the CSR is built. When a website generates a
CSR for you server-side, it necessarily generates your private key too — and you have to
trust that it deleted it. This tool sidesteps the question: crypto.subtle.generateKey
runs in your tab, the key material never reaches the network, and the page has no backend to
send it to. Close the tab and the key is gone, which is also why you must download it before
you navigate away.
What goes in the subject
Only the Common Name is required here. Organization, Organizational Unit, Locality, State,
and Country are part of the classic Distinguished Name and matter for organization-validated
and extended-validation certificates, where the CA verifies them against public records — get
them wrong there and the order stalls. For an ordinary domain-validated certificate (which
includes everything Let’s Encrypt issues) the CA ignores them entirely, so leaving them blank
is fine. The country code must be a two-letter ISO 3166-1 code such as US,
GB, or DE; a three-letter code or a country name will be rejected.
Subject Alternative Names are the part that matters
Every host name the certificate should cover has to be listed as a SAN. Browsers no longer
look at the Common Name when matching a host, so a CSR that names example.com
only in the CN produces a certificate that fails validation. This tool adds a host-name CN to
the SAN list for you and lets you add the rest — www.example.com, API
subdomains, or a *.example.com wildcard. IP address SANs are supported too,
though public CAs will only issue them for addresses you can prove you own. Whatever you omit
cannot be added later without generating a new request.
Keep the key paired with the certificate
The certificate your CA returns is useless without private-key.pem. Store the
key with the same care as a production credential: restrictive file permissions, a secrets
manager or password manager rather than a chat message or a ticket, and a backup somewhere
you will still have access to at renewal time. If the key is ever exposed, revoke the
certificate and start over with a fresh CSR — a leaked private key lets anyone impersonate
your site, and rotating the certificate alone does not help.
Frequently asked questions
Is my private key uploaded anywhere?
No. The key pair is generated by your own browser using the built-in WebCrypto API (crypto.subtle.generateKey), and both the CSR and the private key are assembled in JavaScript on your machine. There is no server call at any point — this site is static, and nothing you type or generate is ever transmitted. You can confirm it: open your browser devtools, switch to the Network tab, and generate a key — you may see the page load its own JavaScript the first time, but nothing carries your key or your form data. Because nothing is stored, the private key is also unrecoverable — download it immediately, because closing the tab destroys it.
Should I choose RSA or ECDSA for a TLS certificate?
RSA 2048-bit is the safe default: every CA issues it and every client on the internet supports it, including very old devices and embedded systems. ECDSA P-256 gives comparable security with far smaller keys and signatures, which means faster handshakes and less bandwidth, and it is supported by every current browser and OS. Pick ECDSA P-256 for a modern public website, RSA 2048 if you need maximum compatibility or your CA or hosting platform only accepts RSA. RSA 4096 and ECDSA P-384 are for policies that mandate a higher security level; they are slower and rarely necessary. Note that the CSR key type determines the certificate key type — you cannot switch later without a new CSR.
Why do Subject Alternative Names matter, and is the Common Name still used?
Browsers stopped matching host names against the Common Name years ago. Chrome removed CN fallback in 2017, and the CA/Browser Forum Baseline Requirements now require every host name to appear in the subjectAltName extension — a certificate whose host name appears only in the CN will be rejected as invalid. That is why this tool copies a host-name CN into the SAN list automatically, and why you should list every name the certificate must cover (apex domain, www, any subdomains, or a single *.example.com wildcard) before generating. Adding a name later requires a new CSR and a reissue.
What do I do with the CSR once I have it?
Paste the CSR PEM into your certificate authority’s order form, or upload csr.pem where the CA asks for it. The CA validates that you control the names in the request — usually by DNS record, an HTTP file, or email — and then returns a signed certificate. Install that certificate on your web server alongside the private-key.pem file you downloaded here; the two must stay paired, because the certificate only works with the key whose public half is inside the CSR. The CSR itself is not secret and can be discarded after issuance, but the private key must be kept secret and backed up.
Can I decode a CSR someone else generated?
Yes. Switch to the Decode tab and paste any PKCS#10 certificate signing request to see its subject fields, Subject Alternative Names, key algorithm and size or curve, and signature algorithm. It is the quickest way to check that a CSR built by OpenSSL, a load balancer, or a hosting control panel contains the host names you expect before you pay for a certificate. Decoding also happens entirely in your browser.
Is the private key encrypted with a passphrase?
No. The key is exported as an unencrypted PKCS#8 PEM file (-----BEGIN PRIVATE KEY-----), which is the format nginx, Apache, HAProxy, Caddy, and most load balancers expect. If you need a passphrase-protected key, run `openssl pkcs8 -topk8 -in private-key.pem -out encrypted-key.pem` locally after downloading. Treat the downloaded file as a secret in either case: anyone holding it can impersonate your site.