What it is
A Certificate Signing Request (CSR) is a message sent from an applicant to a Certificate Authority (CA) to request a digital certificate. The CSR contains:
- Subject information: Common Name (CN), Organization (O), Country (C), etc.
- Public key: The public key that will be included in the certificate
- Signature: A signature created with the corresponding private key to prove ownership
- Extensions: Optional fields like Subject Alternative Names (SANs)
The CSR is typically generated on the server where the certificate will be used, and the private key never leaves that server. This ensures that only you have access to the private key.
Why it matters
CSRs are essential for:
- Certificate issuance: CAs require a CSR to issue a certificate
- Security: The private key stays on your server, never transmitted to the CA
- Flexibility: You can generate multiple CSRs with different parameters
- Validation: The CSR signature proves you control the private key
Without a CSR, you cannot obtain a certificate from a CA. The CSR serves as the formal request and proof that you control the private key that will be paired with the certificate.
In practice
Best practices for CSR generation:
- Generate the private key and CSR on the server where the certificate will be used
- Use strong key sizes (RSA 2048+ or ECDSA P-256+)
- Include all domains in Subject Alternative Names (SANs), not just the Common Name
- Keep your private key secure and never share it
- Verify the CSR before submitting it to the CA
- Use the correct Common Name (CN) - typically the primary domain
- Include wildcard domains in SANs if needed (e.g., *.example.com)
Further reading
- RFC 2986: PKCS #10: Certification Request Syntax Specification
- OpenSSL CSR Generation Guide
- Let's Encrypt Documentation
Generate one now with the browser-based CSR generator — your private key never leaves your device.
Related guides
- Certificate lifecycle
- CSR generator
- Certificate decoder
- SSL Studio — check the certificate your CA issues once it is live.