A certificate signing request, or CSR, is a message you send to a certificate authority asking for a certificate. It contains your public key and the names you want covered, signed with your private key. The private key itself never leaves your system. The format is PKCS #10, published as RFC 2986.
What is inside
RFC 2986 republishes PKCS #10 version 1.7, the syntax for certification requests. A request has three parts in practice: the subject information you ask to be certified, the public key, and a signature made with the matching private key. The signature shows the requester holds the private key, so nobody can request a certificate for a key they do not own.
Modern practice puts the names you need in a subject alternative name request, since clients check those. See reading certificate fields.
Make one
# new key and request in one step
openssl req -new -newkey ec -pkeyopt ec_paramgen_curve:prime256v1 -nodes \
-keyout app.key -out app.csr -subj "/CN=app.example.com" \
-addext "subjectAltName=DNS:app.example.com"
Then check it before you send it:
openssl req -in app.csr -noout -text
Confirm the names, the key type and that the signature line says verify OK when you use the verify option.
Protect what you generated
| File | Share it? | Handling |
|---|---|---|
| app.csr | Yes, to the CA | Safe to send |
| app.key | Never | Tight permissions, no repository, no chat |
| Issued certificate | Yes | Public |
If the key ever lands in a commit or a ticket, treat it as leaked. See what to do when a TLS private key leaks.
Do you still need to handle CSRs?
With ACME and Certbot, your client builds and submits the request for you, and you may never see it. You still meet CSRs when:
- you buy a certificate from an authority that does not use ACME,
- you run a private CA for internal services,
- a network appliance or device generates its own key and asks you for a certificate.
Choose the key type deliberately. See ECDSA or RSA. Decide too whether each renewal gets a new key, as covered in reusing keys at renewal.
What the CA does with it
The authority checks the signature, then separately checks that you control the names. For public certificates, that second step is a domain validation challenge. See the ACME challenge types. The authority then issues a certificate that binds your public key to the validated names.
Common mistakes
- Requesting a common name alone and no subject alternative names.
- Generating the key on a shared laptop, then copying it around.
- Reusing one CSR for many certificates, which reuses the key.
- Sending the key file by mistake along with the request.
Where Safeguard fits
Safeguard scans dependencies and SBOMs for known vulnerabilities, including those in the TLS and crypto libraries your projects pull in, and you can try it with the free scan at gold.safeguard.sh/scan.
Quick check
Does a CSR contain my private key?
No. It carries the public key, and is signed by the private key to prove you hold it.
Is a CSR secret?
No. It contains public information, but handle it with care so the right names are requested.
Sources
Last reviewed: 19 October 2026.
