CSR Generator
Generate a valid certificate signing request (PKCS#10) and its matching private key right here. Fill in the subject — CN, O, OU, L, ST, C and email — add your SANs, pick an RSA or ECDSA key, and get a CSR to hand to your Certificate Authority. The keypair is created in your browser and the private key is never uploaded.
Default · broadest compatibility
The keypair and CSR are generated entirely in your browser with the Web's cryptographic RNG — the private key never leaves this page and is not transmitted to PlayCISO or anyone else.
What this tool is
- A free, in-browser CSR generator: it creates a valid PKCS#10 certificate signing request and the matching private key entirely on your device.
- Fill in the subject — Common Name (CN), Organization (O), Organizational Unit (OU), Locality (L), State (ST), Country (C) and email — and add Subject Alternative Names (DNS, IP, email or URI), which are auto-detected from a comma list.
- Choose your key: RSA 2048, 3072 or 4096, or ECDSA P-256 / P-384. The CSR is signed with SHA-256 (SHA-384 for P-384).
- Every CSR is re-verified against its own signature before it is shown — if the check fails, no CSR is emitted, so you never copy out an invalid request.
- The private key is generated in your browser and never sent anywhere. Copy or download the CSR for your Certificate Authority and store the private key securely — it is yours alone.
What is a CSR?
A CSR (Certificate Signing Request) is the standardised blob — a PKCS#10 CertificationRequest — that you send to a Certificate Authority to request an SSL/TLS certificate. It bundles three things: the subject you want on the certificate (your domain and optional organization details), the public key the certificate will certify, and a signature made with your private key that proves you actually hold the matching key. The CA checks that you control the domain, then issues a certificate built around the public key and names in your CSR. The private key stays with you — it is never part of the CSR and is never sent to the CA.
The subject fields
- CN — Common Name. The primary hostname, e.g.
example.com. Modern browsers validate against the SANs, not the CN, but CAs still record it. - O / OU — Organization & Unit. The legal company name and a department (e.g.
IT). Verified for OV/EV certificates. - L / ST / C — Locality, State, Country. City, region, and the two-letter ISO country code (
US,GB,DE).
Subject Alternative Names
The SANs are the names your certificate is actually valid for — and browsers trust a certificate only for the hostnames in this list. Enter them as a comma-separated list and the tool auto-detects each type: a bare hostname becomes a DNS name (wildcards like *.example.com are fine), a dotted or colon address becomes an IP, an @ makes an email, and a :// makes a URI. By default your CN is copied into the SAN list, because public CAs require the primary name to appear there.
Key types
RSA 2048 is the compatible default; RSA 3072 / 4096 add margin at the cost of speed. ECDSA P-256 / P-384 use elliptic-curve keys that are far smaller and faster for the same strength — P-256 is roughly RSA 3072 — and are the modern choice when you control the clients. The request is signed with SHA-256 (SHA-384 for P-384).
Keep the private key private
A certificate is only as trustworthy as the secrecy of its private key. This tool generates the key in your browser and never transmits it, but once you have it, it is your responsibility: store it in a secrets manager or your server's key store, never email it or paste it into a chat, and never commit it to a repository. Give your CA the CSR — never the key. If a private key is ever exposed, treat the certificate as compromised: revoke it and generate a fresh key and CSR.
Correctness note: every CSR this tool produces is re-verified against its own signature before it is shown to you. If that check does not pass, the tool refuses to emit a CSR rather than hand you a request a CA would reject. Already have a CSR or certificate and want to read it back? Use the SSL / CSR decoder.
Frequently asked questions
What is a CSR (certificate signing request)?
A CSR is a block of PEM-encoded data you send to a Certificate Authority (CA) to ask it to issue an SSL/TLS certificate. Formally it is a PKCS#10 CertificationRequest: it contains the subject you want on the certificate (your domain in the Common Name, plus optional organization details), the Subject Alternative Names the certificate should cover, and your public key — all signed by the corresponding private key to prove you hold it. The CA validates your control of the domain, then issues a certificate built around the public key and subject in the CSR. You keep the private key; it is never part of the CSR and is never sent to the CA.
Is it safe to generate a CSR and private key in a web tool?
It is safe when the generation is genuinely client-side, which this tool is. The keypair and CSR are produced in your browser using the browser cryptographic APIs that jsrsasign builds on; nothing is transmitted to PlayCISO or any server, and you can confirm this in your browser dev-tools network tab (you will see no upload on Generate). That said, the strongest practice for high-value certificates is still to generate the key on the exact machine or HSM that will use it (for example with openssl on your server), so the private key never exists anywhere else. Use this tool for convenience and for test, lab and internal certificates; for a production key you want to keep provably on one host, generate it there.
What are the subject fields — CN, O, OU, L, ST, C?
They are the parts of the X.500 Distinguished Name that identify the certificate holder. CN (Common Name) is the primary hostname, e.g. example.com. O (Organization) is the legal company name; OU (Organizational Unit) is a department such as IT. L (Locality) is the city, ST (State or Province) is the region, and C (Country) is the two-letter ISO country code such as US, GB or DE. For modern public certificates the CN matters less than it used to — browsers validate against the Subject Alternative Names — but the CA still records these fields, and OV/EV certificates verify O, L, ST and C against official records. Leave fields blank if your CA does not require them.
What are Subject Alternative Names (SANs) and why do I need them?
SANs are the list of names a certificate is actually valid for. Every modern browser ignores the Common Name and trusts a certificate only for the hostnames in its SAN list, so a certificate that covers example.com and www.example.com must list both as SANs. SANs can be DNS names (including wildcards like *.example.com), IP addresses, email addresses or URIs; this tool auto-detects the type from each comma-separated entry and, by default, copies your Common Name into the SAN list because public CAs require the primary name to appear there. Always include every hostname you want the certificate to serve.
RSA or ECDSA — which key type should I choose?
RSA 2048 is the safe default: it is accepted everywhere, including older clients and middleboxes, and is still considered secure. RSA 3072 and 4096 give a larger security margin at the cost of slower handshakes and slower generation. ECDSA (P-256 or P-384) uses elliptic-curve keys that are much smaller and faster than RSA for the same security level — P-256 is roughly comparable to RSA 3072 — and is the modern choice for new deployments where you control the clients. If you are unsure, or need maximum compatibility, use RSA 2048. If you want performance and your CA and clients support it, use ECDSA P-256.