📜 CSR Generator
Build a PKCS#10 Certificate Signing Request and its matching private key for RSA or ECDSA — entirely inside your browser. The key pair is generated, the request is assembled and signed, and nothing is ever sent to a server.
What a CSR Actually Is, and Why This Generator Runs Entirely in Your Browser
A Certificate Signing Request (CSR) is a small, standardized document — formally PKCS#10, defined in RFC 2986 — that you hand to a Certificate Authority (CA) when you want an SSL/TLS certificate issued. It bundles your identifying details (domain name, organization, location) together with a public key, and is signed with the matching private key to prove you actually control that key pair. The CA never sees your private key at all; it only ever receives the CSR. Generating both locally, in the browser's own JavaScript engine via the Web Crypto API, means the private key is created and used for signing without ever crossing a network boundary — the same guarantee you'd get running openssl req on your own machine, just without needing OpenSSL installed.
How the Generator Builds a Standards-Compliant Request
The tool generates an RSA or ECDSA key pair with crypto.subtle.generateKey(), exports the public key in SubjectPublicKeyInfo format, and assembles a CertificationRequestInfo structure — version, subject distinguished name, public key info, and (if you set any SAN entries) a requested-extensions attribute — using a minimal ASN.1 DER encoder written specifically for this page. That structure is signed with crypto.subtle.sign() using the private key, and the signed CSR plus the exported private key are both Base64-encoded into standard PEM blocks. The output is byte-for-byte a normal PKCS#10 request: it verifies cleanly with openssl req -in file.csr -noout -verify and decodes with openssl req -text exactly like one produced by OpenSSL, a CA's own portal, or your hosting control panel.
RSA vs ECDSA for a New Key Pair
| Key Type | Handshake Cost | Compatibility | Best For |
|---|---|---|---|
| RSA 2048 | Higher | Universal — every CA, every client back to very old browsers | Default choice, public sites needing maximum reach |
| RSA 4096 | Highest | Universal, same as 2048 | Long-lived internal CAs, specific compliance requirements |
| ECDSA P-256 | Lowest | All current browsers and modern CAs (Let's Encrypt, DigiCert, etc.) | Public web servers wanting faster TLS handshakes at equivalent security |
| ECDSA P-384 | Low | Same as P-256, slightly less universal on older embedded clients | Higher assurance ECC deployments |
RSA 2048-bit and ECDSA P-256 are both considered secure for the foreseeable future by every major CA and browser vendor; the choice mostly comes down to compatibility with whatever is on the other end of the connection. If you don't have a specific reason to pick otherwise, RSA 2048 remains the conservative default this generator preselects.
What Each Subject Field Is Actually Used For
Why the SAN Field Is the One That Actually Matters
Since 2020, the CA/Browser Forum's baseline requirements mean publicly trusted certificates are only checked against the Subject Alternative Name extension — the Common Name field is retained for backward compatibility but no longer trusted for hostname matching on its own. This is why the generator automatically folds your Common Name into the SAN list if you don't add it explicitly: a certificate whose only name lives in CN and not SAN will show a "not secure" / name-mismatch warning in every current browser, even though the CN is technically correct. If you need a certificate to cover both the bare domain and a www subdomain, both need their own SAN entry — they aren't inferred from each other.
When You'll Actually Need to Generate a CSR
Most people who land on this page are in one of a few specific situations. A solo developer renewing a certificate through a CA that doesn't auto-generate keys on their behalf — some paid CAs and enterprise portals still expect you to submit your own CSR rather than handling key generation server-side. A sysadmin setting up mutual TLS (mTLS) between an internal API and its clients, where each service needs its own certificate signed by a private internal CA rather than a public one. Someone requesting an Extended Validation (EV) or Organization Validation (OV) certificate, which almost always requires manually submitting a CSR as part of the vetting workflow rather than using ACME automation. And occasionally, someone migrating a certificate to a new server who needs a fresh key pair because the original private key isn't portable or wasn't backed up — in that case a new CSR against a new key is the only way forward, since a certificate can't be re-keyed after issuance.
What to Do With the CSR and Key After Generating Them
Download both files immediately using the buttons above. Submit the CSR's contents — the full PEM block, including the BEGIN/END lines — into your CA's request form or ACME client configuration; it's a plain-text document meant to be pasted or uploaded as-is. Keep the private key file somewhere access-controlled: on the server that will actually terminate TLS, with restrictive file permissions, or in a secrets manager if your deployment uses one. When the CA finishes validation, they'll send back a signed certificate; that certificate is only usable paired with this exact private key, so the two need to end up on the same server together. Once you have it, the Certificate Decoder confirms exactly what the CA issued — its validity dates, actual SAN list, and extensions — before you deploy it anywhere.
Why the Private Key Never Leaves Your Browser
Web Crypto API key generation happens inside the browser's own cryptographic implementation — the same subsystem used to negotiate the HTTPS connection to this very page — and the DER encoding, signing, and PEM formatting in this tool are plain JavaScript with no network calls anywhere in the code path. There's no form submission, no background request, and no server-side component that ever sees the key material. This is a meaningful difference from copy-pasting your details into a web form that generates a key pair server-side and mails or displays it back to you; here, the private key simply never exists outside your own device's memory until you choose to download it.
If Your CA Rejects the CSR
Related Reading
For a broader look at what SSL/TLS certificates are and how the chain of trust works, see What Is SSL and Certificate Security & Trust Verification. For the difference between DV, OV, and EV validation levels referenced above, read SSL Validation Levels: EV, OV, DV. For the underlying protocol and cipher choices a certificate gets used with once issued, see TLS/SSL Protocol & Certificate Types and the companion guides on disabling legacy TLS versions. If a certificate on your domain has already expired, Fix an Expired SSL Certificate covers the reissuance path this CSR generator feeds into.