LiveChat 
Support 
CSR Certificate Explained: What a Certificate Signing Request Really Is
The phrase “CSR certificate” gets typed into search bars thousands of times a month, and it carries a small but important error in its name. A CSR is not a certificate. It is a Certificate Signing Request: a block of text you generate on your own server and send to a Certificate Authority (CA) when you want them to issue you an SSL/TLS certificate. The CA reads your request, validates who you are, and then issues a certificate in response. The request and the certificate are two different objects, produced at two different steps.
A CSR is an encoded message that bundles your public key together with the identifying details of the entity that wants a certificate, all formatted to a standard called PKCS#10. You create it locally, you hand it to a CA, and the CA uses the public key and identity inside it to mint your certificate. Clearing up that one distinction, request versus certificate, untangles most of the confusion people have about how SSL issuance actually works. Let’s walk through exactly what a CSR contains, how it relates to your private key, and how to generate and decode one correctly.
Key Takeaways
• A CSR is a request, not a certificate – you generate it and send it to a CA, which returns the actual certificate.
• A CSR is structured to the PKCS#10 standard (defined in RFC 2986) and contains your public key plus identity fields like the Common Name.
• Generating a CSR creates a matching private key at the same time – the private key never leaves your server and is never put inside the CSR.
• The certificate the CA issues only works with the specific private key that was paired with the CSR; lose that key and the certificate is useless.
• You can generate a CSR with OpenSSL on the command line or through your control panel’s SSL/TLS section, such as cPanel.
Here is the detail that makes the whole CSR design click, and that most explanations skip over. Generating a CSR is really a key-pair event. In the same command, your server creates a private key and a matching public key, and the CSR carries only the public half outward to the CA. The private key stays behind on your server and is never transmitted, never embedded in the request, and never seen by the CA. This is not an inconvenience: it is the entire point of asymmetric cryptography. The CA can confidently bind a certificate to your public key without ever needing, or being trusted with, the secret that controls it. When you later install the certificate, your server proves it controls the matching private key, and that proof is what convinces a browser the connection is genuinely yours. So the CSR and the private key are two halves of a single act. The CSR is the part you share; the private key is the part you must guard. If you regenerate the key, the old CSR, and any certificate issued from it, becomes worthless. That tight pairing is why “keep your private key safe” is not boilerplate advice. It is the load-bearing wall of the entire request.
What is a CSR certificate, and why is the name misleading?
A CSR, properly a Certificate Signing Request, is the input to certificate issuance, not the output. According to RFC 2986, the standard that defines its format, a CSR is a “certification request” containing a subject name, a public key, and a set of attributes, all signed by the requester. The word “certificate” in everyday searches simply attaches itself by association. There is no such object as a CSR certificate.
The confusion is understandable. Both a CSR and a certificate are blocks of Base64-encoded text wrapped in similar-looking -----BEGIN----- and -----END----- headers, and both relate to SSL. But they sit on opposite ends of the issuance process. The CSR is what you create and submit; the certificate is what the CA signs and returns. A CSR begins with -----BEGIN CERTIFICATE REQUEST-----, while a certificate begins with -----BEGIN CERTIFICATE-----. That one word in the header is the giveaway.
Think of it as an application form versus the credential it produces. You fill out and submit the application (the CSR); the authority verifies it and issues the credential (the certificate). Nobody calls a passport application a passport, and for the same reason a CSR is not a certificate.
What is actually inside a CSR?
A CSR contains two things that matter and one that ties them together: your public key, a subject (the identity fields describing who the certificate is for), and a self-signature proving you hold the matching private key. The identity portion is the part people interact with most, because you type those fields in by hand when you generate the request, and the Common Name is the one that most often causes trouble.
The subject is built from a set of named fields borrowed from the X.500 directory standard. Here is what each one means and a realistic example for each.
| Field | Stands for | Meaning | Example |
|---|---|---|---|
| CN | Common Name | The fully qualified domain name the certificate secures | www.example.com |
| O | Organization | The legal name of the entity requesting the certificate | Example Industries Ltd |
| OU | Organizational Unit | The department or division within the organization (optional) | IT Operations |
| L | Locality | The city or town of the organization | Manchester |
| ST | State / Province | The full state, region, or province name (do not abbreviate) | Greater Manchester |
| C | Country | The two-letter ISO country code | GB |
The Common Name (CN) is the field that decides which hostname the certificate is valid for, and getting it wrong is a frequent cause of browser errors. If your CN says example.com but visitors reach the site at www.example.com, the name will not match and browsers will warn. Modern certificates handle multiple names through a separate Subject Alternative Name (SAN) extension rather than the CN alone, but the CN you put in the CSR still needs to be correct.
Alongside these visible fields, the CSR carries your public key and the algorithm it uses (commonly RSA 2048-bit or an elliptic-curve key), plus a signature the CSR makes over its own contents using your private key. That self-signature lets the CA confirm the request was produced by whoever holds the matching private key.
How does a CSR relate to your private key and the final certificate?
The CSR, the private key, and the issued certificate form a single linked chain, and the private key is the secret thread running through all three. When you generate a CSR, your server creates a private/public key pair in the same step. The public key goes into the CSR; the private key is written to a separate file and stays on your server. The CA never sees it.
When the CA issues your certificate, it binds that certificate to the public key from your CSR. The certificate is therefore mathematically tied to the private key you kept. During every HTTPS handshake, your server uses that private key to prove it is the legitimate holder of the certificate. No private key, no proof, no working HTTPS. This is why the three objects must stay together: a certificate is only usable by the server that holds the exact private key generated alongside its CSR.
This relationship has a practical consequence people often learn the hard way. If you generate a CSR on one server, then try to install the resulting certificate on a different server that does not have the matching private key, it simply will not work. The certificate and key are a pair. Generate the CSR where you intend to install the certificate, or carefully move the private key with it.
How do you generate a CSR with OpenSSL?
OpenSSL is the most direct way to generate a CSR, and it produces the private key and the request together in one command. The following creates a 2048-bit RSA private key and a matching CSR, then prompts you to enter the subject fields described earlier.
openssl req -new -newkey rsa:2048 -nodes \
-keyout example.com.key \
-out example.com.csrA few notes on what each part does. -new requests a new CSR. -newkey rsa:2048 generates a fresh 2048-bit RSA key at the same time. -nodes (read as “no DES”) leaves the private key unencrypted so your web server can read it at startup without a passphrase prompt. -keyout names the private key file, and -out names the CSR file. After running it, guard example.com.key carefully and submit example.com.csr to your CA.
If you prefer to supply all the subject fields on the command line instead of answering prompts, pass them with -subj:
openssl req -new -newkey rsa:2048 -nodes \
-keyout example.com.key \
-out example.com.csr \
-subj "/C=GB/ST=Greater Manchester/L=Manchester/O=Example Industries Ltd/OU=IT Operations/CN=www.example.com"The order of fields in -subj follows the table above. Double-check the CN matches the exact hostname you intend to secure, since that is the value browsers compare against.
How do you generate a CSR in cPanel?
If you run on shared or managed hosting, you usually never touch OpenSSL directly. cPanel includes a guided CSR generator under its SSL/TLS area, and it handles the key creation for you. The workflow is short and removes most of the chances to make a mistake.
Inside cPanel, open Security > SSL/TLS, then choose Certificate Signing Requests (CSR). cPanel presents a form with fields for the domain (the Common Name), organization, city, state, country, and an email address. You fill those in, click Generate, and cPanel creates the private key and the CSR together, storing the key safely in your account and displaying the CSR text for you to copy and paste to your CA. Because cPanel keeps the matching private key on the same server, installing the returned certificate later is straightforward.
For most hosting customers this is the recommended route. It avoids command-line errors, keeps the private key where the certificate will eventually be installed, and stores both for retrieval when the certificate arrives.
How do you decode a CSR to check its contents?
Before you submit a CSR, it is worth decoding it to confirm every field is correct, because a typo in the Common Name or country code means a wasted certificate. OpenSSL reads the encoded request and prints its contents in human-readable form with this command.
openssl req -in example.com.csr -noout -text -verifyHere -in points at your CSR file, -noout suppresses re-printing the encoded request, -text prints the decoded fields, and -verify checks that the request’s self-signature is valid. In the output you will see the Subject line listing CN, O, OU, L, ST, and C exactly as you entered them, the Public Key algorithm and size, and a confirmation that the signature verifies. Read the Subject carefully. If the CN is wrong, regenerate the CSR now rather than after the CA has issued a certificate against the mistake.
There are also reputable online CSR decoders that do the same job in a browser, which is convenient when you cannot run OpenSSL. Whichever you use, the goal is the same: verify the request says what you meant it to say before it leaves your hands.
How DarazHost handles CSRs and SSL for you
On DarazHost hosting, most customers never need to generate a CSR by hand at all. Our free AutoSSL provisions and renews browser-trusted certificates automatically, handling the key generation, request, issuance, and installation behind the scenes so you get working HTTPS without touching OpenSSL. When you do need a custom or organization-validated certificate, the cPanel SSL/TLS section gives you a guided CSR generator that creates the private key and request together and stores them safely in your account. Either way the matching private key stays on the server where the certificate will live, which removes the most common cause of installation failures, and our support team is available 24/7 if you want a second pair of eyes on a request.
For the full picture of how certificates, encryption, and validation fit together, see our complete guide to SSL Certificates: The Complete Guide to How HTTPS, Encryption, and Trust Work. The CSR is the very first step in that journey, the request that sets everything else in motion.
Frequently asked questions
Is a CSR the same as an SSL certificate? No. A CSR (Certificate Signing Request) is what you generate and send to a Certificate Authority; the certificate is what the CA signs and returns to you. They are different objects at different stages. A CSR begins with -----BEGIN CERTIFICATE REQUEST-----, while a certificate begins with -----BEGIN CERTIFICATE-----. The CSR is the application; the certificate is the credential it produces.
Does my private key go inside the CSR? No, and this is critical. When you generate a CSR, a matching private key is created at the same time, but only your public key goes into the request. The private key is written to a separate file and must never leave your server or be sent to the CA. The certificate the CA issues only works with that specific private key, so guard it carefully.
What is the Common Name in a CSR? The Common Name (CN) is the fully qualified domain name the certificate will secure, such as www.example.com. It is the field browsers compare against the address visitors use, so it must match exactly. A mismatch between the CN and the actual hostname is a frequent cause of browser security warnings. Modern certificates also list extra names in a Subject Alternative Name extension.
Can I reuse a CSR for multiple certificates or servers? You can technically submit the same CSR more than once, but the resulting certificate only works on a server holding the matching private key generated with that CSR. Reusing a CSR across different servers means moving the private key too, which is risky. Best practice is to generate a fresh CSR and key on the server where the certificate will actually be installed.
How do I check what is in a CSR before submitting it? Decode it with OpenSSL using openssl req -in yourfile.csr -noout -text -verify, which prints the Subject fields, public key details, and confirms the self-signature is valid. Review the Common Name and country code especially. Reputable online CSR decoders do the same job in a browser. Verifying before submission prevents a wasted certificate built on a typo.
