Generate a CSR the Right Way

A Certificate Signing Request (CSR) is a block of encoded text you generate on your server that contains your public key and identifying details (domain, organization, location). You send it to the certificate authority; they use it to build your certificate.

Generate one with OpenSSL

openssl req -new -newkey rsa:2048 -nodes \
  -keyout yourdomain.key -out yourdomain.csr

You'll be prompted for Country, State, Organization, and Common Name — the Common Name must exactly match the domain you're securing (e.g. www.yourdomain.com).

Common mistakes

• Common Name typos — a CSR for the wrong domain issues a certificate for the wrong domain.
• Losing the private key generated alongside it — without it, the certificate can't be installed.
• Regenerating a CSR for renewal when reusing the existing key was an option — either works, but don't mix key pairs across install steps.

Most hosting control panels (cPanel, Plesk) can generate a CSR through their UI if you'd rather avoid the command line.

What each field in the CSR in reality gets used for

The Common Name must exactly match the hostname visitors will use — www.example.com and example.com are different values as far as a CSR is concerned, which is why most certificates today list both explicitly as Subject Alternative Names rather than relying on the Common Name alone. Organization, Locality, and Country matter exactly for OV and EV validation, where the CA cross-checks these details against public business registries — for a DV certificate they're typically ignored entirely, since DV validation only confirms domain control, not organizational identity.

Why the private key generated alongside a CSR never gets sent anywhere

A CSR is deliberately built so that only your public key travels to the CA — the private key stays on the machine that generated it for the CSR's signature to even be verifiable later. This is the whole point of asymmetric cryptography applied to certificate issuance: the CA can verify you hold the matching private key (via the CSR's own digital signature) without you ever having to hand that key over to a third party. If a CA, a hosting provider, or any tool ever asks you to upload or email your private key directly, that's worth treating as a red flag rather than a normal part of the process.

Decoding a CSR to double-check it before submitting

Running openssl req -text -noout -verify -in request.csr prints every field back out in readable form and confirms the signature is internally valid — worth doing before submitting to a CA, since catching a typo in the Common Name here takes seconds, while catching it after issuance means requesting a full reissue.

See RFC 2986, the PKCS#10 CSR format specification.