A Certificate Signing Request is the document that kicks off the entire certificate issuance process. Generated on your own server, it's a small, encoded block of text containing your public key and the identifying details you want the certificate to cover — sent to a certificate authority, which uses it as the basis for the certificate it issues back to you.
What's actually encoded inside a CSR
A CSR is a PKCS#10-formatted, base64-encoded block that includes your public key and a set of identifying fields: Common Name (the domain), Organization, Organizational Unit, Locality, State, and Country. The private key generated alongside it never goes into the CSR — only the public key does. If you're requesting a certificate covering multiple hostnames, the additional SAN entries are typically specified separately during the CA's order process, not always inside the raw CSR itself, depending on the CA's tooling.
Generating one with OpenSSL
openssl req -new -newkey rsa:2048 -nodes \
-keyout yourdomain.key -out yourdomain.csrThis single command does two things at once: generates a new 2048-bit RSA key pair, and produces the CSR using that new key. You'll be prompted interactively for the identifying fields — Common Name is the one that matters most, and it needs to exactly match the domain you're securing, including the www. prefix if that's the version you serve.
The most common mistakes
- Common Name typos or mismatches — a CSR generated for the wrong exact hostname results in a certificate for the wrong hostname, full stop; the CA has no way to know you meant something else.
- Losing the private key — the key generated alongside the CSR is required to install the resulting certificate. If it's lost, the certificate can't be used, and you'll need to generate a fresh CSR (and a fresh key pair) and start over.
- Reusing an old CSR for renewal without understanding it — reusing the same key pair across renewals is technically fine and sometimes done deliberately, but mixing up which key belongs to which certificate across multiple renewals is a common source of install failures on servers managing many certificates.
Doing it without the command line
Most hosting control panels (cPanel, Plesk) and load balancers can generate a CSR through their UI, which also avoids the risk of losing the private key, since the panel manages both pieces together internally. This is usually the simpler path unless you specifically need control over key parameters the panel doesn't expose.
Decoding an existing CSR to check it
Before submitting a CSR, it's worth decoding it to confirm the fields are correct — a free CSR decoder tool (see our Free SSL Tools category) will show you exactly what's encoded inside, catching a Common Name typo before it becomes a wrongly issued certificate rather than after.
What a CSR actually looks like
A generated CSR is a block of base64 text wrapped in header and footer lines, similar in appearance to a certificate itself but structurally different underneath:
-----BEGIN CERTIFICATE REQUEST-----
MIICijCCAXICAQAwRTELMAkGA1UEBhMCVVMxEzARBgNVBAgMClNvbWUtU3RhdGUx
ITAfBgNVBAoMGEludGVybmV0IFdpZGdpdHMgUHR5IEx0ZDCCASIwDQYJKoZIhvcN
...
-----END CERTIFICATE REQUEST-----You can safely paste this into a CA's order form or a decoder tool — it contains nothing secret. The private key generated alongside it, by contrast, should never be pasted anywhere public; it's the one file from this whole process that needs to be treated as sensitive.
What the CA actually does after you submit it
Once submitted, the CA extracts your public key and requested identity details from the CSR, then runs its validation process appropriate to the certificate type: a DV certificate triggers an automated domain-control check (DNS record, HTTP file, or email); OV and EV certificates additionally trigger manual verification against business registries and, for EV, direct confirmation steps with the organization. Once validation passes, the CA generates the certificate itself — a new file containing your public key (taken from the CSR), the validated identity fields, an expiry date, and the CA's own digital signature over the whole thing — and returns it to you, along with any intermediate certificates needed to complete the chain of trust.
Reusing a key pair across renewals
It's technically valid to generate a new CSR using the same key pair as a previous certificate when renewing — some organizations do this deliberately for continuity. The more common and generally recommended practice, though, is generating a fresh key pair for each renewal, since it limits how long any single private key stays in active use, reducing the impact if a given key is ever quietly compromised without your knowledge.
What's actually inside the CSR file itself
A CSR is a small, base64-encoded block of text containing your public key and the identity fields you're requesting — domain, organization, location. It contains nothing secret; you can safely paste it into a CA's order form or a decoder tool without any security concern, unlike the private key generated alongside it, which should never be shared or pasted anywhere.
The single most common mistake people make with it
Beyond a typo in the Common Name field, the most common practical mistake is losing the private key generated alongside the CSR — without it, the certificate the CA eventually issues can't actually be installed anywhere, since the certificate and key are a matched pair. If this happens, there's no recovery path other than generating an entirely new CSR and key pair and starting the issuance process again.
What the CA actually does with your CSR after you submit it
The CA extracts your public key and requested identity details, runs its validation process (automated for DV, manual for OV/EV), and once satisfied, generates a new certificate file containing your public key, the validated identity, an expiry date, and the CA's own digital signature over the whole package — the CSR itself is discarded after this, having served its purpose.
Reusing a key pair across renewals: allowed, but not usually recommended
It's technically valid to reuse the same key pair across a renewal by generating a new CSR from the existing key — but the more commonly recommended practice is generating a fresh key pair each time, since it limits how long any single private key stays in active use, reducing the impact if a key is ever quietly compromised without your knowledge.
Getting the CSR's identity fields right the first time matters more than it might seem, since correcting a mistake after issuance generally means starting the entire request process over from scratch with a fresh key pair.
A quick closing checklist before submitting any CSR
Double-check the Common Name and every SAN entry for typos, confirm you've securely saved the accompanying private key, and verify the key length or curve meets your CA's current minimum requirements — three checks that prevent the most common CSR-related delays.