What is a CSR?
A certificate signing request is the message an administrator sends to a certificate authority to ask for a certificate. It carries the public key, the subject's identifying details and any requested extensions, most importantly the list of hostnames. The requester signs the CSR with the matching private key, which proves to the CA that the requester actually holds that key. The private key itself never leaves the requester's system. The standard format is PKCS #10, defined in RFC 2986, usually exchanged as a Base64 text block that begins with -----BEGIN CERTIFICATE REQUEST-----.
What a CSR contains
- Public key and its algorithm, such as ECDSA on P-256 or RSA at 2048 bits or more
- Subject distinguished name: common name (CN), organization (O), locality (L), state (ST) and two-letter country code (C)
- Requested extensions, chiefly the Subject Alternative Name list that browsers match hostnames against
- Signature made with the requester's private key
A CSR is not secret, and it is only a request. The CA decides what goes into the final certificate; for a domain-validated certificate it typically drops the organization and location fields and includes only the hostnames.
Generating and checking a CSR
With OpenSSL, one command creates a new key pair and the request:
openssl req -new -newkey ec -pkeyopt ec_paramgen_curve:P-256 -noenc -keyout portal.key -out portal.csr -subj "/CN=portal.example.com" -addext "subjectAltName=DNS:portal.example.com"
Before submitting, check the request with openssl req -in portal.csr -noout -text -verify. The first line of output, Certificate request self-signature verify OK, confirms the CSR was signed by the private key that matches the public key inside it; the rest lists the subject, key and requested names. On Windows the same job is done with the Create Certificate Request wizard in IIS Manager or with certreq -new and an .inf file, and ACME clients such as Certbot create CSRs automatically at each renewal.
Common CSR mistakes
- Letting a website or vendor generate the private key for you, which means someone else has held a copy of it.
- Leaving a needed hostname out of the SAN list, which later causes a name mismatch error.
- Writing the country as USA instead of US, or giving an organization name that doesn't match legal records for an OV or EV certificate.
- Reusing the old key at renewal. A fresh key pair for each CSR limits the damage from a key that leaked unnoticed.
- Losing the private key after submitting. The issued certificate is useless without the key created alongside the CSR.
CSR vs. certificate vs. private key
The CSR is the request: public key and requested names, signed only by the requester. The certificate is what the CA sends back: those details plus validity dates, a serial number, extensions and the CA's own signature. The private key stays on the server or in its HSM and is paired with the certificate at installation. A PKCS #12 file (.pfx or .p12) bundles a certificate with its private key and must be protected like a password; a CSR never contains that key.
CSR on the CompTIA Security+ exam
Generating a CSR is part of SY0-801 objective 1.3, within the certificate topics of the cryptographic solutions objective. The tested fact is simple: a CSR carries the public key and the requested names, and the private key stays with the requester. Any answer that sends the private key to the CA, or claims the CA signs the CSR and returns it, is wrong. Wording such as "the first step to obtain a certificate from a CA" or "what does the administrator submit to the CA" points to generating a key pair and a CSR. Distractors include CRLs and OCSP, which deal with revocation, and self-signed certificates, which skip the CA altogether.