Certificate Signing Requests (CSRs)

A Certificate Signing Request is a cryptographic proof with an elegant property: it proves you possess a secret without revealing the secret.

Here's the problem CSRs solve. You want a Certificate Authority to issue a certificate binding your identity to a public key. But how does the CA know you actually possess the corresponding private key? You can't just send them the private key—that would defeat the entire purpose of keeping it secret.

The solution: you sign the request with your private key. The CA verifies the signature using the public key you've included. If the signature checks out, they know you possess the private key without ever seeing it.

If you use Let's Encrypt or any ACME-based certificate system, you've probably never seen a CSR. The automation handles everything—key generation, CSR creation, submission, validation—invisibly. But understanding what happens beneath that automation matters when things break, when you need manual control, or when you're debugging why a certificate isn't working.

What's Inside a CSR

A CSR contains the information that will appear in your certificate, plus a cryptographic signature proving you control the private key:

Public Key: The key that will be bound to your domain. Generated alongside your private key before creating the CSR.

Common Name (CN): Historically the primary domain name. Modern certificates use Subject Alternative Names instead, but CN persists for compatibility.

Organization Information: For OV and EV certificates—legal name, department, city, state, country. DV certificates typically leave these empty or use placeholders.

Subject Alternative Names (SAN): The actual list of domains the certificate covers. This is what browsers check.

Signature: Created with your private key. This is the proof of possession.

The CSR never contains your private key. The private key stays with you, always.

Generating a CSR

OpenSSL is the standard tool. This command generates a private key and CSR together:

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

You'll be prompted for information:

Country Name (2 letter code): US
State or Province Name: California
Locality Name (city): San Francisco
Organization Name: Example Corporation
Organizational Unit Name: IT Department
Common Name: www.example.com

The -nodes flag means the private key won't be encrypted with a passphrase—typical for web servers that need to start automatically.

You can also generate the key first, then create the CSR:

openssl genrsa -out private.key 2048
openssl req -new -key private.key -out request.csr

The Format

CSRs use PEM format—Base64-encoded text with header and footer markers:

-----BEGIN CERTIFICATE REQUEST-----
MIICvDCCAaQCAQAwdzELMAkGA1UEBhMCVVMxEzARBgNVBAgMCkNhbGlmb3JuaWEx
[many lines of Base64-encoded data]
-----END CERTIFICATE REQUEST-----

This encoding makes CSRs safe to paste into web forms or email. The actual data is ASN.1 DER-encoded binary underneath.

To view what's in a CSR:

openssl req -in request.csr -noout -text

This decodes everything into human-readable form—useful for verifying you got the details right before submitting.

Including Multiple Domains

Modern certificates need Subject Alternative Names to cover multiple domains. Including SANs in a CSR requires a configuration file:

[req]
req_extensions = v3_req

[v3_req]
subjectAltName = @alt_names

[alt_names]
DNS.1 = example.com
DNS.2 = www.example.com
DNS.3 = mail.example.com

Then reference it:

openssl req -new -key private.key -out request.csr -config openssl.cnf

Many commercial CAs let you specify SANs through their web interface after submitting the CSR, which is simpler.

What the CA Does With Your CSR

When the CA receives your CSR, they verify several things:

Signature Check: Using the public key in the CSR, they verify your signature. This proves you possess the private key.

Domain Validation: Through DNS records, HTTP challenges, or email verification, they confirm you control the domain.

Organization Validation (for OV/EV): They verify your organization exists and matches what you've claimed, checking business databases and requesting documentation.

If everything checks out, they issue a certificate containing your public key and the validated information. That certificate is cryptographically bound to your specific private key—no other key will work with it.

The Private Key Is Everything

The private key generated alongside your CSR is the secret that makes the whole system work. Lose it, and your certificate becomes useless. Expose it, and your security is compromised.

Never send your private key to the CA. They don't need it. If anyone asks for it, something is wrong.

Protect it: Restrictive file permissions (600 or 400 on Unix). Secure backups. No unauthorized access.

Track it: Always know which private key corresponds to which certificate. Mixing them up causes TLS handshake failures that can be maddening to debug.

If you generate a new CSR with a different private key, any certificate issued for that CSR will only work with the new key. The old key and new certificate are strangers to each other.

Best Practices

Use strong keys: At least 2048-bit RSA or 256-bit ECC. 4096-bit RSA adds security margin but costs performance.

Fresh CSR for each certificate: Don't reuse CSRs, even for renewals. Generate new ones.

Accurate information: For OV/EV certificates, organization details must match official records exactly. Errors delay issuance.

Include all domains as SANs: Some CAs ignore the Common Name entirely. Always list every domain you need in the Subject Alternative Names.

When Automation Takes Over

ACME clients like Certbot handle CSR generation automatically. They create the private key, build the CSR with correct information, submit it to the CA, complete the validation challenges, and install the certificate—all without you seeing the underlying CSR.

This is the future of certificate management. Manual CSR generation is becoming a specialized skill for edge cases: internal CAs, unusual validation requirements, systems that can't run ACME clients.

But even when you never touch a CSR directly, knowing what it is helps you understand what's happening when certificate issuance fails, when keys don't match certificates, or when you need to debug a broken TLS configuration.