What does a CSR generator do?
A CSR generator creates two things at once: a key pair, and a PKCS#10 certificate signing request built around the public half of it. You describe the name you want — a common name, an organisation, a country and the host names the certificate should cover — choose the key type, and the tool generates the key, assembles the request, signs it with the private key, and hands you both files to download. Every step happens in the page.
Generating the key in the browser rather than on a server is the point of the tool. A key made on somebody else's machine has been seen by that machine, and a service that generates one and emails it to you is asking you to trust that nothing was retained. The cryptography here is the browser's own Web Crypto API, the key is created in memory in your tab, and the only way out is the download button. Nothing is transmitted, which is verifiable by watching the network tab stay empty.
The request follows the standard exactly: a version, your subject name, the public key, and an extensionRequest attribute carrying the subjectAltName extension with the host names you typed. It is signed with SHA-256 — with RSA, or with ECDSA on the curve you pick — and encoded as DER then wrapped in the usual PEM armour. That is the same structure openssl req produces, so an authority expects nothing unusual from it.
How to generate a certificate signing request
- Fill in the common name — usually the host name — and as many of the organisation fields as your authority expects.
- List every host name the certificate must be valid for in the subject alternative names box, one per line; these are what a browser will match against.
- Choose the key: elliptic curve P-256 unless something you talk to needs RSA, in which case 2048 or 3072 bits.
- Press Generate the request; a new key pair is created in the tab and the request is signed with it.
- Download the private key and store it where only the server can read it — there is no recovery if it is lost.
- Download the request and send it to your certificate authority, then delete the request file if you wish; the key is the part that must be kept.
CSR Generator limits and rules
| Item | Limit |
|---|---|
| Key types | RSA at 2048, 3072 or 4096 bits, and ECDSA on P-256 or P-384 |
| Signature | SHA-256 with RSA, or ECDSA with SHA-256 — accepted by every public authority |
| Outputs | The request as PKCS#10 PEM, and the private key as unencrypted PKCS#8 PEM |
| Names | Subject alternative names as DNS entries; an address with @ is written as an email name, and an http URL as a URI name |
| Subject fields | Country, state, locality, organisation, unit and common name, in the conventional order |
| Generation | RSA keys take longer with size; 4096 bits can pause visibly in a browser |
| Not covered | Encrypting the key with a passphrase, self-signing a certificate, and any proof of domain control |
When to use it
- Getting a request ready for a certificate authority without a terminal to hand.
- Producing a matching key and request on a machine where installing OpenSSL is not an option.
- Generating an elliptic-curve request when the usual instructions assume RSA.
- Making a request on a temporary machine where nothing should be left behind afterwards.
- Creating a request for an internal authority that takes PKCS#10 requests by upload.
Is it private?
The key pair is generated by the browser in this page and is never transmitted, stored or logged — you can confirm that by watching the network tab while generating. Closing or reloading the tab discards both the key and the request, so download the key before navigating away.
Frequently asked questions
It is safer than generating one on a server you do not control, which is the alternative most online generators offer. The browser's Web Crypto API uses the operating system's cryptographic random source, and the key is created in memory inside this tab. The risk that remains is local: a compromised browser extension, or a machine that is not yours. For a production key, generating on the server that will hold it is still the strongest option — this is the honest middle ground.
Elliptic curve, unless something specific requires RSA. An ECDSA P-256 key gives roughly the strength of a 3072-bit RSA key at a fraction of the size and generates almost instantly, and every modern server and authority supports it. RSA remains necessary where an old client or appliance cannot do elliptic curve, and where an authority insists on it. RAM and handshake cost both favour the smaller key, which is why it has become the default at most organisations.
For a domain-validated certificate, the alternative names are the only strict requirement, and the organisation fields may be left blank — some authorities will refuse a request that claims an organisation without proving it. For an organisation-validated or extended-validation certificate, the legal name, country and often a locality and registration number are required and will be checked against records. Fill in what your authority asks for and leave the rest empty rather than guessing.
It is a human-readable label, not a binding. Until 2017 it was what clients matched a host name against; since then they read only the subject alternative names, and public authorities stopped issuing on the common name alone. Conventionally you still set it to one of the host names so the certificate is recognisable in a list, but the names in the box below are what actually make the certificate valid for a host.
No. A key pair is generated once from random data and cannot be recreated from the request, from a name, or from anything else — the private key is the only copy of its secret half. That is why the download button for the key matters more than the one for the request, and why keeping the key somewhere backed up and restricted is the step that is worth getting right. The request can always be regenerated from a key; the key cannot be regenerated at all.
It is a trade-off, and worth understanding. An unencrypted key can be loaded by a server without prompting, which is convenient, and it is the form most servers want for unattended start-up — at the cost of being readable by anyone who obtains the file. An encrypted key is protected at rest but needs a passphrase at start-up. The usual practice is an unencrypted key on a server whose file permissions restrict it to the service account, often inside a directory nothing else can read. Encrypt the key with openssl if your policy requires it.
Related tools
Written and maintained by Md. Nur Hossain Repon.