CSR (Certificate Signing Request) Generator
Generate an RSA private key (PEM) and a signed PKCS#10 Certificate Signing Request (CSR) to submit to a Certificate Authority. Set the subject (CN, O, OU, L, ST, C, email) and Subject Alternative Names (DNS/IP/email/URI); choose RSA 2048/3072/4096 and a SHA-2 signature hash. Generated entirely in your browser — the private key never leaves the page.
Input
Subject Information
The fully-qualified domain name (or server/host name) this certificate will secure.
Two-letter ISO 3166-1 country code (e.g. US, GB, DE).
One per line (or comma-separated). DNS names, IPv4/IPv6 addresses, URIs, and emails are auto-detected.
Key Configuration
Generated entirely in your browser — the private key is never uploaded or transmitted anywhere. This creates a NEW key pair for a NEW certificate request; it does not reuse or import an existing private key.
Output
Keep this secret. Never share, upload, or commit this file — it is the key to your certificate.
Submit this CSR to your Certificate Authority (CA).
Guides
A Certificate Signing Request (CSR) is the PKCS#10 document you hand to a Certificate Authority (CA) — Let's Encrypt, DigiCert, your internal PKI — when you want an SSL/TLS certificate issued. It bundles your public key with the identity you're requesting a certificate for (domain name, organization, location) and is signed with the matching private key to prove you control that key.
This tool generates a real RSA private key and a matching, signed CSR right in your browser: fill in the subject fields, pick a key size, and click Generate CSR.
How to use it
- Fill in the subject fields. Only Common Name (CN) is required — it's the domain or host name the certificate will cover (e.g.
example.comor*.example.comfor a wildcard). Organization, Organizational Unit, City, State, Country, and Email are optional metadata most public CAs no longer require but some internal/enterprise CAs still expect. - Add Subject Alternative Names (SANs) if the certificate needs to cover more than one name — extra domains, subdomains, IP addresses, or email/URI identities. Enter one per line (or comma-separated); DNS names, IPv4/IPv6 addresses, emails, and URIs are detected automatically. Modern browsers require the CN to also appear as a SAN for domain validation, so most CAs will add it for you if you omit it — but it's safest to include it explicitly.
- Choose a key size and signature hash, then click Generate CSR.
- Copy or download the CSR (PEM) and submit it to your CA. Copy or download the Private Key (PEM) and store it securely — you'll need it to install the certificate the CA eventually issues.
What key size should I choose?
2048-bit RSA is the current industry baseline and is accepted everywhere — it's the recommended default. 3072-bit and 4096-bit offer a larger security margin at the cost of slower key generation and slightly larger handshakes; 4096-bit is a reasonable choice for a long-lived internal CA root or a certificate you don't want to re-issue for years. Nothing below 2048 bits is offered, since RSA keys smaller than that are considered insecure by every modern CA and browser.
Does my private key ever leave my browser?
No. The key pair and the CSR are generated and signed entirely client-side — nothing is uploaded or transmitted to any server. That said, treat the downloaded private key like a password: never paste it into an untrusted service, send it over email, or commit it to source control. Keep in mind this tool always creates a brand-new key pair for a new certificate request — it can't be used to reuse or recover a private key you already have.
Why do I need both a private key and a CSR?
The CSR only contains your public key and identity information — it's what you send to the CA. The private key stays with you and is what your server uses (alongside the certificate the CA later issues) to actually terminate TLS connections. Losing the private key means the certificate the CA issues is useless to you; losing the CSR is harmless, since you can always generate a new one.
What if my CA asks for a specific signature hash?
SHA-256 is accepted by every CA today and is the recommended default. SHA-384 and SHA-512 are offered for CAs or compliance policies that specifically require a stronger digest; SHA-1 is not offered at all, since it's been deprecated for certificate signing for years.