SSOGEN / Free tools / Free CSR Generator: Create a CSR and Private Key in Your Browser
Free tool
Free CSR Generator: Create a CSR and Private Key in Your Browser
A CSR is the request you send a certificate authority. This free CSR generator makes the key pair and the request in your browser, checks its own signature and uploads nothing.
Generate a CSR and private key here
Enter a common name and every hostname the certificate must cover, choose a key type, and select Generate CSR and key. To see a complete example first, select Fill in an Acme example.
The main hostname. Browsers match the names below, not this one, but CAs still ask for it.
DNS names, wildcards such as *.apps.acme.example, and IP addresses. The common name is added for you if it is missing.
Private by design. The key pair is made in this page and never leaves it. The private key is a secret: copy or download it to the server that will use it, keep it out of email and chat, and clear this page when you are done. Where you can, generate keys on the server itself.
Free, in your browser. Your browser’s Web Crypto API generates the key pair, and the page builds and signs the request. Nothing is sent anywhere, which you can confirm in the Network tab.
The output is a CSR in PEM form and a private key in PKCS #8 PEM form, each with Copy and Download buttons. Before it shows the CSR, the tool parses it again and verifies its signature.
What a CSR is
A certificate signing request (CSR) is the file you send a certificate authority (CA) to request a certificate. It contains your public key, the names you want certified and a signature made with the matching private key.
This free CSR generator creates both parts in your browser: the CSR you send to the CA and the private key you keep. No sign-up is needed, and nothing is uploaded.
What to fill in
A request has a subject (who you are) and a list of names (what the certificate is valid for).
RFC 2986 (PKCS #10, read 2026-10-09) defines the request as the request information, a signature algorithm and a signature over that information.
It also says the CA may use the request’s attributes, and other information it knows, to build the certificate’s extensions. The certificate you receive can therefore differ from the CSR you sent.
Common name or SAN
Put every hostname in the subject alternative name (SAN) list, because clients match the SAN. RFC 9525 (section 2, read 2026-10-09) says the common name must not be used to identify a service.
The CA/Browser Forum Baseline Requirements (section 7.1.2.7.12 for the SAN, section 7.1.4.3 for the common name, read 2026-10-09) set two rules for a publicly trusted certificate:
- The SAN must contain at least one DNS name or IP address.
- A common name, if present, must hold a value derived from the SAN.
The tool adds the common name to the SAN list automatically, so a name entered only in the first box is still covered.
Wildcards and IP addresses
A wildcard is the whole left-most label and matches exactly one label (RFC 9525, section 6.3).
*.apps.acme.example covers finance.apps.acme.example, but not apps.acme.example or a.b.apps.acme.example. The tool accepts a single * at the start of a name and rejects any other wildcard form.
IP addresses are supported. RFC 5280 (section 4.2.1.6) encodes an IPv4 address in exactly four octets and an IPv6 address in exactly sixteen, and the tool handles that encoding.
Many public CAs do not issue certificates for private addresses, so confirm with your CA before you plan on one.
The organization fields
| Field | What CAs do with it | Mistake to avoid |
|---|---|---|
| Common name | Usually asked for, and the Baseline Requirements limit it to a name that is also in the SAN. | Putting a hostname here and nowhere else. |
| Names (SAN) | The names that are validated and certified. | Leaving out www or a second hostname, then needing a reissue. |
| Organization, city, state | Used only if the CA validates organizations. A domain-validated certificate is issued on proof of control of the names, so the CA may ignore them. | Spelling the legal name differently from your records, which stalls organization validation. |
| Department | Optional, often ignored. | Filling it with a product name that means nothing to the CA. |
| Country | Two letters, such as US. The tool rejects anything else. |
Typing the country name in full. |
Always compare the issued certificate with the request. The CSR decoder reads both.
Choose the key
The tool offers RSA 2048, 3072 and 4096, and ECDSA P-256 and P-384, signed with SHA-256 or SHA-384.
The Baseline Requirements (section 6.1.5, read 2026-10-08) require RSA keys of at least 2048 bits and name P-256, P-384 and P-521 as the permitted ECDSA curves.
A CA that follows them accepts every option here, and the tool offers nothing smaller.
- RSA 2048 is the safe default when you do not know how old the software on the other end is, or whether it supports elliptic curves.
- RSA 3072 and 4096 help only if your policy requires a larger key. Larger RSA keys take longer to generate, and the tool warns about this for 4096.
- ECDSA P-256 or P-384 gives shorter keys and requests. Use it when your servers and clients support it, and confirm that first.
We have not measured generation speed and quote no figures. Test on the machines that matter to you.
The private key: where it lives and how to protect it
The private key exists only in this page’s memory until you copy or download it. Closing or reloading the page discards it, so save it before you leave. Then:
- Move it to the server that will use the certificate and set file permissions so only that service account can read it. For example,
chmod 600 private-key.pem. - Do not email it, paste it into chat or attach it to a ticket. A CA never needs it; send the CSR only.
- If it leaks, treat the certificate as compromised: ask the CA to revoke it, generate a new key and request a new certificate.
Where possible, generate the key on the server that will use it. The key then never leaves that machine. This is standard OpenSSL usage and produces a request equivalent to the tool’s output:
openssl req -new -newkey rsa:2048 -nodes \ -keyout private-key.pem -out request.csr \ -subj "/C=US/ST=Texas/L=Dallas/O=Acme Corp/CN=gateway.acme.example" \ -addext "subjectAltName=DNS:gateway.acme.example,DNS:finance-app.acme.example"The -nodes option writes the key without a passphrase.
The Baseline Requirements (section 6.1.1.3, read 2026-10-08) say a CA must not generate the key pair for a certificate used for TLS servers. The private key always stays with the subscriber.
Check what you made
The tool verifies the request before displaying it, using the same parser as the CSR decoder. Paste the CSR there to review the subject, key, names and signature, or run the same check on your own machine:
openssl req -in request.csr -noout -verify -textWe checked the tool’s output this way for RSA 2048 and ECDSA P-256:
- Signature.
openssl req -verifyreported the signature OK. - Names. The subject and subject alternative names were correct.
- Key match. The private key matched the public key in the CSR.
The key match compares the two public keys:
openssl req -in request.csr -noout -pubkey | openssl sha256openssl pkey -in private-key.pem -pubout | openssl sha256Identical hashes mean the key belongs to the request.
What happens next
- Send only the CSR to the CA, through its order form or API.
- The CA validates what it needs: usually control of each name, and the organization for some certificate types.
- You receive the certificate and usually one or more intermediate certificates.
- Install the server certificate first, then each issuer after it, together with your private key. A missing intermediate causes “incomplete chain” errors in stricter clients, and the decoder shows the gap in a pasted chain.
- Keep the private key where it is. It also stays with you when you plan renewals.
Use the key with the SSOGEN Gateway
The App Proxy of the SSOGEN Gateway serves a TLS certificate for each hostname it publishes. The App Proxy guide lists what the console accepts:
- The certificate chain in PEM, with the server certificate first and then each issuer up to a CA certificate.
- The private key in PKCS#8 PEM format (the first line is
BEGIN PRIVATE KEY) without a passphrase.
The key must be RSA of 2048 bits or more, or ECDSA P-256 or P-384. This generator’s key is already in that format, so it goes straight into the Private key (PKCS#8 PEM) box.
SSOGEN also checks that the certificate is a server certificate, not a CA, and that it does not expire within 24 hours.
For a company CA that signs directory certificates, see LDAPS certificate: trust your internal CA. For SAML signing certificates, the SAML metadata checker reads the certificates in a metadata file.
What is a CSR generator?
How do I generate a CSR?
openssl req -new -newkey rsa:2048 -nodes with the options shown earlier.Is it safe to generate a CSR online?
Do I send the private key to the CA?
Why does my certificate not include the name I typed in the common name?
Where to go next
- Decode. Decode the request or the certificate you get back with the CSR decoder.
- More tools. Browse the other free tools.
- Publish an app. Follow the App Proxy guide to publish an internal app.
- A test certificate. For a test certificate that needs no authority, use the self-signed certificate generator.
Sources, all read 2026-10-09: RFC 2986, RFC 9525, CA/Browser Forum Baseline Requirements.