CSR Generator (OpenSSL Command)

What the CSR Generator (OpenSSL Command) does

A Certificate Signing Request (CSR) is what you send to a certificate authority (CA) to get an SSL/TLS certificate. It contains your public key, the subject details and the Subject Alternative Names the certificate should cover, all signed with the matching private key. The CA validates the request and returns a certificate; the private key stays with you.

This generator builds the OpenSSL command that creates the private key and the CSR in one step, with the subject fields and SANs you enter. The default key is ECDSA on the P-256 curve; RSA 2048, 3072 and 4096 are available for systems that need RSA. You also get a second command to inspect the CSR before you submit it. We never create or see your key: you run the command on your own server, so the private key never leaves it.

Why it matters

Generating the key where it will be used is the safe way to do it. A website that creates the key and CSR for you has, at least for a moment, a copy of the key that protects your traffic. A command you can read before you run it has no such step.

The details also trip people up. Browsers match the host name only against the SANs and ignore the common name, so every host, including both example.com and www.example.com, must be listed as a SAN. A wildcard such as *.example.com covers exactly one label: it matches www.example.com, but neither example.com itself nor a.b.example.com. Since 2022 publicly trusted CAs no longer include the Organizational Unit (OU) field, so the generator leaves it out. See our TLS certificate guide.

How to fix common problems

Run the command on the server that will use the certificate, or on a trusted admin machine, with OpenSSL 1.1.1 or newer (needed for the -addext option that adds the SANs). It writes two files: the .key file, which you protect with strict file permissions and never send anywhere, and the .csr file, which you paste into your CA’s order form. Run the inspect command first to confirm that the subject and SANs are what you expect.

If you use Let’s Encrypt or another ACME CA, you usually do not need this tool: clients such as Certbot, acme.sh or Caddy create the key and CSR themselves and renew automatically. A hand-made CSR is mainly for paid CAs, OV and EV certificates, and devices that cannot run an ACME client. Choose ECDSA P-256 unless part of your stack only supports RSA; its keys are smaller and its handshakes faster than RSA at a comparable strength.

When the certificate arrives, check its names, dates and chain with the SSL Certificate Decoder, install it together with its intermediates, and run the SSL Checker against the live site. The full PerfoMetrix audit then reports on the certificate alongside 170+ other checks.

Questions

ECDSA or RSA: which key should I choose?

ECDSA P-256 is the default: smaller keys and faster handshakes at a security level comparable to RSA 3072. Choose RSA 2048 or larger only if a client, load balancer or appliance you must support cannot use ECDSA.

Do I need to fill in the common name?

Browsers ignore it for name matching, but many CAs still expect one. Set it to the main host name and make sure that name is also in the SAN list.

Can I reuse my old private key for a renewal?

Technically yes, but a new key for each certificate is better practice and limits the damage if an old key ever leaked.

Why is there no Organizational Unit field?

Publicly trusted CAs stopped including the OU field in certificates in 2022 under CA/Browser Forum rules, so there is no reason to put it in the CSR.