CSR Explained: What's Inside and Why It Matters

What a CSR Is

A Certificate Signing Request (CSR) is a small, signed data structure — typically encoded as PKCS#10, defined in RFC 2986 — that you generate and send to a Certificate Authority to request a certificate. It is not itself a certificate: nobody has vouched for anything in it yet. It's better understood as an application: here is the public key I control, here is the identity I want a certificate for, and here is proof I actually hold the matching private key.

That proof is the CSR's defining property. The CSR body is signed with the private key corresponding to the public key it carries, so anyone can verify — without trusting the requester at all — that whoever submitted this CSR really does possess that private key. This is why a CA never needs to see your private key at any point in the issuance process: the signature is the proof, and the signature can be verified with the public key already sitting right there in the request.

What's Inside a CSR

• Subject. The Distinguished Name you're requesting — historically a Common Name matching your domain, plus optional Organization/Country/Locality fields for Organization Validation (OV) or Extended Validation (EV) certificates. For Domain Validation (DV) certificates, the common issuance type today, most of this beyond the CN is ignored by the CA.
• Public key. The key you generated — RSA or EC — that the eventual certificate will bind to your identity. This is copied essentially verbatim from the CSR into the issued certificate.
• Signature algorithm and signature. The algorithm and value proving possession of the corresponding private key, computed over everything else in the request.
• Requested extensions. Carried in an extensionRequest attribute, PKCS#9's mechanism for smuggling X.509 extensions into a PKCS#10 structure. In practice this is almost always where your Subject Alternative Names live — every hostname you want the certificate to cover, since a modern browser will ignore everything except the SAN list when matching a hostname. It can also request Key Usage, Extended Key Usage, or other extensions, though the CA is under no obligation to honor any of them.

From CSR to Certificate

The CA does not simply copy your CSR into a certificate and sign it. It verifies the signature to confirm key possession, performs whatever domain/organization validation its issuance policy requires (an HTTP or DNS challenge for DV, business registry checks for OV/EV), and then constructs a new structure: your public key and requested Subject, mapped into a propertbsCertificate, plus fields the CSR never contained at all — the CA's own Issuer name, a CA-assigned serial number, a validity window set by the CA's policy (not anything you requested), and extensions the CA chooses to include, which may be a subset of what you asked for. The requested SANs typically do carry through unchanged, since they're exactly what the CA validated ownership of — but nothing about a CSR guarantees any particular field survives into the final certificate. The signed CSR is an application; the CA writes the actual document.

Generating One Safely

The private key must never leave the machine that generates it. The entire point of the CSR mechanism is that you can prove key possession to a CA without transmitting the key itself anywhere — generate the keypair and CSR together, on the server (or HSM, or local machine) that will ultimately hold the private key, and send only the CSR onward:

# RSA-2048 key + CSR in one step
openssl req -new -newkey rsa:2048 -nodes \
  -keyout example.com.key -out example.com.csr \
  -subj "/CN=example.com"

# Prefer EC (P-256) for a smaller, faster-verifying key
openssl req -new -newkey ec -pkeyopt ec_paramgen_curve:P-256 -nodes \
  -keyout example.com.key -out example.com.csr \
  -subj "/CN=example.com"

If you use a CSR generation wizard (in a hosting control panel or a CA's web portal) that offers to create the private key for you and hand it back over the network, be aware you're trusting that service with your private key from the moment it's created — the safer default is always to generate the keypair locally and submit only the CSR.

Common CSR Mistakes

• Missing SANs. A CSR with only a CN and no extensionRequest SAN entries will typically produce a certificate that fails hostname verification in every modern browser, per the CN-vs-SAN rules. Many CAs now auto-populate the SAN from the CN as a courtesy, but don't rely on it — request the SANs explicitly.
• Key reuse across certificates. Generating one keypair and submitting the same CSR (or a new CSR built from the same key) for multiple unrelated certificates weakens your security posture — a single leaked private key then compromises every certificate built on it. Generate a fresh keypair per certificate.
• Weak or wrong key parameters. RSA below 2048 bits is rejected outright by every public CA under current Baseline Requirements. Mismatched curve parameters on an EC key produce a CSR that looks fine but fails signature verification at the CA.
• Losing the private key. The CSR and issued certificate are both public information you can regenerate a copy of; the private key is not. If it's lost, there is no recovery path — you generate a new keypair, a new CSR, and get the certificate reissued.

Decode Your Own CSR

Paste a CSR below to see its requested subject, key algorithm, SANs, and any requested extensions extracted automatically. Parsing happens entirely in your browser.

Once the certificate comes back from the CA, decode it the same way to confirm what actually made it through — see how to read an SSL certificate. And if you're assembling the certificate with its intermediates for deployment, see fixing an incomplete certificate chain.