Certificate Signing Requests (CSR): The Complete Technical Guide

A Certificate Signing Request (CSR) is the formal application you submit to a Certificate Authority (CA) when requesting a digital certificate. Defined by the PKCS#10 specification (RFC 2986) (2000), a CSR is a structured block of data that contains your public key, your identity information (domain name, organization, country), and a cryptographic signature proving you possess the corresponding private key. The CA validates your identity, signs your public key, and returns a certificate that browsers and operating systems trust.

Despite being one of the oldest standards in PKI, CSR generation remains a pain point. Misconfigured fields trigger ERR_CERT_COMMON_NAME_INVALID errors, missing SAN extensions cause browsers to reject certificates, and lost private keys force the entire process to start over. This guide explains the full technical pipeline — from ASN.1 structure to ACME automation — so you can generate, inspect, and troubleshoot CSRs with confidence.

Want to generate or inspect a CSR right now? Try the CSR Generator tool — it supports RSA 2048/3072/4096 and ECDSA P-256/P-384, SAN configuration, and CSR inspection, all in your browser.

What a CSR Contains

A CSR is not just a text file — it’s a structured binary object encoded in Baseetized. Understanding its internal anatomy helps you debug problems when CAs reject your requests.

PKCS#10 ASN.1 Structure

At the binary level, a CSR follows the PKCS#10 structure defined in ASN.1 (Abstract Syntax Notation One):

CertificationRequest ::= SEQUENCE {
    certificationRequestInfo  CertificationRequestInfo,
    signatureAlgorithm        AlgorithmIdentifier,
    signature                 BIT STRING
}

CertificationRequestInfo ::= SEQUENCE {
    version       INTEGER (0),
    subject       Name,
    subjectPKInfo SubjectPublicKeyInfo,
    attributes    [0] IMPLICIT SET OF Attribute
}

In plain English:

1. CertificationRequestInfo — The “form data”: your identity (subject), your public key, and optional extensions (like SANs)
2. signatureAlgorithm — Which algorithm was used to sign the request (e.g., sha256WithRSAEncryption)
3. signature — The cryptographic proof that you hold the private key

Subject Distinguished Name (DN)

The subject field is a sequence of Attribute Type-Value pairs:

Attribute	OID	Example	Required?
Common Name (CN)	2.5.4.3	www.example.com	Yes — the primary domain
Organization (O)	2.5.4.10	Example Corp	For OV/EV certificates
Organizational Unit (OU)	2.5.4.11	Platform Team	Deprecated by most CAs
Locality (L)	2.5.4.7	San Francisco	For OV/EV certificates
State/Province (ST)	2.5.4.8	California	For OV/EV certificates
Country (C)	2.5.4.6	US	Two-letter ISO 3166-1 code
Email Address	1.2.840.113549.1.9.1	[email protected]	Optional, rarely used

Critical note about CN: Since Chrome 58 (2017), browsers ignore the CN field for identity matching and require the domain to appear in the Subject Alternative Name (SAN) extension instead. A CSR without SANs will produce a certificate that triggers security warnings in every modern browser.

Subject Alternative Names (SANs)

SANs are carried as a CSR attribute (extension request) and encoded in ASN.1 as:

SubjectAltName ::= GeneralNames
GeneralNames ::= SEQUENCE OF GeneralName
GeneralName ::= CHOICE {
    dNSName       IA5String,    -- www.example.com
    iPAddress     OCTET STRING  -- 192.168.1.1
}

A single certificate can carry dozens of SANs, protecting multiple domains and subdomains:

DNS: www.example.com
DNS: example.com
DNS: api.example.com
DNS: shop.example.com
IP:  192.168.1.100

Our CSR Generator lets you add multiple SAN entries — just enter one domain or IP per line.

RSA vs ECDSA: Choosing Your Key Algorithm

The key algorithm you choose for your CSR affects certificate size, performance, compatibility, and security margin. Here’s the full comparison:

Property	RSA 2048	RSA 3072	RSA 4096	ECDSA P-256	ECDSA P-384
Security level	112-bit	128-bit	140-bit	128-bit	192-bit
Public key size	256 bytes	384 bytes	512 bytes	65 bytes	97 bytes
CSR signature size	256 bytes	384 bytes	512 bytes	64 bytes	96 bytes
Key generation speed	Slow	Very slow	Extremely slow	Fast	Moderate
Signing speed	Slow	Very slow	Extremely slow	Fast	Moderate
Verification speed	Fast	Fast	Moderate	Moderate	Moderate
Browser compatibility	Universal	Universal	Universal	Modern (all since ~2014)	Modern
CA acceptance	Yes	Yes	Yes	Yes	Yes
Quantum resistance	None	None	None	None	None

Recommendations:

• Default choice: RSA 2048 — universally compatible, meets all current CA/Browser Forum requirements
• Best performance: ECDSA P-256 — 128-bit security with dramatically smaller keys and faster signing; supported by all modern browsers and CAs
• Government/high-security: ECDSA P-384 — 192-bit security, required for NSA Suite B / CNSA 2.0
• Avoid: RSA 1024 — deprecated, rejected by all reputable CAs since 2013
• Overkill for web: RSA 4096 — minimal security gain over RSA 3072, significant performance cost

Our CSR Generator supports all five options: RSA 2048/3072/4096 and ECDSA P-256/P-384. You can also use our RSA Key Generator or ECC Key Generator to create standalone key pairs, then import the private key into the CSR tool.

PEM vs DER: CSR File Formats

CSRs can be encoded in two formats. Understanding the difference prevents submission errors:

Format	Encoding	Headers	Use case
PEM	Base64 text	-----BEGIN CERTIFICATE REQUEST----- / -----END CERTIFICATE REQUEST-----	Most CAs, email, web forms
DER	Raw binary	None	Java keytool, some enterprise CAs

PEM is by far the most common format. It’s human-readable (you can open it in a text editor and see the Base64 content), easy to copy-paste, and universally accepted.

DER is a binary format used primarily in Java ecosystems. The keytool command generates DER-encoded CSRs by default.

Converting between formats:

# PEM → DER
openssl req -in server.csr -outform DER -out server.der

# DER → PEM
openssl req -in server.der -inform DER -outform PEM -out server.pem

Our PEM Format Converter handles CSR format conversions in the browser.

How to Generate a CSR

Method 1: OpenSSL (Command Line)

OpenSSL is the most widely used tool for CSR generation. It’s pre-installed on macOS and most Linux distributions.

One-liner (generate key + CSR):

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

Two-step process (separate key generation):

# Step 1: Generate private key
openssl genrsa -out server.key 2048

# Step 2: Create CSR from existing key
openssl req -new -key server.key -out server.csr \
  -subj "/CN=www.example.com/O=Example Corp/C=US" \
  -addext "subjectAltName=DNS:www.example.com,DNS:example.com"

ECDSA variant:

# Generate ECDSA P-256 key
openssl ecparam -genkey -name prime256v1 -out server.key

# Create CSR
openssl req -new -key server.key -out server.csr \
  -subj "/CN=www.example.com/O=Example Corp/C=US" \
  -addext "subjectAltName=DNS:www.example.com,DNS:example.com"

Verify the CSR before submission:

openssl req -in server.csr -noout -text -verify

This outputs the subject, public key details, SANs, and signature algorithm — everything you need to confirm the CSR is correct.

Method 2: Using an OpenSSL Config File

For complex SAN configurations, a config file is cleaner than command-line flags:

# openssl.cnf
[req]
default_bits       = 2048
prompt             = no
distinguished_name = dn
req_extensions     = v3_req

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

[v3_req]
subjectAltName = DNS:www.example.com,DNS:example.com,DNS:api.example.com

openssl req -new -newkey rsa:2048 -nodes \
  -keyout server.key -out server.csr \
  -config openssl.cnf

Method 3: Browser (Web Crypto API)

Modern browsers can generate CSRs entirely client-side using the Web Crypto API. Our CSR Generator does exactly this — no data leaves your device. The process:

1. Generate a key pair using crypto.subtle.generateKey()
2. Encode the subject DN as ASN.1
3. Add SAN extension as a CSR attribute
4. Sign the CertificationRequestInfo with the private key
5. Output PEM-encoded CSR + private key

This is the same cryptographic operation that OpenSSL performs, but running in your browser with no server round-trip.

Method 4: Java keytool

For Java-based servers (Tomcat, Jetty, WebLogic):

# Generate keystore + key pair
keytool -genkeypair -alias server -keyalg RSA -keysize 2048 \
  -keystore keystore.jks \
  -dname "CN=www.example.com, O=Example Corp, C=US"

# Generate CSR from keystore
keytool -certreq -alias server -keystore keystore.jks -file server.csr \
  -ext "san=dns:www.example.com,dns:example.com"

Note: keytool outputs the CSR in DER format by default. Add -rfc to get PEM output.

Certificate Validation Levels and CSR Requirements

Not all certificates require the same information in the CSR. The validation level determines what the CA checks:

Level	Abbreviation	CSR fields required	CA checks	Typical use
Domain Validation	DV	CN + SANs	Domain ownership only	Blogs, small sites
Organization Validation	OV	CN + O + L + ST + C + SANs	Domain + legal entity existence	Business websites
Extended Validation	EV	CN + O + L + ST + C + businessCategory + serialNumber + SANs	Domain + legal entity + operational existence + physical address	Banks, e-commerce

Key differences:

• DV certificates can be issued in minutes via automated domain control validation (DCV). The CSR only needs the domain name.
• OV certificates require the CA to verify the organization’s legal existence (business registry lookup). The CSR must include the full legal name and location.
• EV certificates require the most rigorous validation, including verification of operational existence and physical address. The CSR must include additional fields like businessCategory and serialNumber.

Since 2020, the CA/Browser Forum has been phasing out the visual distinction between OV and EV (the “green bar” was removed from browser UIs), but the validation rigor remains different.

CA/Browser Forum Baseline Requirements

The CA/Browser Forum defines the baseline requirements that all publicly trusted CAs must follow. Key CSR-related requirements:

Requirement	Details
Minimum RSA key size	2048 bits (RSA 1024 rejected since 2013)
Minimum ECDSA curve	P-256 or stronger
SAN required	Certificates must include SAN extension; CN-only certs are non-compliant
Signature algorithm	SHA-256 or stronger for the CSR signature
Key usage	CSR should request digitalSignature and keyEncipherment (RSA) or digitalSignature (ECDSA)
Validity period	Maximum 398 days (since September 2020)
Wildcard restrictions	*.example.com allowed for DV; OV/EV wildcards require additional validation

These requirements are enforced through the Baseline Requirements (BR) and audited by WebTrust or ETSI audits.

The CSR Lifecycle

Here’s the complete journey of a CSR from generation to certificate installation:

1. Generate private key (on your server)
   ↓
2. Create CSR containing public key + subject + SANs
   ↓
3. Sign CSR with private key (proves key possession)
   ↓
4. Submit CSR to Certificate Authority
   ↓
5. CA validates identity (DV/OV/EV)
   ↓
6. CA verifies domain control (DCV)
   ↓
7. CA signs your public key → issues certificate
   ↓
8. Install certificate + private key on server
   ↓
9. Serve certificate to clients via TLS handshake

Critical: The private key (step 1) never leaves your server. Only the public key and metadata travel to the CA. If anyone asks for your private key, it’s a scam.

ACME and Automated Certificate Issuance

The ACME protocol (RFC 8555) (2019) automates the entire CSR-to-certificate pipeline. Instead of manually generating CSRs and pasting them into web forms, ACME clients handle everything programmatically:

1. ACME client generates key pair + CSR
   ↓
2. Client submits CSR to ACME server (e.g., Let's Encrypt)
   ↓
3. ACME server issues domain validation challenge
   ↓
4. Client proves domain control (HTTP-01 or DNS-01)
   ↓
5. ACME server signs CSR → returns certificate
   ↓
6. Client installs certificate automatically
   ↓
7. Client renews before expiry (typically 60-90 days)

Popular ACME clients:

• Certbot (EFF) — The reference implementation, supports Apache/Nginx
• Caddy — Web server with built-in ACME
• Traefik — Reverse proxy with automatic HTTPS
• acme.sh — Pure shell script, zero dependencies

Let’s Encrypt, Buypass, Google Trust Services, and ZeroSSL all offer free DV certificates via ACME. For OV/EV certificates, you still need to generate CSRs manually and submit them through the CA’s portal.

Common CSR Errors and Troubleshooting

Error	Cause	Fix
ERR_CERT_COMMON_NAME_INVALID	Domain not in SAN extension	Regenerate CSR with SANs; CN alone is ignored by browsers
CSR rejected by CA	Key size too small (RSA < 2048)	Use RSA 2048+ or ECDSA P-256+
Signature verification failed	CSR not properly signed	Regenerate CSR; ensure private key matches
“Private key does not match”	Key was regenerated after CSR	Use the exact private key generated with the original CSR
Empty SAN list	Config file missing [v3_req] section	Add subjectAltName to OpenSSL config or -addext flag
CSR contains wrong organization	Copied from old CSR	Regenerate with correct subject fields
“Invalid encoding”	Submitted DER as PEM (or vice versa)	Convert format: openssl req -in file -outform PEM

Pro tip: Always verify your CSR before submission using our CSR Generator Inspect mode, or via OpenSSL:

openssl req -in server.csr -noout -text -verify

Security Best Practices

1. Generate the private key on the server where the certificate will be installed. Never transmit the private key over the network.

2. Use strong key sizes. RSA 2048-bit minimum; RSA 3072 or ECDSA P-256 recommended for new deployments.

3. Always include SANs. Browsers ignore CN for identity matching. A certificate without SANs will trigger warnings.

4. Verify before submitting. Decode the CSR and check every field — typos in the subject or SANs can’t be fixed after issuance without starting over.

5. Back up the private key immediately. If you lose it, the issued certificate is useless and you must generate a new key pair + CSR.

6. Never share the private key. The CA doesn’t need it. Support teams don’t need it. Anyone asking for it is a security risk.

7. Use unique keys per certificate. Don’t reuse a private key across multiple CSRs or certificates.

8. Rotate keys periodically. Generate a new key pair and CSR before certificate renewal, not just a new CSR with the old key.

9. Consider ECDSA for performance. ECDSA P-256 provides 128-bit security with smaller keys and faster operations than RSA 2048.

10. Automate with ACME where possible. Manual CSR workflows are error-prone and don’t scale. Let’s Encrypt + Certbot eliminates most human error.

Frequently Asked Questions

Can I reuse a CSR for multiple certificates?

Technically yes — a CSR is just a signed request containing your public key and identity. However, most CAs bind the CSR to a specific certificate order, and reusing one can cause confusion. Best practice: generate a new CSR (and ideally a new key pair) for each certificate.

What’s the difference between a CSR and a self-signed certificate?

A CSR is a request for a CA to sign your public key. A self-signed certificate is one you sign yourself — it provides encryption but no third-party trust. Browsers will show a security warning for self-signed certificates because no trusted CA vouches for the identity.

Why do browsers ignore the Common Name (CN)?

Since Chrome 58 (released 2017), browsers follow the CA/Browser Forum Baseline Requirements which mandate that identity matching uses only the Subject Alternative Name (SAN) extension. The CN field is deprecated for domain validation. Always include your domains as SANs in the CSR.

Can I use an ECDSA key for my CSR?

Yes. ECDSA P-256 and P-384 are supported by all major CAs and modern browsers. ECDSA offers equivalent security to RSA with much smaller keys (P-256 ≈ RSA 3072 in security, but with 65-byte keys vs 384-byte keys).

How long is a CSR valid?

A CSR itself doesn’t expire — it’s just a signed request. However, CAs typically require a fresh CSR for each certificate order. If your certificate is expiring and you’re renewing, generate a new CSR (and ideally a new key pair) rather than reusing an old one.

What happens if I lose my private key after submitting a CSR?

The issued certificate becomes unusable. You cannot recover the private key from the CSR or the certificate. You must generate a new key pair, create a new CSR, and request a reissue from your CA (most offer free reissues within the original certificate’s validity period).

Can I edit a CSR after generating it?

No. A CSR is cryptographically signed — any modification to the subject, SANs, or public key invalidates the signature. If you need to change anything, regenerate the CSR from scratch.

Should I use RSA or ECDSA for my CSR?

For new deployments in 2026, ECDSA P-256 is the recommended choice: smaller keys, faster operations, equivalent security to RSA 3072, and universal browser support. Use RSA 2048 only when you need compatibility with legacy systems that don’t support ECDSA.

Further Reading

• RFC 2986 — PKCS #10: Certification Request Syntax — The foundational specification for CSR format
• RFC 8555 — Automatic Certificate Management Environment (ACME) — Protocol for automated certificate issuance
• CA/Browser Forum Baseline Requirements — Mandatory requirements for publicly trusted certificates
• RFC 5280 — X.509 PKI Certificate and CRL Profile — The specification for X.509 certificate structure
• Let’s Encrypt Documentation — Free ACME-based certificate authority
• OpenSSL req Command Reference — Complete CSR generation and management commands
• NIST SP 800-57 Part 1 Rev. 5 — Key management recommendations including minimum key sizes
• NIST SP 800-52 Rev. 2 — TLS implementation guidelines including curve and algorithm requirements

Related Articles

• RSA-2048 Encryption: The Complete Guide — Understanding the RSA key pairs that underpin most CSRs
• Elliptic Curve Cryptography (ECC): The Complete Guide — ECDSA keys as a modern alternative to RSA in CSRs