A Certificate Signing Request (CSR) is the first step in obtaining a digital certificate. It contains your public key and identity information, signed with your private key. This guide explains what a CSR is, what it contains, how to generate one, and the common mistakes to avoid.
A Certificate Signing Request (CSR) is a block of encoded data that you send to a certificate authority (CA) when applying for a digital certificate. The CSR contains your public key and identifying information about your organization, and it is signed with the corresponding private key to prove you possess it.
The CSR format is defined by the PKCS#10 standard (RFC 2986). When a CA receives your CSR, it verifies the signature, validates your identity (depending on the certificate type), and then issues a signed certificate containing your public key and identity information, bound by the CA's digital signature.
Think of a CSR as a formal application: you fill in your details, prove your identity, and the CA stamps it with their authority. The private key never leaves your system; only the public key and metadata travel to the CA.
A CSR contains structured data following the X.509 naming conventions. Here are the key fields.
The primary domain name or entity name the certificate will protect.
CN=www.example.com The legally registered name of your organization. Used in OV and EV certificates.
O=Example Inc A department or division. This field is now deprecated by many CAs and can be left empty.
OU=Engineering Two-letter ISO 3166-1 country code where the organization is legally registered.
C=US The public key that will be embedded in the certificate. Typically RSA 2048/4096-bit or ECDSA P-256/P-384.
The CSR is signed with the private key corresponding to the public key, proving key possession to the CA.
The most common way to generate a CSR is with OpenSSL. Here's a step-by-step process that includes Subject Alternative Names.
Create a 2048-bit RSA private key (or use ECDSA for better performance):
# RSA 2048-bit key
openssl genrsa -out server.key 2048
# Or ECDSA P-256 key (recommended)
openssl ecparam -genkey -name prime256v1 -out server.keyGenerate the CSR using the private key. Include SANs directly on the command line:
openssl req -new -key server.key -out server.csr \
-subj "/CN=www.example.com/O=Example Inc/C=US" \
-addext "subjectAltName=DNS:www.example.com,DNS:example.com"Before submitting, verify the CSR contents are correct:
openssl req -in server.csr -noout -text -verify
# Check: subject, public key algorithm, key size, SANs, signatureSubmit the server.csr file to your certificate authority. The CA validates the request and returns a signed certificate. Keep server.key safe and never share it.
While OpenSSL is the most universal tool, other platforms have their own CSR generation methods.
IIS Manager provides a GUI wizard: open Server Certificates, click "Create Certificate Request," fill in the subject fields, select a key size, and save the CSR file. The private key is stored in the Windows certificate store automatically.
For Java applications using keystores:
keytool -genkeypair -alias server -keyalg RSA -keysize 2048 \
-keystore keystore.jks -dname "CN=www.example.com,O=Example Inc,C=US"
keytool -certreq -alias server -keystore keystore.jks -file server.csrWith ACME-based tools like certbot, the CSR generation is handled automatically. The client generates a key pair, creates a CSR, submits it to the CA, and installs the certificate, all in a single command. This is the recommended approach for automated certificate management.
Always verify your CSR before submitting it to a CA. This catches errors in the subject, missing SANs, or wrong key parameters before you waste time on a failed issuance.
openssl req -in server.csr -noout -text
Certificate Request:
Data:
Version: 1 (0x0)
Subject: CN=www.example.com, O=Example Inc, C=US
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
RSA Public-Key: (2048 bit)
Attributes:
Requested Extensions:
X509v3 Subject Alternative Name:
DNS:www.example.com, DNS:example.com
Signature Algorithm: sha256WithRSAEncryption
[signature bytes...]You can also use the Evertrust Crypto Decoder to paste your CSR and get a visual breakdown of all fields, including extensions and key parameters, without running any command-line tools.
RSA 2048-bit minimum, 4096-bit for high-security use cases. ECDSA P-256 or P-384 offers equivalent security with better performance. Avoid RSA 1024-bit, which is considered broken.
ECDSA P-256 is the best default for TLS certificates: smaller keys, faster handshakes, and strong security. Use RSA only when legacy compatibility is required. Consider post-quantum readiness.
Modern browsers require Subject Alternative Names. Include all domains the certificate should cover. Don't forget the bare domain alongside www.
The private key generated alongside the CSR must be protected. Set restrictive file permissions (chmod 600), never transmit it, and consider HSM storage for high-value certificates.
Setting the CN to the organization name instead of the domain name. For TLS certificates, the CN should be the primary FQDN (e.g., www.example.com), not Example Inc.
Generating a CSR without the Subject Alternative Name extension. Browsers ignore the CN field for identity matching since Chrome 58. A certificate without SANs will trigger ERR_CERT_COMMON_NAME_INVALID.
Using RSA 1024-bit keys, which are no longer accepted by any reputable CA. Most CAs require a minimum of 2048-bit RSA or 256-bit ECDSA. Check your CA's requirements before generating the CSR.
Generating a CSR and then losing, deleting, or overwriting the private key. Without the matching private key, the issued certificate is useless. The only fix is to generate a new key pair and submit a new CSR. Always back up the private key securely before submitting the CSR.
CSR validation and policy: Evertrust PKI validates every CSR against your organization's policies before issuing a certificate. Reject CSRs with weak keys, incorrect subjects, or unauthorized SANs automatically.
Eliminate manual CSR workflows: With ACME and REST API enrollment, Evertrust CLM automates the entire process from key generation to certificate installation. No more emailing CSR files or pasting them into web forms.
Decode and inspect: Use the free Crypto Decoder tool to parse any CSR and visually inspect its contents, including subject, SANs, key algorithm, and signature.