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.
Create a 2048-bit RSA private key (or use ECDSA for better performance):
Generate the CSR using the private key. Include SANs directly on the command line:
Before submitting, verify the CSR contents are correct:
Submit 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.
The primary domain name or entity name the certificate will protect.
The legally registered name of your organization. Used in OV and EV certificates.
A department or division. This field is now deprecated by many CAs and can be left empty.
Two-letter ISO 3166-1 country code where the organization is legally registered.
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.
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.
# RSA 2048-bit key
openssl genrsa -out server.key 2048
# Or ECDSA P-256 key (recommended)
openssl ecparam -genkey -name prime256v1 -out server.keyopenssl 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"openssl req -in server.csr -noout -text -verify
# Check: subject, public key algorithm, key size, SANs, signaturekeytool -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.csropenssl 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...]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.