Back to Interactive Demo
CertificatesOpenSSL

Certificate Signing Request (CSR): Complete Guide

Learn how to create CSRs correctly. Understand every field, choose the right key algorithm, and avoid common mistakes that cause certificate rejections.

10 min readDecember 2025
CSR Builder Visualization
Try the Interactive CSR Builder

Quick Answer: What is a CSR?

A Certificate Signing Request (CSR) is a formal request you send to a Certificate Authority (CA) asking them to issue you a certificate. It contains your public key and identity information, signed with your private key to prove you own it.

Generate Key Pair
Create CSR(Public Key + Identity)
Send to CA
CA Returns Certificate

Key Point: Your private key NEVER leaves your server. The CSR only contains your public key, which the CA will embed in your certificate.

The CSR Lifecycle

CSR Lifecycle

Generate Key Pair
RSA or ECC private key
1
Create CSR
Public key + identity info
2
Submit to CA
Send CSR to Certificate Authority
3
CA Validates
Domain/organization verification
4
Receive Certificate
Signed by CA's private key
5
Install & Use
Configure on your server
6

Step 1: Generate Key Pair

Create a private and public key pair. The private key stays SECRET on your server forever.

# Generate RSA 2048-bit private key
openssl genrsa -out domain.key 2048

# Or generate ECDSA P-256 key (recommended)
openssl ecparam -genkey -name prime256v1 -out domain.key

Step 2: Create CSR

Generate a CSR using your private key. This extracts the public key and adds your identity.

# Create CSR (interactive - prompts for details)
openssl req -new -key domain.key -out domain.csr

# Create CSR (non-interactive with subject)
openssl req -new -key domain.key -out domain.csr \
  -subj "/CN=www.example.com/O=Example Corp/C=US"

Step 3: Submit to CA

Submit the CSR to your chosen Certificate Authority. They will verify your identity (domain ownership, organization details) and issue a certificate signed by their CA.

Step 4: Install Certificate

Once issued, install the certificate alongside your private key on your server.

Subject DN Fields Explained

Subject DN Fields

CN
Common NameRequired
www.example.com
O
Organization
Example Inc.
OU
Organizational Unit
IT Department
L
Locality (City)
San Francisco
ST
State/Province
California
C
Country
US
E
Email
admin@example.com

Tip: For modern certificates, use SAN extension instead of relying on CN for hostnames

The Subject Distinguished Name (DN) identifies who owns the certificate. Each field has specific requirements that CAs validate.

FieldCodeExampleNotes
Common NameCNwww.example.comPrimary domain (also add to SAN!)
OrganizationOExample CorpLegal company name (OV/EV only)
Org UnitOUIT DepartmentBeing deprecated - many CAs ignore
LocalityLSan FranciscoCity name
StateSTCaliforniaFull name, not abbreviation
CountryCUSISO 3166-1 alpha-2 code

Country Code Gotchas

  • US not "USA" or "United States"
  • GB not "UK" for United Kingdom
  • DE for Germany (Deutschland)
  • • Always use exactly 2 uppercase letters

Subject Alternative Names (SAN)

SANs are now the primary way browsers validate domain names. Modern browsers check SAN first, not the Common Name. Your certificate should list ALL domains in the SAN field.

Critical SAN Rules

  • Include the CN in SAN: Your primary domain (CN) must ALSO be in the SAN list
  • List all variations: example.com, www.example.com, api.example.com
  • Wildcards: *.example.com covers subdomains but NOT example.com itself

Creating a CSR with SANs

# Using -addext (OpenSSL 1.1.1+)
openssl req -new -key domain.key -out domain.csr \
  -subj "/CN=www.example.com/O=Example Corp/C=US" \
  -addext "subjectAltName=DNS:www.example.com,DNS:example.com,DNS:api.example.com"

# Using a config file (works with all OpenSSL versions)
cat > san.cnf << EOF
[req]
distinguished_name = req_dn
req_extensions = req_ext
prompt = no

[req_dn]
CN = www.example.com
O = Example Corp
C = US

[req_ext]
subjectAltName = @alt_names

[alt_names]
DNS.1 = www.example.com
DNS.2 = example.com
DNS.3 = api.example.com
DNS.4 = *.example.com
EOF

openssl req -new -key domain.key -out domain.csr -config san.cnf

Choosing Key Algorithms

Which Key Algorithm?

RSA (Traditional)

  • Universal compatibility
  • Well-understood security
  • Use 2048-bit minimum (4096 for high security)
  • Larger keys = slower handshakes

ECC (Modern)

  • Smaller keys, same security
  • Faster handshakes
  • Use P-256 or P-384 curves
  • Check legacy client support
Security equivalence:
RSA 2048ECC P-256
RSA 3072ECC P-384
AlgorithmKey SizeSecurityPerformanceRecommendation
RSA1024-bitBrokenFastNever use
RSA2048-bitMinimumOKAcceptable
RSA4096-bitStrongSlowerGood for high security
ECDSAP-256StrongVery FastRecommended
ECDSAP-384Very StrongFastBest for security
# ECDSA P-256 (recommended - same security as RSA 3072)
openssl ecparam -genkey -name prime256v1 -out domain.key
openssl req -new -key domain.key -out domain.csr

# ECDSA P-384 (stronger)
openssl ecparam -genkey -name secp384r1 -out domain.key

# RSA 2048 (widely compatible)
openssl genrsa -out domain.key 2048

# RSA 4096 (high security)
openssl genrsa -out domain.key 4096

OpenSSL CSR Commands

Generate Key + CSR in One Command

# RSA 2048 - Key and CSR together
openssl req -new -newkey rsa:2048 -nodes \
  -keyout example.com.key \
  -out example.com.csr \
  -subj "/CN=www.example.com/O=Example Corp/C=US" \
  -addext "subjectAltName=DNS:www.example.com,DNS:example.com"

# ECDSA P-256 - Key and CSR together
openssl req -new -newkey ec -pkeyopt ec_paramgen_curve:prime256v1 -nodes \
  -keyout example.com.key \
  -out example.com.csr \
  -subj "/CN=www.example.com/O=Example Corp/C=US"

View CSR Contents

# View CSR details
openssl req -in domain.csr -noout -text

# View just the subject
openssl req -in domain.csr -noout -subject

# Verify CSR signature is valid
openssl req -in domain.csr -noout -verify

Common Mistakes to Avoid

1. Missing SAN Entries

Problem: Certificate works for www.example.com but not example.com

Fix: Always list ALL domains in the SAN field, including the apex domain (example.com)

2. Wrong Key for CSR

Problem: CSR signed with different key than what you'll use with the certificate

Fix: Use the same private key file for CSR generation and certificate installation

3. Invalid Country Code

Problem: Using "USA", "UK", or "GER" instead of ISO codes

Fix: Always use ISO 3166-1 alpha-2 codes: US, GB, DE

4. Weak Key Size

Problem: Using RSA 1024-bit or other deprecated algorithms

Fix: Use RSA 2048-bit minimum, or ECDSA P-256/P-384 (recommended)

5. Organization Mismatch

Problem: O field doesn't match your legal business name exactly (for OV/EV)

Fix: Use the exact legal name as registered with your government

Related Resources

Frequently Asked Questions

Can I reuse a CSR?

Technically yes, but it's not recommended. Generate a fresh key pair and CSR for each new certificate. This limits exposure if an old key is ever compromised.

What's the difference between CN and SAN?

CN (Common Name) was traditionally THE domain field, but modern browsers now check SAN (Subject Alternative Name) first. You should put all your domains in SAN, and CN is mainly kept for compatibility with older systems.

Do I need different CSRs for DV, OV, and EV certificates?

The CSR format is the same. For DV certs, only CN and SAN matter. For OV/EV, you need accurate organization details that the CA will verify against public records.

What happens to my CSR after the certificate is issued?

You can delete the CSR file - it's not needed after the certificate is issued. Keep your private key safe! It's required to use the certificate.

My CA rejected my CSR. What should I check?

Common reasons: key size too small, invalid country code, organization name doesn't match records, or domain isn't listed in SAN. View your CSR withopenssl req -in domain.csr -noout -textto verify all fields.

Ready to Create Your CSR?

Use our interactive CSR builder to generate commands with the correct parameters.

Open CSR Builder Demo