CSR (Certificate Signing Request)

A Certificate Signing Request is a PKCS #10 structure, specified in RFC 2986, that an applicant generates and submits to a certificate authority. It contains the applicant's public key, a subject distinguished name, and optionally requested extensions such as Subject Alternative Names, all signed with the matching private key. That signature proves the applicant possesses the private key, which itself never leaves the applicant's system.

Why it matters

The CSR is the boundary between you and the CA: you keep the private key, and the CA gets only what it needs to issue the certificate. CAs treat the CSR as a request, not a command. They validate the names, ignore subject fields they have not verified (a DV certificate will not carry an O field even if you put one in the CSR), and set validity, key usage and policy themselves. ACME clients build and submit a CSR for you when finalizing an order, so with automated issuance you rarely handle one by hand.

Example

openssl req -new -newkey rsa:2048 -nodes \
  -keyout example.com.key -out example.com.csr \
  -subj "/CN=example.com" \
  -addext "subjectAltName=DNS:example.com,DNS:www.example.com"
openssl req -in example.com.csr -noout -text -verify

Common misconceptions

• The CSR contains the private key. It contains only the public key; never send the .key file to anyone.
• Every field I fill in will appear in the certificate. The CA decides the final content based on what it validated.
• Reusing last year's CSR is fine. It reuses the same key pair; generating a fresh key and CSR at renewal is better practice.