What is a CSR (Certificate Signing Request)?
A Certificate Signing Request (CSR) is a small, encoded text file you generate on your own server, in a control panel, or with a tool like OpenSSL, and then submit when you order an SSL/TLS certificate. It is not the certificate itself — it is a request that carries your public key and the domain details a certificate authority (CA) needs in order to issue one. Knowing what a CSR is before you generate one saves a support ticket later, because most CSR problems turn out to be a typo in the fields below rather than anything wrong with OpenSSL.
If you have not ordered a certificate yet, start with our overview of SSL certificates or the walkthrough of how to buy an SSL certificate — generating a CSR is one step in that process, not a separate product.
What's inside a CSR: public key, subject fields, and SANs
Open a CSR in a text editor and you will see a block of base64 text between -----BEGIN CERTIFICATE REQUEST----- and -----END CERTIFICATE REQUEST-----. Decoded, it contains:
- Your public key, generated together with — and mathematically tied to — your private key.
- Subject fields: Common Name (the primary domain, for example
example.com), Organization and Organizational Unit (for OV and EV certificates), City/Locality, State/Province, and Country. - Subject Alternative Names (SANs): every additional hostname the certificate should cover, such as
www.example.com, a second domain, or a wildcard entry. - A signature proving the request was signed with the private key that matches the public key inside it.
The CA uses these fields to decide what to validate — see our guide to domain validation (DCV) — and what to put on the issued certificate; it will not add a hostname you did not request. If you are unsure which validation level you need, our DV SSL page explains what a domain-only certificate covers.
How a CSR relates to your private key
The private key is generated at the same time as the CSR — or just before it — and it should never leave the server or panel where it was created. It is not part of the CSR file and should never be sent to anyone, including SSLCipher or the certificate authority. The CSR only carries the public half of that key pair. Once the CA issues your certificate, it will only work together with the exact private key that produced the CSR that was submitted; generate a new CSR after issuance and the certificate and key will no longer match, which is one of the most common problems covered in our SSL installation guide.
That is also why losing a private key is worse than losing a CSR: a CSR can be regenerated in seconds, but a lost private key means reissuing the certificate against a brand-new key pair.
How to generate a CSR with OpenSSL (RSA 2048)
The most common way to create a CSR with OpenSSL generates an RSA 2048-bit private key and the CSR together, in a single command:
openssl req -new -newkey rsa:2048 -nodes -keyout example.com.key -out example.com.csrOpenSSL will prompt for the subject fields — Country, State, City, Organization, Organizational Unit, and Common Name — plus an optional challenge password you can normally leave blank. RSA 2048-bit is the usual minimum key size certificate authorities accept today, which makes it a safe default when you are not sure what to choose.
Adding SANs with an OpenSSL config file
The interactive prompts only ask for one Common Name, so as soon as the certificate needs to cover more than one hostname — example.com and www.example.com, say — it's easier to write a small config file with the SAN list and pass it in instead:
[req]
distinguished_name = req_distinguished_name
req_extensions = v3_req
prompt = no
[req_distinguished_name]
CN = example.com
[v3_req]
subjectAltName = @alt_names
[alt_names]
DNS.1 = example.com
DNS.2 = www.example.comopenssl req -new -newkey rsa:2048 -nodes -keyout example.com.key -out example.com.csr -config example.com.cnfSave the block above as example.com.cnf, add one DNS.n line per hostname, and the resulting CSR will already carry every SAN — no need to re-enter them later in an order form field by field.
CSR generator: an ECDSA (P-256) OpenSSL example
ECDSA is a common modern alternative to RSA: it reaches equivalent security with a smaller key, which is why some administrators prefer it. Generate a P-256 private key first, then create the CSR from it:
openssl ecparam -name prime256v1 -genkey -noout -out example.com.keyopenssl req -new -key example.com.key -out example.com.csrThe second command asks the same subject-field questions as the RSA example above. Check with your certificate authority or reseller which key types a specific product supports before you commit to ECDSA for a certificate you have not ordered yet.
RSA or ECDSA: which key type should you choose?
If you're not sure, RSA 2048-bit is the safer default: every certificate authority, every browser, and older internal tools or API clients accept it without exception. ECDSA P-256 produces a smaller CSR and a smaller certificate for equivalent security, which can matter on constrained devices or high-volume TLS handshakes, but it's only worth choosing once you've confirmed that every server and every client that needs to connect to it — including older internal integrations — actually supports it. When that isn't confirmed, RSA is the lower-risk choice for a certificate you are ordering today.
How to check a CSR before you submit it
Before pasting a CSR into an order form, confirm it actually contains what you intended:
openssl req -in example.com.csr -noout -text -verify-verify confirms the signature is valid — that it matches the private key that created it — and -text prints every subject field and SAN in a human-readable form. Read through the output line by line; it is the quickest way to catch a wrong Common Name or a missing SAN before it turns into a certificate you have to reissue.
Generating a CSR in a control panel or reseller panel
Most hosting control panels, such as cPanel or Plesk, can generate a CSR and a matching private key through a form instead of the command line: you fill in the same subject fields, and the panel runs the equivalent of the OpenSSL commands above behind the scenes. The private key it creates stays on that server, exactly as it would with OpenSSL.
In the SSLCipher reseller panel, you have both options when you place an order: let the panel generate the CSR and private key for you, or paste in a CSR you already generated yourself with OpenSSL or another tool. Generating it in the panel is the faster path for a routine order; pasting your own CSR matters when the private key has to be created and stored on the destination server itself, or when your own workflow already produces CSRs through the SSLCipher API.
Common CSR mistakes to avoid
A handful of mistakes account for most CSR-related support requests:
- Wrong Common Name. A typo, the wrong domain, or an internal hostname that does not match what visitors actually type into the address bar.
- Forgetting www or other SANs. If both
example.comandwww.example.comneed to be covered, both have to be in the request — a certificate authority will not add one on its own. This is a frequent cause of the "connection is not private" errors visitors run into later. - Losing the private key. Without it, the certificate issued from your CSR is unusable and has to be reissued against a new key pair.
- Reusing an old key pair. Generating a new CSR from a private key you have used before still works, but a fresh key pair per certificate is better practice — especially since certificate lifetimes keep shrinking and you will be doing this more often; see our guide to renewing an SSL certificate.
- Sharing the private key. It should never be emailed, pasted into a support ticket, or sent to anyone at all — not your CA, not your reseller, not SSLCipher.
Generate your CSR, then choose the right certificate
A CSR is a small, mechanical step, but getting the subject fields and SANs right the first time avoids a reissue later on. Whether you generate it with OpenSSL, in a control panel, or directly inside the SSLCipher reseller panel, the same rules apply: keep the private key secret, double-check the Common Name and SANs with openssl req -noout -text, and match the CSR to the certificate type you actually need.
Once the CSR is ready, place your order and choose the validation level and any Wildcard or Multi-Domain coverage the domain actually needs before you submit it.
Frequently asked questions
01What is a CSR used for?
A CSR is what you submit to a certificate authority, or a reseller, when ordering an SSL certificate. It carries your public key and the domain details, such as Common Name, SANs, and organization fields for OV/EV, that the CA needs to validate and issue the certificate.
02Can I generate a CSR without OpenSSL?
Yes — most hosting control panels such as cPanel and Plesk can generate a CSR and private key through a form, and the SSLCipher reseller panel can generate one for you when you place an order. OpenSSL is simply the most common command-line option and works the same way everywhere.
03What happens if I lose the private key that matches my CSR?
The certificate issued from that CSR becomes unusable, because it only works together with the exact private key that created the request. You will need to generate a new CSR and private key and have the certificate reissued against them.
04Do I need a new CSR every time I renew my certificate?
Not strictly — a CSR generated from the same key pair can technically be reused — but generating a fresh CSR and key pair at each renewal is better practice and is what most panels do by default. Certificate lifetimes are getting shorter, so this happens more often than it used to.