A CSR is a request file you send to a certificate authority to get an SSL certificate
A Certificate Signing Request (CSR) is a block of encrypted text that you generate on your web server and send to a certificate authority (CA) when you want to buy an SSL certificate. The CSR contains information about your organization — your domain name, company name, location, and contact details — along with a public key that the CA uses to create your certificate.
You cannot get an SSL certificate without a CSR. The CA needs it to verify that you control the domain and to bind the certificate to your specific server. The CSR stays on your server; you never send your private key to anyone. Only the public key inside the CSR goes to the CA.
Most hosting providers and server software (Apache, Nginx, IIS, cPanel) have built-in tools to generate a CSR in seconds. You paste the CSR text into the CA's order form, they sign it, and you get back a certificate file to install on your server.
Key Takeaways
- A CSR is a text file generated on your server that contains your domain name, organization details, and a public key that the CA uses to create your SSL certificate.
- You generate the CSR yourself using your server's tools — you do not send it to the CA until you are ready to order a certificate.
- The CSR includes a public key, but your private key stays on your server and never leaves it.
- Different certificate types (single domain, wildcard, multi-domain) require different CSR information, but the process of generating one is the same.
What information goes into a CSR
When you generate a CSR, you provide details that become part of your SSL certificate. The most important field is the Common Name (CN) — this is the domain name the certificate will protect, such as example.com. If you are ordering a wildcard certificate, you enter *.example.com instead.
You also enter your organization name, department (optional), city, state or province, country code, and email address. These details appear in the certificate and help visitors verify that the certificate belongs to a legitimate organization. The CA may ask you to prove ownership of the domain and verify that the organization information is correct before they sign the CSR.
The CSR also contains a public key — a long string of characters generated automatically when you create the CSR. This public key is mathematically linked to a private key that stays on your server. The CA uses the public key to create the certificate, but they never see or touch your private key.
How to generate a CSR on your server
The steps depend on what software runs your server. If you use cPanel (common on shared hosting), log in, find the "SSL/TLS" section, and click "Generate, view, upload, or delete SSL certificates." Select "Generate a new private key and CSR" and fill in your domain name and organization details. cPanel generates the CSR and private key and stores both on your server.
On Apache servers running OpenSSL, you open a terminal and run a command like openssl req -new -newkey rsa:2048 -nodes -keyout example.com.key -out example.com.csr. You answer prompts for your domain, organization, and location, and OpenSSL creates two files: the CSR and the private key.
On Nginx or other Linux servers, the process is similar — you use OpenSSL from the command line. On Windows servers running IIS, you use the IIS Manager interface to create a CSR. Your hosting provider's documentation or support team can walk you through the exact steps for your setup.
What happens after you send the CSR to a certificate authority
Once you have generated the CSR, you copy the entire text (including the BEGIN and END lines) and paste it into the CA's order form. You do this during checkout when you are buying the certificate. The CA then validates your domain ownership — usually by sending you an email to an address listed in your domain's WHOIS record, or by asking you to add a DNS record to prove control.
The CA also verifies your organization information if you are ordering a business or extended validation certificate. Once validation is complete, the CA signs the CSR with their private key and sends you back a signed certificate file (usually a .crt or .cer file). You then install this certificate on your server alongside the private key you generated earlier.
The whole process typically takes a few minutes to a few hours, depending on the CA and the certificate type. Domain validation is fastest; organization validation takes longer because the CA may call your business phone number to confirm details.
CSR mistakes that delay certificate issuance
The most common mistake is entering the wrong domain name in the Common Name field. If you order a certificate for www.example.com but your site also uses example.com (without the www), the certificate will not match the second domain. You can avoid this by ordering a wildcard certificate (*.example.com) or a multi-domain certificate that covers both versions.
Another mistake is losing the private key after you generate the CSR. The private key and the signed certificate must be installed together on your server. If you lose the private key, you cannot use the certificate — you have to generate a new CSR, order a new certificate, and start over. Keep backups of both files in a secure location.
Entering incorrect organization information can also slow things down. If the name or address in your CSR does not match your business registration or domain WHOIS record, the CA may ask you to resubmit or provide documentation. Double-check spelling and use the legal name of your organization, not a nickname or abbreviation.
CSR versus the final SSL certificate
The CSR is a request — it is not the certificate itself. You generate it, send it to the CA, and then discard it. The CA signs the CSR and sends back a certificate, which is what you actually install on your server. The certificate is valid for one to three years (depending on what you buy), while the CSR is only used once during the ordering process.
If your certificate expires and you want to renew it, you generate a new CSR and send it to the CA again. You can use the same domain name and organization details, or update them if something has changed. Some CAs let you reuse a CSR, but it is safer to generate a fresh one for each certificate order.
Frequently Asked Questions
Can I use the same CSR for multiple certificates?
Technically yes, but you should not. Each time you order a certificate, generate a new CSR. This keeps your private key secure and makes it easier to track which certificate goes with which CSR. Reusing a CSR across multiple orders increases the risk of confusion or key compromise.
What if I generate a CSR but do not order a certificate right away?
The CSR itself does not expire, but keep it stored safely alongside the private key. If you wait months before ordering, the organization information in the CSR may become outdated. It is better to generate a fresh CSR when you are ready to order so the details are current.
Do I need to generate a new CSR if I renew my certificate?
Yes. When your certificate expires, generate a new CSR and send it to the CA. You can use the same domain name and organization details, but a fresh CSR ensures your private key stays secure and the certificate is properly bound to your current server setup.
What if the CA rejects my CSR?
The CA will tell you why — usually because the domain name does not match your order, the organization information is incomplete, or there is a formatting error. Fix the issue, generate a new CSR with the correct information, and resubmit it. There is no penalty for generating multiple CSRs.