CSR Generator
Generate a CSR and private key in your browser — the key never leaves it.
Runs 100% in your browser — nothing you paste or generate ever leaves your device.
Subject (Distinguished Name)
Subject alternative names (SAN)
Key & signature
Quick answer
CSR Generator creates a Certificate Signing Request and its matching private key in your browser, with the key never leaving your device. Choose RSA or ECDSA, enter your domains, submit the CSR to your CA, and keep the private key to install alongside the issued certificate.
CSR Generator creates a Certificate Signing Request and its matching private key directly in your browser. The private key is generated locally with the Web Crypto API and never leaves your machine, which is exactly how key generation should work. Server-side CSR generators create your private key on their server, meaning a copy of the secret that protects your site exists somewhere you do not control; that is a risk worth avoiding entirely. Here, you download the key, you keep it, and no one else ever sees it.
A CSR is the PKCS#10 request you hand to a Certificate Authority. It contains your public key plus the identity you want certified (domain names, organization, country) and is signed by the private key so the CA can confirm the two belong together. This tool lets you pick RSA (2048 or 4096) or ECDSA (P-256 or P-384), enter your domains and organization details, and produces both the CSR to submit and the private key to install alongside the issued certificate.
The private key never leaves your browser
Key generation runs client-side using the browser's built-in cryptography. The private key material is created in memory on your device, used to sign the CSR locally, and offered to you as a download; it is never transmitted. This is the whole point: a private key that a third party has seen can no longer be trusted to protect your traffic. Generators that produce the key on a remote server break that guarantee, however reputable they claim to be.
What to put in a CSR
Fill the Common Name with your primary domain and list every hostname you want covered as Subject Alternative Names, because clients validate against the SAN, not the Common Name. Organization, locality, and country matter for organization-validated (OV) and extended-validation (EV) certificates but are ignored for domain-validated (DV) ones. Choose RSA 2048 for maximum compatibility, or ECDSA P-256 for smaller, faster keys that every current client supports. Never include a password or email in the subject; keep it to identity fields.
RSA vs ECDSA
RSA 2048 is the safe default: universally supported and strong enough for years. RSA 4096 is stronger but slower and rarely necessary. ECDSA P-256 gives security comparable to RSA 3072 with a far smaller key, faster handshakes, and lower CPU cost, and it is supported by every modern browser and OS. Pick ECDSA for new, performance-sensitive deployments; keep RSA 2048 if you must support very old clients or middleboxes that predate elliptic-curve support.
After you generate
Submit the CSR text to your CA and store the private key securely; you cannot re-download it later and losing it means starting over. When the CA returns your certificate, install it together with this private key and the intermediate chain the CA provides. If you plan to load the certificate into Windows or IIS, you will later combine the certificate and this key into a PKCS#12 (PFX) file; the SSL Converter tool does that locally.
Frequently asked questions
- Where is my private key generated and stored?
- It is generated in your browser with the Web Crypto API and stays on your device. We never receive it. You download it and are responsible for storing it safely, because it cannot be regenerated to match the CSR later. This local-only model is the reason to avoid server-side CSR generators, which create your key on a machine you do not control.
- What key type and size should I choose?
- RSA 2048 is the best default for compatibility. ECDSA P-256 is the best choice for modern deployments: equivalent security to RSA 3072, smaller keys, and faster TLS handshakes, supported by all current clients. Use RSA 4096 only if a policy requires it, and ECDSA P-384 for extra margin. Very old systems may still need RSA.
- Do I list all my domains in one CSR?
- Yes. Put your primary name as the Common Name and add every hostname as a Subject Alternative Name. Modern clients validate only the SAN list, so any domain not listed there will be rejected. For a wildcard, use *.example.com as a SAN, remembering it covers one label only, so it matches www.example.com but not a.b.example.com.
- Can I reuse a CSR for renewal?
- You can, but generating a fresh CSR and key each time is better practice because it rotates the key and limits the impact of any past exposure. If you reuse a CSR you also reuse the same public key, which the certificate binds. Since generating a new one here takes seconds and never exposes the key, prefer a fresh pair on renewal.
- What is the difference between the Common Name and SAN in a CSR?
- The Common Name is a single legacy identity field. The Subject Alternative Names are the modern, authoritative list of hostnames the certificate will cover, and browsers validate strictly against them. Always include your Common Name value in the SAN list too, and add every other domain and subdomain you need on the same certificate.
- I lost the private key after generating the CSR, what now?
- A certificate is only usable with the exact private key that matches its CSR, so if the key is gone the certificate is useless. There is no recovery. Generate a new CSR and private key here, submit the new CSR to your CA for a reissue, and store the new key securely this time, ideally in a password manager or secrets vault.