Generate Certificate Signing Requests with custom fields and SANs
CSR
Private Key
About CSR Generator
A CSR generator builds a Certificate Signing Request before a certificate is issued. Our free CSR Generator creates Certificate Signing Requests with custom fields and Subject Alternative Names (SANs). Generate RSA or ECDSA key pairs along with a properly formatted CSR that you can submit to any Certificate Authority. The tool also generates the matching private key, ready for server deployment.
How to Use
1Enter the Common Name (e.g., example.com) and optional organization details.
2Select key type (RSA or ECDSA) and key size.
3Add SANs as comma-separated domains (optional).
4Click "Generate CSR" and copy or download both the CSR and private key.
Use Cases
•Generate CSRs for SSL certificate orders from any CA
•Create multi-domain CSRs with SAN support
•Generate ECDSA CSRs for modern, faster TLS handshakes
•Prepare CSR for Let's Encrypt ACME certificate issuance
A Certificate Signing Request is a file you give to a certificate authority. It contains your public key and the names you want covered, plus a signature proving you hold the key. It never contains the private key itself, which is why it is safe to send and the key is not.
1Validate the names. Every hostname is checked before anything is generated, so a typo fails here rather than producing a CSR your CA rejects days later.
2Build the subject. The Common Name carries your primary domain. Organisation, organisational unit, country and state are appended only if you supply them — all four are optional and increasingly left out.
3Generate the private key in the algorithm you selected: RSA at the size you chose, or ECDSA on P-256, P-384 or P-521, or Ed25519.
4Attach the Subject Alternative Names as a critical SAN extension listing every hostname the certificate should cover.
5Sign the request with the freshly generated key and encode both as PEM — the CSR to send to the CA, the key to keep.
The private key is produced alongside the CSR and shown to you once. It is not stored, not emailed and cannot be retrieved later, so save it before you close the page.
Tips & Best Practices
•Use the same key type (RSA/ECDSA) as your target certificate
•Include all domain names in the SAN field, including the primary domain
•Keep your private key secure — never share it with anyone
Frequently Asked Questions
A Certificate Signing Request is a file you give to a certificate authority containing the public key you want certified, the names it should cover, and a signature proving you hold the matching private key. The private key itself is never in it, which is what makes a CSR safe to send. The authority checks that the proof is valid and then issues a certificate binding your public key to your names, and the certificate will only work on a server holding the private half.
It depends on the certificate type, and getting it wrong wastes a round trip. Organisation and extended validation certificates require them because the authority is making a statement about a legal entity. Domain validated certificates need only the names, because they assert nothing beyond control of the domain. Leaving them out for an OV or EV order produces a rejected request, and including them for a DV order adds noise the authority ignores, so it is worth knowing which kind you are buying before you generate.
No, and this catches people out regularly because the Subject Alternative Name list feels like something a certificate authority could fill in afterwards. The SANs are part of what your key signs in the request, so they are fixed at the moment the CSR is created. If a name is missing the answer is to generate a new CSR including every name you need and have the certificate reissued, which is also the reason to list the apex and the wildcard alongside the specific hosts rather than adding them one at a time as new services appear.
ECDSA is the sensible default today: keys are roughly a third the size of RSA and the handshake is faster, which matters most for mobile visitors. RSA 2048 remains universally supported, so choose it if any of your clients are old or managed. Ed25519 is excellent but needs a recent client stack. The one rule: whatever you pick must also be a key type your CA will sign, and the certificate must be usable by every system that will serve it.
Somewhere you control and nowhere it is served from. The key shown here appears exactly once and cannot be retrieved later, so copy it before leaving the page. Store it with the same care as any other secret: never in version control, never on a public web server, never in a shared document. If the key is lost you have to generate a new CSR and reissue, and if it leaks you have to revoke the certificate rather than hope nobody used it.
The Common Name is no longer authoritative. Every major browser has ignored it for hostname matching since 2017 and reads only the Subject Alternative Name extension, so a certificate with a CN and no SANs is treated as covering nothing at all. Your CA copies the SANs from the CSR into the certificate and often drops the CN entirely. This is why the SAN list matters more than the primary domain you typed first.
2048 bits is the current floor and is what almost every certificate authority still issues by default. 3072 is a reasonable choice if you want headroom for a long-lived certificate, at a modest cost in handshake size and generation time. Below 2048 is not worth the compatibility trouble: the security margin is thin and several browsers and certification programmes have started rejecting it outright. Check what your CA and your clients actually require before going higher.
The private key is created on this server for your request and returned to you in the response. It is not written to the certificate store, emailed, logged or attached to any account. Treat the page as sensitive anyway, because a key that ends up in a screenshot, a shared clipboard or a screen recording is compromised the same way as one pasted into chat. Generate it, save it to a file, and close the tab.
