Generate CSR with OpenSSL Command

To generate a Certificate Signing Request (CSR) with OpenSSL, use the openssl req command with the -new and -key flags. You provide your private key (or let OpenSSL create one) and answer a series of prompts about your organization; the command outputs a CSR file that you submit to a Certificate Authority (CA) to obtain an SSL/TLS certificate.

What a CSR Contains and Why It Matters

A CSR is a block of encoded text that contains your public key and identifying information about your domain and organization. When a CA issues a certificate, it signs this information with its own private key, creating a digital document that proves your server’s identity to browsers. The CSR itself is not secret—anyone can read it—but the private key used to generate it must remain confidential. If your private key is compromised, the certificate becomes worthless, so protecting it is a core part of the process.

Step-by-Step: Generating a CSR with OpenSSL

OpenSSL is a command-line tool available on Linux, macOS, and Windows (via WSL or a precompiled binary). The most common workflow involves two steps: creating a private key and generating the CSR. You can do both in a single command:

openssl req -new -newkey rsa:2048 -nodes -keyout yourdomain.key -out yourdomain.csr

Here’s what each flag does:

• -new tells OpenSSL to generate a new CSR.
• -newkey rsa:2048 creates a new RSA private key with 2048-bit strength (the current recommended minimum).
• -nodes (“no DES”) leaves the private key unencrypted, so your server can read it without a passphrase. If you omit this, OpenSSL will prompt for a passphrase each time the key is used.
• -keyout specifies the filename for the private key.
• -keyout specifies the filename for the CSR.

If you already have a private key, use openssl req -new -key yourdomain.key -out yourdomain.csr. After running the command, OpenSSL asks for the following details:

1. Country Name (2-letter code, e.g., US)
2. State or Province Name (full name)
3. Locality Name (city)
4. Organization Name (legal entity)
5. Organizational Unit (department, often left blank)
6. Common Name (the fully qualified domain name, e.g., www.example.com)
7. Email Address (optional; many CAs ignore this)
8. A challenge password (optional; leave blank unless your CA requires it)

You can also supply all details non-interactively using the -subj flag:

openssl req -new -newkey rsa:2048 -nodes -keyout example.key -out example.csr -subj "/C=US/ST=California/L=San Francisco/O=Example Corp/CN=www.example.com"

This is useful for automation and scripting.

Choosing the Right Key Type and Size

RSA is the most widely supported algorithm, but ECDSA (Elliptic Curve Digital Signature Algorithm) is becoming popular because it offers equivalent security with smaller keys and faster performance. To generate an ECDSA key and CSR, use:

openssl req -new -newkey ec -pkeyopt ec_paramgen_curve:prime256v1 -keyout example.key -out example.csr

For RSA, 2048 bits is the minimum for new certificates; 4096 bits provides more margin but increases handshake time and CPU usage. Most CAs accept 2048-bit keys, and browsers handle them fine. ECDSA with the prime256v1 curve is equivalent to a 3072-bit RSA key in strength.

Common Mistakes and How to Avoid Them

Several pitfalls trip up even experienced administrators:

• Mismatched Common Name: The CN must exactly match the domain you intend to secure, including subdomains. For a wildcard certificate, use *.example.com.
• Using a passphrase on the key: If you set a passphrase, your web server will prompt for it on every restart, which breaks automatic reboots. Use -nodes to avoid this.
• Losing the private key: Once you submit the CSR to a CA, you cannot retrieve the private key. Back it up securely before proceeding.
• Including extra attributes: Some CAs reject CSRs that contain an email address or challenge password. If your CA complains, regenerate the CSR without those fields.
• Using the wrong key type: If you mix up RSA and ECDSA, the CSR will be invalid. Always verify with openssl req -text -noout -in yourdomain.csr.

Verifying Your CSR

Before submitting, inspect the CSR to ensure all details are correct. Run:

openssl req -text -noout -in yourdomain.csr

This prints the CSR contents, including the public key modulus and the subject fields. You can also verify that the private key matches the CSR with:

openssl rsa -noout -modulus -in yourdomain.key | openssl md5
openssl req -noout -modulus -in yourdomain.csr | openssl md5

If the two hashes match, the key and CSR are paired correctly.

What to Do After Generating the CSR

Once you have the CSR file, copy its contents (including the -----BEGIN CERTIFICATE REQUEST----- and -----END CERTIFICATE REQUEST----- lines) and paste it into your CA’s enrollment form. After the CA validates your domain ownership and issues the certificate, you’ll receive a certificate file (usually a .crt or .pem) and possibly an intermediate bundle. Install these on your server along with the private key. Remember: the private key stays on your server; never share it with the CA.

Frequently Asked Questions

Can I reuse a CSR?

Yes, a CSR can be used multiple times as long as the private key remains the same. However, CAs typically require a fresh CSR for each certificate order, and reusing an old CSR may cause confusion if your domain or organization details have changed.

What is the difference between a CSR and a certificate?

A CSR is a request for a certificate—it contains your public key and identity information but is not signed by a CA. A certificate is the signed result, which browsers trust. You generate the CSR, the CA signs it, and the signed file becomes your certificate.

Why does OpenSSL ask for a challenge password?

The challenge password is an optional field that some CAs use for revocation. In practice, most modern CAs ignore it, and leaving it blank is recommended to avoid compatibility issues.

How do I generate a CSR for a wildcard certificate?

Use the same command but set the Common Name to *.example.com (replace example.com with your domain). The CSR will be valid for the wildcard domain and all its subdomains.

What if I lose my private key?

You cannot recover a lost private key. You must generate a new key pair and a new CSR, then reissue the certificate through your CA. This is why backing up the key is essential.

Is it safe to use -nodes?

Yes, -nodes simply means the private key is not encrypted with a passphrase. This is standard practice for web servers because it allows the server to start automatically. The security of the key then depends on file permissions—ensure the key file is readable only by root or the web server user.

Related

• Can a Numbered Game Be a Standalone Story?
• Devices That Need Regular Firmware Updates
• Modular Mouse: Why It’s the Future of Input