What Is a CSR File? (Certificate Signing Request Explained)

What Is a CSR File? (Certificate Signing Request Explained)

Before you can buy an SSL certificate from a certificate authority, you have to generate a CSR. Your hosting provider asks for one. The CA's web form asks for one. You paste a block of Base64 gibberish and a certificate comes back. But what actually lives inside that file, and why does the CA need it?

A CSR (Certificate Signing Request) is the bridge between your private key and a signed certificate. Understanding what's inside it — and how to verify those contents — prevents the kind of mistakes that waste days of deployment time.

What CSR Stands For

CSR stands for Certificate Signing Request. It's a PKCS#10-formatted message (RFC 2986) that you send to a certificate authority to request a signed SSL/TLS certificate. The CSR contains:

1. Your public key (extracted from the key pair you generated)
2. Identifying information about the entity the certificate will cover (domain, organization, location)
3. A signature over all of the above, created with your private key

The CA takes your CSR, validates the identifying information through their validation process (DV, OV, or EV), then issues a certificate that binds your public key to the validated identity.

Crucially, a CSR never contains your private key. The private key stays on the server that generated the request. That's the whole point of public-key cryptography — you can hand the public key to anyone, and only the holder of the private key can prove ownership.

What's Inside a CSR File

A CSR file is typically a PEM-encoded (Base64 with header/footer) ASN.1 structure. Open one in a text editor and you'll see something like:

-----BEGIN CERTIFICATE REQUEST-----
MIICvDCCAaQCAQAwdzELMAkGA1UEBhMCVVMxDTALBgNVBAgMBFV0YWgxDzANBgNV
BAcMBkxpbmRvbjEWMBQGA1UECgwNRGlnaUNlcnQgSW5jLjERMA8GA1UECwwIRGln
...
-----END CERTIFICATE REQUEST-----

The -----BEGIN CERTIFICATE REQUEST----- / END markers tell you it's a CSR (not a certificate, not a key). File extensions vary — .csr, .pem, .req, or .p10 are all common — but the content is what matters.

Decode that Base64 and you get a structured ASN.1 object with three main parts:

Paste a CSR into the CSR Decoder to see every field without running OpenSSL commands.

The Subject: Who the Certificate Is For

The Subject is a Distinguished Name (DN) — a structured identifier composed of several fields:

• CN (Common Name) — the primary domain, e.g., www.example.com
• O (Organization) — the legal name of your company
• OU (Organizational Unit) — department or team (often omitted)
• L (Locality) — city
• ST (State) — state or province
• C (Country) — two-letter country code (e.g., US, GB)
• emailAddress — optional contact email

For a Domain Validated (DV) certificate (the kind Let's Encrypt issues), only the CN matters — everything else is ignored or stripped. For Organization Validated (OV) or Extended Validation (EV) certificates, the CA will verify every field against official records.

Subject Alternative Names (SANs)

Modern browsers no longer accept the Common Name for domain matching — they require a Subject Alternative Name extension. A CSR for a multi-domain certificate embeds SANs as an attribute:

X509v3 Subject Alternative Name:
    DNS:example.com, DNS:www.example.com, DNS:api.example.com

If your CSR doesn't include SANs, modern CAs will either reject it or add them automatically based on validation. Always include the exact domains you want covered.

How a CSR Is Generated

A CSR is created from an existing private key (or a new key pair generated in the same command). The canonical OpenSSL incantation:

# Generate a 2048-bit RSA key and a CSR in one step
openssl req -new -newkey rsa:2048 -nodes \
    -keyout example.com.key \
    -out example.com.csr \
    -subj "/C=US/ST=California/L=San Francisco/O=Example Inc/CN=www.example.com"

Breaking that down:

• req -new — create a new CSR
• -newkey rsa:2048 — also generate a new 2048-bit RSA private key
• -nodes — "no DES," meaning don't encrypt the private key with a passphrase
• -keyout / -out — output file paths
• -subj — the Distinguished Name, supplied inline

For ECC keys (recommended for performance):

openssl ecparam -genkey -name prime256v1 -noout -out example.com.key
openssl req -new -key example.com.key -out example.com.csr \
    -subj "/CN=www.example.com"

If you don't want to touch the command line, the CSR Generator runs the same logic in your browser — no keys leave your machine.

How to Verify a CSR Before Submitting It

Always decode your CSR before sending it to a CA. A typo in the CN means a reissued certificate later (and often a fee). Quick verification:

openssl req -in example.com.csr -noout -text -verify

The -verify flag also confirms the signature is mathematically valid — proof that whoever generated the CSR possessed the matching private key.

Things to check:

• CN matches the intended domain exactly (trailing slashes, www vs. apex)
• SANs include all domains you expect the certificate to cover
• Key size is ≥ 2048 bits for RSA or ≥ 256 bits for ECC
• Signature algorithm is SHA-256 or better — SHA-1 CSRs are rejected by all modern CAs
• Organization details match official records (for OV/EV)

The CSR Decoder displays all of these in a single view, and also shows the public key fingerprint — which you can cross-reference against your private key using the Certificate Key Matcher to confirm they're a matched pair.

CSR vs Certificate: The Difference

People often confuse CSRs with certificates because they look almost identical — both are Base64 blocks wrapped in PEM headers. The distinction:

A CSR is a request; a certificate is the granted response. Once the CA issues the certificate, you no longer need the CSR — you only need the private key (which you never sent) and the certificate (which they returned).

Common CSR Mistakes and How to Fix Them

Mistake 1: Wrong Common Name. Generating a CSR for example.com when you meant www.example.com (or vice versa). Browsers treat these as different hostnames. Fix: always include both as SANs.

Mistake 2: Encrypted private key in production. If you didn't use -nodes, your key is passphrase-protected — which means your web server will prompt for the passphrase on every restart. Fix: strip the passphrase with openssl rsa -in encrypted.key -out plain.key before deploying.

Mistake 3: Reusing a CSR across renewals. Each renewal should use a fresh CSR and, ideally, a fresh key pair. Reusing the same key year after year reduces your ability to rotate cryptographic material if it's ever compromised.

Mistake 4: Submitting a CSR whose private key you lost. If you lose the key, the resulting certificate is useless — you cannot prove ownership. Always back up the private key to an encrypted, access-controlled location before submitting the CSR.

When You Don't Need a CSR

Some modern certificate workflows skip the manual CSR step entirely:

• Let's Encrypt via ACME (Certbot, acme.sh) — the client generates the CSR automatically behind the scenes
• AWS ACM / Cloudflare / GCP managed certificates — the cloud provider handles key generation, CSR creation, and issuance
• Self-signed certificates — no CA involved, so no CSR needed (though you still create one internally)

You still benefit from understanding CSRs, though — because when something goes wrong at renewal time, you'll need to read what the automation produced.

Quick Reference

• A CSR is a Certificate Signing Request — a file you send to a CA to request a certificate.
• It contains your public key and subject details, signed by your private key.
• The private key never leaves your server.
• File extension varies (.csr, .pem, .req) — content is what matters.
• Always decode and verify a CSR before submitting it. Use the CSR Decoder to inspect any CSR in seconds.
• After the CA issues your certificate, the CSR can be discarded.