Cybersecurity glossary
What is a Certificate Signing Request (CSR)?
Learn what a Certificate Signing Request (CSR) is, what information it contains, how key pairs and CA issuance relate, and which security practices keep private keys safe during certificate requests.
Definition
A Certificate Signing Request (CSR) is a signed message that contains a public key and identity fields, sent to a Certificate Authority so the CA can validate the applicant and issue an X.509 certificate for that key.
Why CSRs matter
Before a Certificate Authority can issue a TLS or identity certificate, it needs two things: a public key to bind and evidence about who should own that binding. A Certificate Signing Request (CSR) packages the public key and requested identity fields in a standard, signed structure—most often PKCS #10.
Understanding CSRs helps operators avoid a classic failure: treating certificate purchase as a file download while mishandling the private key that makes the certificate useful. The CSR is shareable. The private key is not.
What a CSR contains
A CSR is created on the system that holds—or will hold—the private key. The requester generates a key pair, embeds the public key and subject information in a request, and signs that request with the private key. The signature proves possession of the key without revealing it.
Public key
The key the CA will place into the issued certificate. Algorithm and size must meet current policy.
Subject / SAN fields
Requested identity such as DNS names, directory names, or other attributes the CA may approve.
Proof of possession
A signature over the request using the corresponding private key.
Optional attributes
Extensions or challenge passwords depending on enrollment protocol and CA support.
Important nuance: a CA is not obligated to copy every CSR field into the final certificate. Public TLS CAs increasingly populate names from validated domain control data and Certificate Transparency requirements rather than trusting arbitrary CSR content.
How CSR-based issuance works
Generate a key pair
Create a private key in a secure location such as a server filesystem with tight permissions, a vault, or an HSM.
Create the CSR
Build a PKCS #10 request containing the public key and desired identity fields.
Submit to the CA
Send the CSR through a portal, ACME-backed automation, or enterprise enrollment protocol.
Complete validation
Prove domain control or identity according to the certificate product and CA policy.
Receive the certificate
Install the issued certificate with any required intermediates on the TLS terminator or identity store.
Protect and rotate
Keep the private key safe, monitor expiry, and re-key on a defined lifecycle.
ACME-based automation still uses the same cryptographic ideas, even when operators never manually open a PEM CSR file.
CSR vs private key vs certificate
| Item | Contains | Shareable? |
|---|---|---|
| Private key | Secret key material used to prove identity and decrypt/sign as designed | Never with the CA or ticket systems |
| CSR | Public key + requested identity + proof-of-possession signature | Yes, with the intended CA/enrollment service |
| Certificate | CA-signed binding of public key to validated identity | Yes, it is presented to clients |
If a support process asks for “the key and the CSR,” stop and clarify. They need the CSR and later the certificate chain—not the private key.
Security practices for CSRs
- Generate keys on the system or HSM that will use them; avoid generating production keys on admin laptops when possible.
- Use current algorithm guidance (for example, strong RSA sizes or approved elliptic curves) and disable obsolete options.
- Include all required DNS names in SAN planning; do not rely on legacy CN-only assumptions.
- Never email private keys or commit them to source control alongside CSRs.
- Prefer automated issuance and renewal to reduce urgent manual CSR handling errors.
- Treat CSR generation as a change event: inventory the key, owner, expiry target, and installation location.
- On suspected private-key exposure, do not merely renew with the same key; re-key and revoke.
- Validate that the installed certificate matches the expected public key and names after issuance.
Common operational pitfalls
Operators paste a CSR created for www.example.com into an order for api.example.com and discover the mismatch only after browsers reject the name. Others generate a new CSR but accidentally leave an old private key configured on the server. Wildcard requests get broader names than intended. Enterprise teams also sometimes reuse one CSR across many machines, which means many machines share one private key—convenient and dangerous.
Another frequent issue is encoding confusion: PEM versus DER, or submitting a certificate file where a CSR is required. Tooling should verify the object type before enrollment.
The practical takeaway
A Certificate Signing Request (CSR) is the standardized way to ask a CA to issue a certificate for a public key you control. It carries identity requests and proof of possession—not the private key itself.
Safe certificate operations start before the CA portal: generate strong keys in the right place, craft an accurate CSR, validate issuance, and keep private keys out of tickets, chat, and git history.
Related security terms
Certificate Authority (CA)
The issuer that receives a CSR, validates identity, and returns a signed certificate.
X.509 Certificate
The signed credential produced after a CA approves a CSR.
Public Key Infrastructure (PKI)
The operational framework in which CSRs, issuance, and trust anchors fit.
Self-Signed Certificate
An alternative where the subject signs its own certificate instead of sending a CSR to a CA.
Frequently asked questions
What is a CSR in simple terms?
A CSR is a request file you send to a Certificate Authority when you want a trusted certificate. It includes your public key and the names you want on the certificate, and it proves you control the matching private key.
Does a CSR contain the private key?
No. A proper CSR contains the public key and identity attributes, signed by the private key. The private key must stay on the system that generated it or in an HSM.
What format is a CSR usually in?
Most TLS CSRs use PKCS #10 and are commonly exchanged as Base64 PEM blocks with BEGIN CERTIFICATE REQUEST markers, although binary DER encoding also exists.
What information goes into a CSR?
Typical fields include the public key and subject names such as common name and subject alternative names. Organization details may appear depending on validation type and CA requirements.
Is creating a CSR the same as getting a certificate?
No. Generating a CSR only prepares the request. The CA must still validate control of the domain or identity and then issue the signed certificate.
Can I reuse a CSR?
Sometimes, but reusing an old CSR also reuses the same key pair. Best practice is to generate a new key and CSR on renewal unless a controlled rekey policy says otherwise.
What is the biggest CSR-related security mistake?
Sending or storing the private key with the CSR, generating keys on an untrusted machine, or using weak key sizes and obsolete algorithms.
References
Explore authoritative guidance and frameworks related to certificate signing request (csr).
Explore every security definition
Return to the glossary to search by term, alias, starting letter, or security category.