CSR Generator

Create a private key and a certificate signing request (CSR) for a TLS certificate. The key is generated on this device and never leaves it, and this page shows no ads.

Runs in your browser. Your input is not sent anywhere.

Usually the main host name, such as www.example.com. Up to 64 characters.

Host names and IP addresses the certificate should cover, separated by commas, spaces or new lines; wildcards such as *.example.com work. A common name that is a host name or IP address is added here as well.

Organization details (optional)

The legal name, needed for OV and EV certificates. Up to 64 characters.

Public CAs no longer include it; leave it empty for them.

Written out, such as San Francisco.

Written out, not abbreviated, such as California.

Two-letter ISO 3166 code, such as US or DE.

Off by default. When on, the fields of this tool are kept in the local storage of this browser, unencrypted, until you turn it off.

No CSR yet

Enter at least a common name or one alternative name, then select “Generate CSR”. The key pair is created on this device.

Keyboard shortcuts

Ctrl + Enter, ⌘ + Enter
Run the tool with the current input
Alt + Shift + C
Copy the result
Alt + Shift + X
Clear all fields

Shortcuts work while the focus is inside the tool. Every action is also available as a button.

How to use it

  1. Enter the main host name as the common name, for example www.example.com.
  2. Add every other name the certificate must cover, such as example.com without www, under subject alternative names.
  3. Choose a key type. ECDSA P-256 is small and fast and works with every current browser; choose RSA 2048 if an old client or a device such as a load balancer needs RSA.
  4. Fill in the organization details only if you order an organization-validated (OV) or extended-validation (EV) certificate. Domain-validated certificates ignore them.
  5. Select “Generate CSR”. Send the CSR to your certificate authority (CA) and store the private key on the server where the certificate will be installed.

If you prefer to create the key on the server itself, which is the better practice for production, copy the OpenSSL command the tool shows. It produces an equivalent key and CSR with the same names.

Worked example

For www.example.com and example.com, with the organization Example Inc in the US and an ECDSA P-256 key, the tool shows this command:

Equivalent OpenSSL command
openssl req -new \
  -newkey ec -pkeyopt ec_paramgen_curve:P-256 \
  -nodes -keyout private-key.pem \
  -out request.csr \
  -sha256 \
  -subj '/C=US/O=Example Inc/CN=www.example.com' \
  -addext 'subjectAltName=DNS:www.example.com,DNS:example.com'

Decoded with openssl req -in request.csr -noout -text -verify, the CSR from the tool and the one from the command have the same fields; only the key and the signature differ, because each run creates a new key:

Decoded CSR (key and signature shortened)
Certificate request self-signature verify OK
Certificate Request:
    Data:
        Version: 1 (0x0)
        Subject: C=US, O=Example Inc, CN=www.example.com
        Subject Public Key Info:
            Public Key Algorithm: id-ecPublicKey
                Public-Key: (256 bit)
                ASN1 OID: prime256v1
                NIST CURVE: P-256
        Attributes:
            Requested Extensions:
                X509v3 Subject Alternative Name:
                    DNS:www.example.com, DNS:example.com
    Signature Algorithm: ecdsa-with-SHA256

The common name www.example.com also appears in the list of alternative names. The tool adds it there because CAs and browsers use only that list for host names.

What is inside a CSR

A CSR is a PKCS #10 certification request (RFC 2986): the subject name, the public key and a list of attributes, signed with the private key that belongs to the public key. The signature proves to the CA that whoever sent the request holds the key; the CA does not need the key itself.

Fields of the request
FieldWhat the tool writes
Version0, the only version PKCS #10 defines (printed as 1).
SubjectC, ST, L, O, OU and CN in this order, empty fields left out. The country is a PrintableString as RFC 5280 requires, the others UTF8String, as OpenSSL writes them.
Public keySubjectPublicKeyInfo exported by Web Crypto: an EC point on P-256 or P-384, or an RSA key with exponent 65537.
AttributesAn extensionRequest (PKCS #9) with the subject alternative names as DNS names and IP addresses. No key usage or validity: the CA decides those.
Signatureecdsa-with-SHA256 for P-256, ecdsa-with-SHA384 for P-384, sha256WithRSAEncryption for RSA. ECDSA signatures are converted from the raw form Web Crypto returns to the DER form X.509 expects.

The key pair comes from the Web Crypto interface of your browser and its cryptographically secure random generator. The private key is exported unencrypted in PKCS #8 form, the form openssl req writes as well, and exists only in this page until you copy or download it.

For publicly trusted TLS certificates the CA/Browser Forum Baseline Requirements allow RSA keys of at least 2048 bits and ECDSA keys on P-256, P-384 or P-521 (section 6.1.5). They forbid the organizational unit (OU) in subscriber certificates, and a domain-validated certificate may carry only the country and the common name in its subject (section 7.1.2.7). A CA may therefore drop fields you enter.

Common mistakes

  • Losing the private key. The CA never sees it and cannot restore it; without it the issued certificate is useless and you must start again with a new CSR.
  • Sending the private key to the CA or a reseller. Only the CSR goes to them. Anyone who asks for the key is not following the process.
  • Listing only www.example.com. The certificate then does not cover example.com, and visitors who type the short name see a warning.
  • Abbreviating the state (CA instead of California) or entering a country name instead of the two-letter code. OV and EV orders are checked against these fields.
  • Reusing an old CSR after the key was exposed. A new certificate for an exposed key is exposed as well; generate a new key.

Sources

Frequently asked questions

Is it safe to generate a private key on a website?
On this page the key is created by your browser’s Web Crypto interface and is not sent anywhere; this page loads no ads or other third-party scripts. Still, any web page is software you have to trust, and browser extensions can read pages. For production keys the safest place is the server itself: use the OpenSSL command the tool shows.
Which key type should I choose?
ECDSA P-256 for most sites: the Baseline Requirements allow it for every publicly trusted certificate, current browsers support it, and its keys and handshakes are smaller than RSA’s. Choose RSA 2048 or 3072 when a client or appliance supports only RSA. RSA 4096 is allowed but slower, with little practical gain for a certificate that lasts at most 200 days (Baseline Requirements section 6.3.2, for certificates issued since 2026-03-15).
How do I check a CSR before I submit it?
Paste it into the certificate decoder on this site, or run openssl req -in request.csr -noout -text -verify. Check that every host name is listed under the subject alternative names and that the signature verifies.
Why is there no Ed25519 option?
Publicly trusted TLS certificates may use only RSA and ECDSA on the NIST curves P-256, P-384 and P-521 under the CA/Browser Forum Baseline Requirements, so a CA would reject an Ed25519 request.
How do I match the issued certificate with my key?
Compare public key pins. The tool shows the pin of the new key; the certificate decoder shows it for the certificate you receive. Equal pins mean the certificate belongs to your key. Locally, openssl pkey -in private-key.pem -pubout -outform DER | openssl dgst -sha256 -binary | openssl base64 prints the same pin for the key.

Last updated: September 29, 2026