toolfree

CSR generator

Generate a private key and a certificate signing request with WebCrypto, in this tab. Nothing is uploaded, because there is no server on this page to upload it to.

Runs in your browser

The domain the certificate is for, e.g. example.com or *.example.com

Two letters, e.g. GB, TW, HK, CN

One per line, or comma separated. Domains, wildcards, IP addresses and email addresses. The common name is added automatically — browsers ignore the common name and match on this list, so a certificate without it does not work for its own name.

The key pair is generated by your browser and never leaves this tab. There is no server involved in this page at all.

The one thing that matters about an online CSR generator

A certificate signing request is a public document. You email it to a certificate authority, and it contains nothing secret — the names you are asking to certify, and a public key.

The private key generated alongside it is the entire security of the certificate. Anyone holding it can impersonate the site the certificate is issued to, for as long as the certificate is valid.

So the question to ask any online CSR generator is where the key pair was made. If the answer is “on our server”, that server had your private key before you did, and you have no way to know what it did with it. Some are honest about this. Most say nothing.

This page generates the key in your browser, using the WebCrypto API that is part of the browser itself. The key is exported once, shown to you, and then dropped. It is not stored, not logged and never transmitted — this site has no endpoint to transmit it to, and you can confirm that in the network tab: generating a key makes no requests at all.

It also means the key cannot be recovered. Reload the page and it is gone. Save it before you navigate away.

Filling in the form

Common name (CN) is the domain, and the only required field: example.com, or *.example.com for a wildcard. Not a URL — no https://, no trailing slash, no port.

Other names (SAN) is the field that actually decides what the certificate works for. Since 2017 every mainstream browser has ignored the common name entirely when matching a hostname and looked only at the subject alternative name extension. A certificate with a CN and no SAN is rejected as invalid for its own domain. This page copies the CN into the SAN list automatically so that cannot happen, and you add the rest: www.example.com, other hostnames, IP addresses.

Country (C) is a two-letter ISO 3166-1 code, and CAs validate it. GB, not UK — UK is not an ISO country code. TW, HK, CN, US, SG, JP.

Organisation (O) and the rest are optional and, for the certificates most people buy, ignored. A domain-validated certificate certifies the domain and nothing else, and a CA will strip organisation fields it has not verified. Fill them in only for an OV or EV certificate, where they have to match your registration documents exactly.

Which key

RSA 2048 is the safe default. Every CA issues it, and everything that has ever spoken TLS accepts it.

ECDSA P-256 is smaller and faster, with a much shorter handshake, and support is now effectively universal on anything that is not a decade-old embedded device. Prefer it if you know what is connecting.

RSA 4096 is the one to skip. It slows every handshake for security nobody needs — 2048-bit RSA has no known practical attack, and if that changes, 4096 buys you very little more time. Choose ECDSA instead if 2048 makes you uneasy.

P-384 exists for compliance regimes that ask for it by name.

The signature hash is SHA-256 throughout, and SHA-384 for P-384. SHA-1 has not been accepted by any public CA since 2016 and is not offered.

What to do with the two files

  1. Save the private key as example.com.key, somewhere backed up and readable only by you. chmod 600.
  2. Send the CSR — the CERTIFICATE REQUEST block — to your CA. It is not secret; email is fine.
  3. The CA returns a certificate. Your server needs it and the private key from step 1. The certificate is worthless without the key.
  4. Delete nothing until the certificate is installed and the site loads.

Check what you are about to submit before you submit it:

openssl req -in request.csr -noout -text -verify

That prints the subject and the SAN list, and verify confirms the signature was made by the key belonging to the public key inside it — which is the check that catches a CSR assembled wrongly.

What a CSR does not decide

The certificate’s validity period, its issuer, whether it can sign other certificates, and which extended key usages it carries are all the CA’s decisions, not yours. A CSR requests names and presents a public key; a CA is free to ignore everything else in it, and generally does.

This is also why a CSR does not expire. It is a request, not a credential — you can send the same one again as long as you still hold its key.

Free certificates first

If you are buying a domain-validated certificate to put on a public web server, check whether you need to. Let’s Encrypt and ZeroSSL issue DV certificates free, and their ACME clients — certbot, acme.sh, Caddy, or whatever your host has built in — generate the key and the CSR for you and renew automatically. A manual CSR is the right tool for a paid OV/EV certificate, a client certificate, a private CA, an appliance whose web UI demands one, or a code-signing request.

What is my IP and the WebSocket tester for the other half of getting TLS working, and UUID generator for identifiers that also come from the browser’s own crypto.